[rbridge] PS issue #4

[Gray, Eric]

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Joe Touch
--> Sent: Wednesday, December 07, 2005 3:12 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] PS issue #4
--> 
--> -----BEGIN PGP SIGNED MESSAGE-----
--> Hash: SHA1
--> 
--> 
--> 
--> Spencer Dawkins wrote:
--> > While looking at
--> > 
--> > #4 delivery requirements:
--> >    a) is in-order required?
--> >    b) is no-duplication required?
--> > 
--> > I tripped over some unexpected good news: IEEE 
--> 802.1D-2004 does seem to 
--> > understand that trading off in-order and no-duplication 
--> guarantees for 
--> > performance makes sense (ex. Section 6.3.3, "NOTE 2-Frame 
--> misordering and 
--> > duplication (6.3.4) does not occur during normal 
--> operation. When RSTP is 
--> > configuring or reconfiguring the network (see Clause 17), 
--> there is an 
--> > increased and implementation-dependent probability that 
--> frames that are in 
--> > transit will be misordered or duplicated as network paths 
--> change, since a 
--> > Bridge can buffer frames awaiting transmission through 
--> its Ports. Since the 
--> > probability of duplication or misordering occurring as a 
--> result of 
--> > reconfiguration is small, and the frequency of physical 
--> network failures 
--> > leading to reconfiguration is also generally small, the 
--> degradation of the 
--> > properties of the MAC service is considered to be negligible."
--> > 
--> > This was a huge improvement over the situation in IEEE 
--> 802.17/RPR several 
--> > years ago, when we assumed (IIRC, because we were 
--> explicitly told) that no 
--> > tradeoff was possible.
--> > 
--> > As the note goes on to say, there are LLC-level protocols 
--> that don't 
--> > tolerate out-of-order delivery, but anything running over 
--> TCP is protected 
--> > from misordering, and anything running over UDP should 
--> already be dealing 
--> > with reordering, so I think that for our purposes, we can 
--> say that meeting 
--> > these requirements in normal operation is "good enough".
--> 
--> Which requirement:
--> 
--> a) that reordering is a transient possibility
--> 
--> b) that persistent reordering is acceptable
--> 
--> The latter affects whether multipath forwarding is 
--> supported inside the
--> rbridge and whether it also requires reordering facilities 
--> at the egress.
--> 
--> > Although I'm getting off-topic, I note that letting TCPs 
--> see reordering 
--> > during path changes is not a bad thing, since it's a clue 
--> that available 
--> > path bandwidth may be changing...
--> 
--> The Internet doesn't tend to want to think a link layer has volatile
--> properties in general, though.
--> 
--> Joe
--> 
--> 
--> -----BEGIN PGP SIGNATURE-----
--> Version: GnuPG v1.2.4 (MingW32)
--> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
--> 
--> iD8DBQFDl0IeE5f5cImnZrsRAixWAJ4+GkRB1jnxDPbhmODpm1gjr1ywvACfdaQc
--> t1j8uOgMK1AYCKkRw3q+pps=
--> =Ode4
--> -----END PGP SIGNATURE-----
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->