Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD BoF

[Tom Herbert <[e-mail]>]

On Tue, May 24, 2016 at 1:13 AM, Mirja Kühlewind
<[e-mail]> wrote:
> Hi Tom,
>
>> Am 24.05.2016 um 09:57 schrieb Brian Trammell <[e-mail]>:
>>
>>> I suppose it's a natural inclination to try to mimic TCP semantics
>>> because of its pervasiveness, but if things already work well enough
>>> then I don't see what problem it solves. The addition of such
>>> signaling increases the complexity of the protocols, the networking
>>> stack, network devices, and creates yet another opportunity for
>>> ossification.
>
> The problem is it only works for what we have right now. It works less well for new things which is a pity… it’s ossified. Yes, adding more stuff will make it more complex; I guess that’s a general case but I don’t think is an argument to stop trying to solve the problem. And also yes, it might get ossified again, but if we do it right this time, I want it to get ossified and settle as a common base for new protocols to get (more quickly and at all) deployed.
>

Mirja,

I will argue that what we have does not work right now. If a NAT state
is evicted in a network device then that means we lose the TCP
connection often without any notification. This has forced widespread
use of NAT keepalives which are basically junk packets sent into the
Internet that serve no other purpose than keep NAT state fresh. This
is a real problem especially on mobile devices where we waking up a
transmitter to send a keepalives is drain on the battery.

A proposed solution to this is what I'm calling "disassociated
location" (described in draft-herbert-transports-over-udp-00 and
borrowed from QUIC). The idea is that the endpoints do not use the IP
addresses and port numbers to identify a connection, they instead use
connection identifiers that are negotiated between the two endpoints
to be unique the other connections in the nodes. With this method, I
believe that connections can survive a NAT eviction. So if a
connection goes idle we no longer have to worry about maintaining NAT
state (presuming the client is the one that initiates requests). And
when an idle client wakes up it can assume that the NAT state has
timed so it may as well use new port numbers and new flow identifiers;
to the network this looks like a completely new flow (good for
security), but to the transport endpoints it is a continuation of an
established connection.

Similarly this should resolve the multi-homing/mobility issue.
Currently, if the path of a connection changes and packets are routed
through a different NAT device we lose the connection. With a
transport over UDP and disassociated location the connection remains
viable in that scenario.

This model only assumes typical UDP-NAT behavior in the network (like
in RFC4787) and does not require any new "path layer" protocol. I
don't see how exposing connection state can help here, and honestly I
wouldn't even know how to set it-- during the lifetime of one
connection it would be seen by the network to be different flows at
different times and (hopefully) would be unable deduce that these
refer to the same transport layer connection.

Tom

> Mirja
>
>
>