[rbridge] PS issue #4
touch at ISI.EDU
Wed Dec 7 12:12:14 PST 2005
-----BEGIN PGP SIGNED MESSAGE-----
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".
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the rbridge