[rbridge] Fwd: In-order delivery not an issue?
Caitlin.Bestler at neterion.com
Mon Oct 6 12:11:04 PDT 2008
> From: Venkatsubramaniyan G, TLS-Chennai <venkatg at hcl.in>
> Date: Mon, Oct 6, 2008 at 7:21 PM
> Subject: RE: [rbridge] In-order delivery not an issue?
> To: rbridge at postel.org, Radia Perlman <Radia.Perlman at sun.com>
> Cc: gvsm <g.venkatasubramaniyan at gmail.com>
> Assuming a traffic flow (of given SRC, DST and QoS) happens through
> multiple equal cost paths in Rbridge cloud, I think TRILL cannot not
> offer guarantees that the frames at egress are in the same order as in
> ingress in Layer-2. The individual paths can have different traffic
> conditions and reaction mechanisms which may not give in-order
> behavior, which could largely vary.
> At present it is assumed this is left for ES ('s higher layer) to
> handle out-of-order packets.
I do not believe that is an accurate characterization of Appendix C.
There it states that the mechanism(s) used to ensure that conversations
are not mis-ordered by ECMP is "out of scope".
When multipathing is used, frames that follow different paths will be
subject to different delays and may be re-ordered. While some
traffic may be order/delay insensitive, typically most traffic
consists of flows of frames such the re-ordering within a flow is
damaging. How to determine flows or what granularity flows should
have is beyond the scope of this document but, as an example, under
many circumstances it would be safe to consider all the frames
flowing between a particular pair of end station ports to be a flow.
It might be useful to explicitly state that any flow considered to be
a "conversation" for 802.3ad purposes SHOULD be similarly treated by
any RBRidge implementing multi-pathing. But such a statement is only
making explicit what I think is already clearly the intent.
More information about the rbridge