Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.txt

[Joe Touch <[e-mail]>]

Your intent is to thus reinvent the Internet over UDP, solely to get
around the fact that you don't have permission to do so otherwise?

Again, a very poor justification for this level of complexity. I don't
consider RFCs useful when they address only temporary concerns.

Joe

On 5/19/2016 2:59 PM, Tom Herbert wrote:
> On Thu, May 19, 2016 at 2:36 PM, Joe Touch <[e-mail]> wrote:
>> There are many ways to support user-land transport protocols (raw IP,
>> tun/tap devices, etc.) and some good reasons not to (lack of
>> coordination with kernel-based transports).
>>
> Raw IP and tun/tap require privileged access and as you mention
> requires coordination with kernel stack (if nothing else we need to
> deal with allocations in TCP tuple namespace). We have support for
> neither of those available in the application environment we need to
> run in.
>
>> IMO, adding a layer of encapsulation (and all that entails, including
>> the need for PLPMTUD, other ICMP signal relaying between layers, etc.)
>> is a very inefficient and complex way to overcome an implementation
>> convenience issue.
>>
> As far as the kernel is concerned this is just another UDP application
> so PMTU discovery and ICMP should work normally as long as the ICMP
> messages are sent pertaining to the UDP packet.
>
> It is true that if we run a TCP stack in userspace we lose quite a bit
> of efficiency compared to a stack running in kernel that is well
> integrated with lower layers, routing, NIC offloads, etc. (at my last
> count Linux TCP stack interacted with other layers and other parts of
> the kernel at about fifty different points). This is why I believe we
> want an asymmetric implementation. For our Internet clients we want to
> run the TCP stack as part of the application to achieve OS
> independence (from Android, iOS, etc.); on the server side where
> scalability is the primary issue I will use a modified kernel stack
> that implements TOU.
>
> Tom
>
>> Joe
>>
>> On 5/19/2016 12:39 PM, Tom Herbert wrote:
>>> The current use case we are developing is TCP over UDP. Our deployment
>>> scenario is that we want to embed a TCP stack in the client
>>> application (Facebook app in this instance), and will update out
>>> server stacks appropriately. With the transport stack under our
>>> control we can now modify it quickly and not depend on underlying OS
>>> to leak out features. An example feature that we'd like to have is TCP
>>> Fast Open (TFO). TFO was developed nearly five years ago, but we still
>>> cannot effectively use this because Android hasn't supported it.
>>> Once we control both the client and server stacks and don't need to
>>> worry to affects in the network of changing the transport protocol,
>>> implementing new features like TFO in a timely manner becomes
>>> feasible.