Re: [Softwires] [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
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave