Subject: [BEHAVE] NAT64: Out of order session handling

From: Simon Perreault <[email-masked]>
Date: Fri, 19 Feb 2010 09:33:25 -0500

Hello,

Two questions:

- Does NAT64's session handling work with packets arriving out of order? 
I'm not talking about fragments here.

- Is a NAT64 allowed to reorder packets?

Thanks,
Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 19 Feb 2010 16:21:25 +0100

El 19/02/10 15:33, Simon Perreault escribió:
> Hello,
>
> Two questions:
>
> - Does NAT64's session handling work with packets arriving out of 
> order? I'm not talking about fragments here.
>
you mean TCP 3 way handshake arriving in the wrong order?
or soemthing else?

> - Is a NAT64 allowed to reorder packets?
Not sure why it would do that... the draft doesn't explicitly frbids 
that, but it probably should i guess

Regards, marcelo

---

From: Simon Perreault <[email-masked]>
Date: Fri, 19 Feb 2010 10:43:39 -0500

> you mean TCP 3 way handshake arriving in the wrong order?

Any kind of reordering. I haven't studied the possible cases in detail. 
I mean, take a look at RFC 793:

   Reliability:

     The TCP must recover from data that is damaged, lost, duplicated, or
     delivered out of order by the internet communication system.  This
     is achieved by assigning a sequence number to each octet
     transmitted, and requiring a positive acknowledgment (ACK) from the
     receiving TCP.  If the ACK is not received within a timeout
     interval, the data is retransmitted.  At the receiver, the sequence
     numbers are used to correctly order segments that may be received
     out of order and to eliminate duplicates.

Since our state machine is not exactly that of a real TCP endpoint, do 
we have the same reliability with regard to reordering or not? Has 
thought been given to this?

> that, but it probably should i guess

Here's a hint: multi-threading

Simon

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 19 Feb 2010 17:24:29 +0100

El 19/02/10 16:43, Simon Perreault escribió:
> Any kind of reordering. I haven't studied the possible cases in 
> detail. I mean, take a look at RFC 793:
>
>   Reliability:
>
yes, i did some thought on this (not sure if that is enough though)

So, afaict, the order of packets is irrelevant (meaning that don't 
affect nat64 behaviour) for all cases except for the 3 way handshake.
in the 3 way handshake case, we probably need to understand it more, but 
reordering of the 3 way handshake would only happen with retrial, so it 
is not really reordering, but handling duplicates, which i think are 
properly handled (we do support TCP SO)

So, do you have any scenario in mind where there can be problem?
> Here's a hint: multi-threading
do you think we should mention something?

Regards, marcelo

---

From: Simon Perreault <[email-masked]>
Date: Fri, 19 Feb 2010 11:38:28 -0500

> properly handled (we do support TCP SO)

Thanks.

> So, do you have any scenario in mind where there can be problem?

No, nothing specific at this point.

> do you think we should mention something?

First, I don't know if it should go into the stateful or stateless 
document, or both.

Second, how about "Translation MAY reorder packets."?

Thanks,
Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Feb 2010 10:03:20 +1300

On 2010-02-20 05:38, Simon Perreault wrote:
...
> First, I don't know if it should go into the stateful or stateless

imho, stateless (and if I am not mistaken about the normative
dependency, it then also automatically applies to stateful).

Reason: we really need the same behaviour in all translators.

> Second, how about "Translation MAY reorder packets."?

Disagree. Reordering is generally evil and should be avoided as
much as possible, because it damages TCP performance and can do even
worse things to UDP streams. So I think we should invert this and
say

Translators SHOULD be designed to avoid packet reordering as much
as possible.

If you want to multithread, that means selecting a thread
according to some sort of hash of the 5-tuple (IPv4) or
6-tuple (including flow label) for IPv6. I don't see it as
different from any other load balancing mechanism.

    Brian

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Fri, 19 Feb 2010 13:24:02 -0800

With stateless, theoriticaly two packets of the same flow can go through
two different translators and make it to the end point, can it not? How
can the translator keep track of the ordering of the packets? 
Stateless is a little different, but even there, except for the initial
handshake the packets can come through in different order and you cant
hold on to a packet in the translator and order them. I think this is
best left undefined and left to the end point application and translator
implementation. Do we know of any application that would fail if the
translator doesn't send the packets in the right order? 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian E Carpenter
Sent: Friday, February 19, 2010 4:03 PM
To: Simon Perreault
Cc: [email-masked]
Subject: Re: [BEHAVE] NAT64: Out of order session handling

> Second, how about "Translation MAY reorder packets."?

Disagree. Reordering is generally evil and should be avoided as much as
possible, because it damages TCP performance and can do even worse
things to UDP streams. So I think we should invert this and say

Translators SHOULD be designed to avoid packet reordering as much as
possible.

If you want to multithread, that means selecting a thread according to
some sort of hash of the 5-tuple (IPv4) or 6-tuple (including flow
label) for IPv6. I don't see it as different from any other load
balancing mechanism.

    Brian

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Xing Li <[email-masked]>
Date: Sat, 20 Feb 2010 10:38:55 +0800

Senthil Sivakumar (ssenthil) 写道:
> Stateless (stateful?) is a little different, but even there, except for the initial

Agree. Stateless translator should behave like a router when dealing 
with L4 and above. xing

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Feb 2010 16:56:19 +1300

> Agree. Stateless translator should behave like a router when dealing

It shouldn't try to do *better* than a router, that would be
pointless. So I'm not saying it should attempt to correct
misordering, and *obviously* we can't solve the problem of a
given packet flow being split across two stateless translators,
exactly because they are stateless.

What I proposed does not attempt to do that. It addreses exactly
the case that Simon raised: a translator (stateful or stateless)
that wants to multithread. And the solution (such as a 5-tuple or
6-tuple hash) should be stateless too.

     Brian

---

From: Xing Li <[email-masked]>
Date: Sat, 20 Feb 2010 13:39:14 +0800

> 6-tuple hash) should be stateless too.

Then we may add a paragraph in section 1.2 of xlate, mention

a translator that wants to multithread should avoid changing the order 
of the packets.

Is this the correct understanding? Do you have a suggested wording? Thanks.

Regards,

xing

---

From: Simon Perreault <[email-masked]>
Date: Sat, 20 Feb 2010 09:46:33 -0500

> Is this the correct understanding? Do you have a suggested wording? Thanks.

It's not perfect because it mentions "multithreading", which is an
implementation detail. Only externally-observable behaviour should be
part of the spec.

Thanks,
Simon
-- 
DNS64 open-source   --> http://ecdysis.viagenie.ca
STUN/TURN server    --> http://numb.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Sun, 21 Feb 2010 18:42:28 -0800

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Simon Perreault
Sent: Saturday, February 20, 2010 9:47 AM
To: [email-masked]
Subject: Re: [BEHAVE] NAT64: Out of order session handling

> Translators SHOULD be designed to avoid packet reordering as much as 

[Senthil] This text, IMO, is not implementable. The translator cannot
avoid reordering
unless it keeps track of ordering. It cannot order if the packets are
going through different translators. 
I don't know how to quantify "as much as possible", under what
conditions it is ok to reorder?
Instead something like this could be more useful.
"Translator should make sure that the packets leave the translator in
the same order in which they arrived".

But this will have some issues with translators doing ALG functionality,
but that would be a separate discussion.

Senthil

Thanks,
Simon

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Sun, 21 Feb 2010 18:45:04 -0800

Corrected text below. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Senthil Sivakumar (ssenthil)
Sent: Sunday, February 21, 2010 9:42 PM
To: Simon Perreault; [email-masked]
Subject: Re: [BEHAVE] NAT64: Out of order session handling

-----Original Message-----

[Senthil] This text, IMO, is not implementable. The translator cannot
avoid reordering unless it keeps track of ordering. It cannot order if
the packets are going through different translators. 
I don't know how to quantify "as much as possible", under what
conditions it is ok to reorder?
Instead something like this could be more useful.
"Translator should make sure that the packets leave the translator in
the same order in which they arrived".

[Senthil] Should be, 
"Translator should make sure that the packets belonging to the same flow
leave the translator in the same order in which they arrived".

Senthil

Thanks,
Simon

---

From: Kentaro Ebisawa <[email-masked]>
Date: Mon, 22 Feb 2010 12:52:08 +0900

Hi,

> but that would be a separate discussion.

I think exception to this is when handling fragmented packets.
In compliance to Section 3.4. Page 19, implementation should have
freedom to queue and sort fragments in order or translate packets
as they arrive.

Thanks,
-- 
Kentaro Ebisawa <[email-masked]>

On Sun, 21 Feb 2010 18:45:04 -0800

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 22 Feb 2010 00:03:05 -0500

I think this text is fine.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 22 Feb 2010 08:11:00 -0500

On 2010-02-22 00:03, Reinaldo Penno wrote:
> On 2/21/10 6:45 PM, "Senthil Sivakumar (ssenthil)"<[email-masked]>
> wrote:
>
>> [Senthil] Should be,

+1 with s/should/SHOULD/

Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Feb 2010 09:44:51 +1300

> freedom to queue and sort fragments in order or translate packets

That's why it can only be a SHOULD and not a MUST.

I'm fine with Senthil's version; obviously one stateless translator
cannot guess what is happening in another one, or what has happened
in the past.

    Brian

---

From: "David Harrington" <[email-masked]>
Date: Mon, 22 Feb 2010 19:30:09 -0500

> > Translators SHOULD be designed to avoid packet reordering as much

doesn't "Translators SHOULD be designed to avoid packet reordering"
suffice?
or even "Translators SHOULD avoid packet reordering"?

dbh

---

From: Xing Li <[email-masked]>
Date: Tue, 23 Feb 2010 14:29:45 +0800

> cannot guess what is happening in another one, or what has happened

Thanks. xing