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

[Ca By <[e-mail]>]

On Thursday, May 19, 2016, Joe Touch <[e-mail]> wrote:

> 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
>
>
+1 for joe.

This and similarly quic are creating an arms race.

These things wont stop, and the next step is your local middle box provider
requiring users to install their mitm cert :(

We already saw this this "http trusted proxies"


> On 5/19/2016 2:59 PM, Tom Herbert wrote:
> > On Thu, May 19, 2016 at 2:36 PM, Joe Touch <[e-mail] <javascript:;>>
> 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.
>
> _______________________________________________
> Spud mailing list
> [e-mail] <javascript:;>
> https://www.ietf.org/mailman/listinfo/spud
>