Re: [BEHAVE] (no subject)

[Simon Perreault <[e-mail]>]

Le 2013-06-27 16:17, ivan c a écrit :
>> My point is that UDP and TCP are not different from the point of view of
>> the NAT w.r.t. port preservation, since applications routinely call
>> connect() on UDP sockets and it is entirely possible that two UDP
>> sockets share the same local endpoint. POSIX standards have nothing to
>> do with it.
>
> It has everything to do with POSIX standards. Options that are outside the
> POSIX standards are usually quite flaky. See the shortcomings of the
> SO_REUSEADDR option that I mention in my previous post.
> I also totally agree that: UDP and TCP are not different from the point of
> view of the NAT w.r.t. port overloading (i assume you meant port
> overloading, you wrote "port preservation")

No, I meant port preservation. I'm having a hard time following, and I 
thought that the UDP-vs-TCP distinction was w.r.t. port preservation.

> It's just that applications usually use many more TCP local endpoints than
> UDP ones. See bittorrent and all others, empirical observations. So if
> there is a shortage of internal endpoints, it's more likely to happen for
> TCP. But it can also happen for UDP, i totally agree.

Fully agree.

>> The functionality is available on many (all?) platforms, and
>> applications use it.
>
> Which applications use it for TCP? Reference needed.

By "it", I was referring to "the ability to open multiple sockets bound 
to the same client endpoint". With TCP, applications do it by default.

> SO_REUSEADDR is not needed on UDP anyway since you can already multiplex
> multiple sessions over the same UDP socket. Applications can still use it
> for pure convenience though, i agree, your previous post being a nice
> illustration of this use case.

Exactly. My point is that UDP applications do sometimes create 5-tuples 
sharing the same local 3-tuple. Empirically we see that it is a minority 
of the traffic, but the functionality is there, is being used, and needs 
to be considered in the recommendations for NAT that we end up writing.

Simon