Subject: [rbridge] PS issue #4

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Thu, 8 Dec 2005 11:38:34 -0500

Spencer, et al,

Once upon a time, some "higher layer" communication protocols treated
out of order delivery as a communication failure.  For such protocols,
even transient out of order delivery would be unacceptable.

However...

As far as I know, the increasingly common assumption that occasional 
out of order delivery is okay has not led to a lot of loud complaints,
so it is possibly safe to assume that out of order delivery during a
network transient condition is okay for all currently in use "higher
layer" communication protocols.

However, the comment below that persistent out of order delivery must
be okay if we want to allow multiple path use is simply not true.

As has been said on this list before, even though many "higher layer" 
protocols can handle out of order delivery, practically all of them -
most notably including TCP/IP - are optimized for in order delivery.

Consequently, concepts like "link bundling" and ECMP have long taken
this into account and employ any of a number of techniques to ensure
that streams of packets (or frames) from any given source to a given
destination are not persistently delivered over variable paths.

Since using multiple paths across an Ethernet network is precisely
analogous to link bundling, clearly the same techniques apply in the
TRILL/RBridge case as well.

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