[rbridge] PS issue #4

[Joe Touch]

-----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-----