Subject: [Softwires] packet reordering in MAP

From: "Poscic, Kristian (Kristian)" <[email-masked]>
Date: Sun, 31 Mar 2013 12:21:56 +0000

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 31 Mar 2013 13:45:10 +0100

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:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: "Poscic, Kristian (Kristian)" <[email-masked]>
Date: Sun, 31 Mar 2013 12:48:01 +0000

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-masked]] 
Sent: Sunday, March 31, 2013 5:45 AM
To: Poscic, Kristian (Kristian)
Cc: [email-masked]; [email-masked]
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.

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

---

From: Ted Lemon <[email-masked]>
Date: Sun, 31 Mar 2013 13:30:39 +0000

> better to send a packet out of order than to drop it?

Almost surely it is already too late to fix the brokenness that began when the translator allowed its buffer to get so full.   The internet is *supposed* to drop packets in the face of congestion!

(Sorry, I realize that's off-topic, but I couldn't let this pass unremarked.)

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 31 Mar 2013 15:51:28 +0100

Ted

> (Sorry, I realize that's off-topic, but I couldn't let this pass unremarked.)

Yes, there is certainly an interesting question about the trade-offs between
reordering and drops under congestion, but as far as this spec goes, the point
is that both can happen anyway, so imposing a MUST would be unreasonable.

    Brian

---

From: Ted Lemon <[email-masked]>
Date: Sun, 31 Mar 2013 14:56:08 +0000

> is that both can happen anyway, so imposing a MUST would be unreasonable.

Indeed so.