Cette page appartient aux archives web de l'EPFL et n'est plus tenue à jour.
This page belongs to EPFL's web archive and is no longer updated.

Different questions regarding the slides

Hi

There are several things I didn't get in the slides, some of them being just typos, I think.


in archi.ppt on top left of page 39, there is the formula T = L/D, shouldn't it be T = L/b ?


in tcp.ppt on pages 43, there are several things I don't understand :
"Reset timers for packets 4, 5, 6", as packet 6 is an ack, shouldn't it be "Reset timers for packets 4, 5" ?

then at event 8, why does the sender waits for the ack (event 9) before sending the next packet ? Is it because it's usable window is empty ?

there is something I don't understand with the "win" field (same on page 57). It is supposed to be the offered Window Size so I suppose that on the acks, it represents the window's size the sender should use (credits). And on the data, it represents the window's size the sender is actually using. So why don't they match ? After receiving an ack, the window's size should be set the the received value, and then the next sent packet should piggyback this same value.


in dv.ppt on page 9, I think there is a typo on the 3rd (should add B4 at the end) and 4th routes (should add B2 between R2 and R3).

on page 36, the statement "Just before B updates its table..." shouldn't it be "Just before B broadcasts its table..." ?

on page 42, I don't understand what the "bounce effect" is. Is it just a synonym for slow convergence ?

on page 43, I think the starting scenario is: link 1 fails -> the system converge to a new stable state -> link 6 fails -> D updates its table (sets costs to INF). Then the entry "B l3 INF" on table D is not logical, is should be : "B l6 INF" (same for pages 46, 47, 48)

Are these statements true ?:
split horizon can fail only if there is a loop;
even if there is a loop, the order of the broadcasts will determine failure or success of split horizon (success if all routers with correct infinite values are able to broadcast their values to all neighbors before receiving incorrect values);
even if split horizon fails, the routers will just count toward infinity, thus (slowly) converging to a stable state.


in bgp.ppt on page 5, it is said that ARD D and B are transit. It's ok for D since it serves as a relay between A and C. But it's not the case for B so shouldn't B be multihomed instead of transit ?

on page 12, the last line states that : "ISP 1 announces to ISP3 only routes to ISP3?s customers". But it doesn't make sense to me, so shouldn't it be "... only routes to ISP1?s customers" ? This way, ISP3 is not aware of the connection between ISP2 and ISP1 and therefore cannot send its packet to ISP2 through ISP1.

on page 20, the import policy accepts or rejects routes. But what is the point of rejecting some routes ? Are there incorrect routes ? And if yes, how can they be detected ?

on pages 34, 35, 79, 80, the address 2.2.2.2 is the external address of router R5 and not R6 ?

on page 80, shouldn't R1 also inject the route in its forwarding table ?
Posted by René Giller on Saturday 16 December 2006 at 1:37
Comments
For BGP:

in bgp.ppt on page 5, it is said that ARD D and B are transit. It's ok for D since it serves as a relay between A and C. But it's not the case for B so shouldn't B be multihomed instead of transit ?
-----
Perhaps the picture in p.5 does not tell everything. From http://www.freesoft.org/CIE/Topics/4.htm:
If you draw a network map of AS's, three distinct types can be identified:
A Stub AS is only connected to one other AS. For routing purposes, it could be regarded as a simple extension of the other AS. In fact, most networks with a single Internet connection don't have a unique AS number assigned, and their network addresses are treated as part of the parent AS.
A Transit AS has connections to more than one other AS and allows itself to be used as a conduit for traffic (transit traffic) between other AS's. Most large Internet Service Providers are transit AS's.
A Multihomed AS has connections to more than one other AS, but does not allow transit traffic to pass, though its interior hosts may route traffic through multiple AS's. This is the typical configuration for a large corporate network with multiple redundant Internet connections, but which does not wish to pass traffic for others.
Actually, the picture does not tell exactly what happens to the traffic inside B (and in general, inside every ARD)...

***********************************************************
on page 12, the last line states that : "ISP 1 announces to ISP3 only routes to ISP3?s customers". But it doesn't make sense to me, so shouldn't it be "... only routes to ISP1?s customers" ?
This way, ISP3 is not aware of the connection between ISP2 and ISP1 and therefore cannot send its packet to ISP2 through ISP1.
------
I think its'a typo, I think you are correct.


*******************************************************************
on page 20, the import policy accepts or rejects routes. But what is the point of rejecting some routes ? Are there incorrect routes ? And if yes, how can they be detected ?
-----------
For example an ISP might reject some routes about prefixes the client did not pay for (see TP3)

********************************************************************
on pages 34, 35, 79, 80, the address 2.2.2.2 is the external address of router R5 and not R6 ?
---------
Yes.
******************************************************************
on page 80, shouldn't R1 also inject the route in its forwarding table ?
-----------
which route???
Posted by Gianluca Rizzo on Tuesday 19 December 2006 at 10:23
could you add an errata section on the blog please?
Posted by Raphaël Tagliani on Tuesday 19 December 2006 at 11:02
done
Posted by Manuel Flury on Tuesday 19 December 2006 at 12:21
on page 80, shouldn't R1 also inject the route in its forwarding table ?
-----------
which route???

the route 18.1/16, NEXT-HOP = 2.2.20.1
Posted by René Giller on Wednesday 20 December 2006 at 16:13
yes.
Posted by Gianluca Rizzo on Thursday 21 December 2006 at 12:55
dv.ppt:
pp 9, agree;
pp 36, agree;
pp 42: I think it refers to what happens to advertisements exchanged between a and b before the algorithm converges;
pp 43, agree.
split horizon:
I think that it can fail if the undirected graph of the network of routers has cycles: if this is not the case, s.h. will work.
If s.h. fails, you can have a state that you can define as stable only if you set a maximum distance.
Posted by Gianluca Rizzo on Thursday 21 December 2006 at 13:54
in archi.ppt on top left of page 39, there is the formula T = L/D, shouldn't it be T = L/b ?

- yes, you are right
****************************

in tcp.ppt on pages 43, there are several things I don't understand :
"Reset timers for packets 4, 5, 6", as packet 6 is an ack, shouldn't it be "Reset timers for packets 4, 5" ?

- yes, you are right
****************************

then at event 8, why does the sender waits for the ack (event 9) before sending the next packet ? Is it because it's usable window is empty ?

- to me there is no reason visible on the picture of why it couldn't send it before. maybe it simply doesn't have data to send before event 9.
****************************

there is something I don't understand with the "win" field (same on page 57). It is supposed to be the offered Window Size so I suppose that on the acks, it represents the window's size the sender should use (credits). And on the data, it represents the window's size the sender is actually using. So why don't they match ? After receiving an ack, the window's size should be set the the received value, and then the next sent packet should piggyback this same value.

- read the definition of the window field in http://www.ietf.org/rfc/rfc793.txt and tell me why you think they should match.
Posted by Manuel Flury on Thursday 21 December 2006 at 17:33
Thanks for your replies, they solved all the problems I had to face yet.

P.S. for the win field, I just misunderstood its use...
Posted by René Giller on Tuesday 9 January 2007 at 14:45
you are welcome.
Posted by Manuel Flury on Tuesday 9 January 2007 at 16:28