Ok, this is exactly what I was looking for. Let me take a look at this. Thanks!
-----Original Message----- From: Brian E Carpenter [mailto:[email protected]] Sent: Sunday, March 31, 2013 5:45 AM To: Poscic, Kristian (Kristian) Cc: [email protected]; [email protected] Subject: Re: [BEHAVE] packet reordering in MAP Have a look at section 3.1.8 in RFC 6250, and there is a reference: Bennett, J., Partridge, C., and N. Shectman, "Packet reordering is not pathological network behavior", IEEE/ACM Transactions on Networking, Vol. 7, No. 6, December 1999. A UDP application that cannot tolerate reordering is broken. Since the Internet does not and cannot guarantee the order of delivery, I think the SHOULD is appropriate. For example, if a translator is almost out of memory, surely it is better to send a packet out of order than to drop it? Brian On 31/03/2013 13:21, Poscic, Kristian (Kristian) wrote: > Can someone share some history and research backed data behind this statement > at the very bottom of section 4 in RFC 6145 (IP/ICMP Translation Algorithm). > > The translator SHOULD make sure that the packets belonging to the > same flow leave the translator in the same order in which they > arrived. > > I'm wondering why would be acceptable for a box to reorder packets of the > same flow (SHOULD vs MUST)? > > While TCP can cope with reordering well (seq numbers plus TCP has MSS > mechanism to avoid fragmentation all together if the nodes in the path also > support MSS), I would think that (at least some) apps using UDP transport > would not tolerate packet reordering. > So I was hoping that someone can offer some references of real research > backed data rather than opinions (I would like to her opinions as well but > they often differ). > Even if you have ECMP in the network and if all the nodes in the end-to-end > path are performing per flow load balancing over ECMP links (which should be > the norm), packet reordering should not happen. > If nodes are performing per-packet load balancing over ECMP links then packet > reordering can occur but I would consider this bad practice (I know that some > old platforms would do per packet load balancing on ECMP links though). > > The reason I ask this is in the context of implementing > fragmentation/reassembly for MAP-E/T (although the issue extends beyond MAP). > For example in distributed platforms it would make sense to implement MAP > translation function in-line (in the forwarding cards) but the reassembly > function in the service cards since the reassembly function adds additional > complexity and buffering requirements (I understand that the fragmented > traffic is small percentage of all traffic, but still...). > Let say that a v6 packet arrives to a BR (from the CPE). > The BR will process this packet in-line and send it out as v4. > Then another number of fragmented packets of the same flow arrive -> the BR > process those in service blades (not in-line). > While service blade is processing the fragments (reassembling them), another > non-fragmented packet of the same flow arrives on the BR. > This packet is processed in-line and sent out before the previously received > fragments are reassembled in service blade. > Now the BR has caused packet re-ordering. > Why is this, according to RFC 6145) acceptable? > > Any feedback appreciated. > Kris > > > > > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > Behave mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/behave _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
