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

[gvsm]

I think I have not drafted my question properly and hence restarting
the discussion.  Apologies ...

[1] I am going through a book on Network convergence which lists TRILL
as one of the enabling technologies and more specifically towards the
multipath offering of the protocol [Ref-1] and this is my source of
interest.

[2]I am aware of scope of TRILL. It has clearly stated that this would
introduce frame reordering.

   Multipathing of multi-destination frames through alternative
   distribution tree roots and ECMP (Equal Cost MultiPath) of unicast
   frames are supported (see Appendix C). Multipathing may introduce
   frame reordering as can differing frame priorities or changes in
   network topology.

[3] I think the frame ordering, if its not in the scope of TRILL, the
protocol needs to be extensible to support additional features of this
kind. I am not right? In my understanding Link aggregation works only
at Link level and may not be suitable enough for multipath. I think
though in theory it can be possible the use of Slow Protocols
Multicast address would prohibit in present form. Will this multicast
packets forwarded? I dont think so. There are studies of new protocols
to overcome this limitation[Ref-2].

All I was asking that is the protocol should be extensible for
features like this, something with "options".

Hope I am clear this time.

Thanks a lot,
venkatg

Ref-1 : Data center Networks and Fiber Channel over Ethernet by Silvano Gai
Ref-2 : High speed, Short Latency Multipath Ethernet Transport for
Interconnections, [
http://doi.ieeecomputersociety.org/10.1109/HOTI.2008.13&ei=d-j3SJ2pAaa0qAOS3tHtCg&sig2=UQ4ZsidRizrOTow70xQqdQ&ct=w
]




-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Dinesh G Dutt wrote:
> One more point. The TCP/IP RFCs don't talk about maintaining order
> either, but products do it.

TCP/IP does talk about NOT requiring order (sometimes referred to as
'sequencing') to be maintained, and explicitly require tolerating it at
the network layer:

791 - sec 1.2
793 - sec 1.5
1122 = sec 1.1.2
1812 - sec 2.2.1

Agreed that these RFCs don't focus on efficiencies afforded when packets
arrive in the order sent, but that's not what is being discussed here.

Joe

>> ---------- 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
>>
>>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjqk5IACgkQE5f5cImnZrtgNgCdF3sxWNIS2ZgMmWGuL5PV/25z
hF0AoKKoRZwwy7mDdhBo3VbwLCE3386g
=nMhu
-----END PGP SIGNATURE-----