[rbridge] Fwd: In-order delivery not an issue?

Mon Oct 6 21:47:17 PDT 2008

Dinesh,

What you are saying is perfectly fine with IP and TCP. But Ethernet is a layer 2 (link layer) protocol. In steady state, Ethernet always delivers packets in order. There are occasional packet losses but not out-or-order packet delivery.

802.3ad mandates in-order delivery for packets belonging to a conversation. In similar lines, TRILL can maintain in-order deliver *only* for packets belonging to a CONVERSATION (by taking the same path), which in our case can loosely be defined as packets from a Source to Destination machine.

Regards,
Ravi

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Dinesh G Dutt
Sent: Tuesday, October 07, 2008 4:01 AM
To: G.Venkatasubramaniyan
Cc: rbridge at postel.org
Subject: Re: [rbridge] Fwd: In-order delivery not an issue?

Venkat,

Think about how in-order delivery guarantees are offered within IP
today. Even TCP does not like dealing with out of order frames without
suffering loss of throughput.

What is done is that we send all frames associated with a flow (and
different products have different definitions of flow, ranging from {DA,
SA, VLAN} to the full 5 TCP/IP tuple and more) on the same path thereby
guaranteeing in order delivery for that flow, in steady state. AFAIK,
there is no requirement for the network to maintain order across flows.

Dinesh
 G.Venkatasubramaniyan wrote:
> resending my previous mail ...
> Thanks,
> venkatg
> ---------- Forwarded message ----------
> 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>
>
>
>
> Radia,
>
> 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.
>
> If this needs to be handled inside TRILL, there may be a need for
> seq-numbering the packets for each flow inside the TRILL cloud. Is it
> not?
> It may also need an elaborate session management and control protocols
> between ingress R-Bridge and egress R-Brdge, so that in-order is
> guaranteed.
>
>
> BTW, do not 802 solutions in *steady state* give in-order delivery for a
> given flow?
>
> Thanks a lot,
> Venkatg
>
> -----Original Message-----
> From: Radia Perlman [mailto:Radia.Perlman at sun.com]
> Sent: Monday, October 06, 2008 1:10 PM
> To: gvsm
> Cc: rbridge at postel.org; Venkatsubramaniyan G, TLS-Chennai
> Subject: Re: [rbridge] In-order delivery not an issue?
>
> TRILL ought to do in-order delivery, except with an occasional out of
> order packet in very rare cases. The 802 solutions also, with low
> probability, will occasionally reorder packets. Perhaps one could argue
> that the probability
> might be slightly larger with TRILL, but in either case it will be "very
>
> rare".
>
> Certainly we took the desire for in-order delivery into account in the
> design of TRILL.
>
> Radia
>
>
> gvsm wrote:
>
>> Hi,
>>
>> Does not present Ethernet by STP families give inorder delivery of
>> frames for a flow?
>> Will not this be compromised with this(TRILL) solution or is it
>> assumed implementation would take care of it?
>>
>> Thanks,
>> venkatg
>> _______________________________________________
>> rbridge mailing list
>> rbridge at postel.org
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>
>>
>
>
> DISCLAIMER:
> -----------------------------------------------------------------------------------------------------------------------
>
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only.
> It shall not attach any liability on the originator or HCL or its
> affiliates. Any views or opinions presented in
> this email are solely those of the author and may not necessarily
> reflect the opinions of HCL or its affiliates.
> Any form of reproduction, dissemination, copying, disclosure,
> modification, distribution and / or publication of
> this message without the prior written consent of the author of this
> e-mail is strictly prohibited. If you have
> received this email in error please delete it and notify the sender
> immediately. Before opening any mail and
> attachments please check them for viruses and defect.
>
> -----------------------------------------------------------------------------------------------------------------------
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>

--
We make our world significant by the courage of our questions and by
the depth of our answers.                               - Carl Sagan

_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***