Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

On Fri, Jun 24, 2016 at 5:01 PM, Rick Jones wrote: > On 06/24/2016 04:43 PM, Tom Herbert wrote: >> >> Here's Christoph's slides on TFO in the wild which presents a good >> summary of the middlebox problem. There is one significant difference >> in that ECN needs network

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

On Wed, Jun 22, 2016 at 12:23 PM, David Miller wrote: > From: Jerry Chu > Date: Tue, 21 Jun 2016 20:42:19 -0700 > >> I don't believe TOU will lead to a proliferation of TCP >> implementations in the userland - getting a solid TCP implementation >> is hard.

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

On 06/24/2016 04:43 PM, Tom Herbert wrote: Here's Christoph's slides on TFO in the wild which presents a good summary of the middlebox problem. There is one significant difference in that ECN needs network support whereas TFO didn't. Given that experience, I'm doubtful other new features at L4

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

On Fri, Jun 24, 2016 at 3:06 PM, Rick Jones wrote: > On 06/24/2016 02:46 PM, Tom Herbert wrote: >> >> On Fri, Jun 24, 2016 at 2:36 PM, Rick Jones wrote: >>> >>> How would you define "severely?" Has it actually been more severe than >>> for >>> say ECN?

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

On 06/24/2016 02:46 PM, Tom Herbert wrote: On Fri, Jun 24, 2016 at 2:36 PM, Rick Jones wrote: How would you define "severely?" Has it actually been more severe than for say ECN? Or it was for say SACK or PAWS? ECN is probably even a bigger disappointment in terms of

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

On Fri, Jun 24, 2016 at 2:36 PM, Rick Jones wrote: > On 06/24/2016 02:12 PM, Tom Herbert wrote: >> >> The client OS side is only part of the story. Middlebox intrusion at >> L4 is also a major issue we need to address. The "failure" of TFO is a >> good case study. Both the

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

On 06/24/2016 02:12 PM, Tom Herbert wrote: The client OS side is only part of the story. Middlebox intrusion at L4 is also a major issue we need to address. The "failure" of TFO is a good case study. Both the upgrade issues on clients and the tendency for some middleboxes to drop SYN packets

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

On Thu, Jun 23, 2016 at 12:50 AM, Richard Weinberger wrote: > Am 23.06.2016 um 09:40 schrieb David Miller: >> From: Richard Weinberger >> Date: Thu, 23 Jun 2016 00:15:04 +0200 >> >>> On Thu, Jun 16, 2016 at 7:51 PM, Tom Herbert

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

Am 23.06.2016 um 09:40 schrieb David Miller: > From: Richard Weinberger > Date: Thu, 23 Jun 2016 00:15:04 +0200 > >> On Thu, Jun 16, 2016 at 7:51 PM, Tom Herbert wrote: >>> Transports over UDP is intended to encapsulate TCP and other transport

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

From: Richard Weinberger Date: Thu, 23 Jun 2016 00:15:04 +0200 > On Thu, Jun 16, 2016 at 7:51 PM, Tom Herbert wrote: >> Transports over UDP is intended to encapsulate TCP and other transport >> protocols directly and securely in UDP. >> >> The

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

On Wed, Jun 22, 2016 at 3:15 PM, Richard Weinberger wrote: > On Thu, Jun 16, 2016 at 7:51 PM, Tom Herbert wrote: >> Transports over UDP is intended to encapsulate TCP and other transport >> protocols directly and securely in UDP. >> >> The goal

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

On Thu, Jun 16, 2016 at 7:51 PM, Tom Herbert wrote: > Transports over UDP is intended to encapsulate TCP and other transport > protocols directly and securely in UDP. > > The goal of this work is twofold: > > 1) Allow applications to run their own transport layer stack

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

From: David Ahern Date: Tue, 21 Jun 2016 22:06:01 -0600 > On 6/21/16 9:42 PM, Jerry Chu wrote: >> Yes TOU may lower the bar for random hacks by Joe Random. But I'd >> argue >> no large organization would serious consider or dare deploy TCP stack >> with random hacks. >

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

From: Jerry Chu Date: Tue, 21 Jun 2016 20:42:19 -0700 > I don't believe TOU will lead to a proliferation of TCP > implementations in the userland - getting a solid TCP implementation > is hard. The fear isn't doing legitimate things. It's making TCP stacks that do evil stuff

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

On Tue, Jun 21, 2016 at 8:42 PM, Jerry Chu wrote: > On Tue, Jun 21, 2016 at 1:29 AM, David Miller wrote: >> From: Tom Herbert >> Date: Mon, 20 Jun 2016 08:13:48 -0700 >> >>> Routing around the problem is already being done. >> >>

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

On 6/21/16 9:42 PM, Jerry Chu wrote: Yes TOU may lower the bar for random hacks by Joe Random. But I'd argue no large organization would serious consider or dare deploy TCP stack with random hacks. There are userspace network stacks that have been around for years and widely deployed on

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

On Tue, Jun 21, 2016 at 1:29 AM, David Miller wrote: > From: Tom Herbert > Date: Mon, 20 Jun 2016 08:13:48 -0700 > >> Routing around the problem is already being done. > > QUIC, a new protocol used for specific purposes and implemented in > userspace

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

On Tue, Jun 21, 2016 at 10:11 AM, Hannes Frederic Sowa wrote: > On 17.06.2016 20:52, Tom Herbert wrote: >> >>> > Rather, I think people are going to start adding rules to block TOU >>> > tunnels entirely because they cannot inspect nor conditionally >>> >

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

On 17.06.2016 20:52, Tom Herbert wrote: > >> > Rather, I think people are going to start adding rules to block TOU >> > tunnels entirely because they cannot inspect nor conditionally >> > filter/rewrite the contents. This is even more likely if Joe Random >> > and so easily can do their own

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

On 17.06.2016 09:51, Tom Herbert wrote: > On Thu, Jun 16, 2016 at 4:15 PM, Hannes Frederic Sowa > wrote: >> On 16.06.2016 19:51, Tom Herbert wrote: >>> Transports over UDP is intended to encapsulate TCP and other transport >>> protocols directly and securely in UDP.

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

From: Tom Herbert Date: Mon, 20 Jun 2016 08:13:48 -0700 > Routing around the problem is already being done. QUIC, a new protocol used for specific purposes and implemented in userspace from the start is significantly different from making the kernel's _TCP_ implementation

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

On Sun, Jun 19, 2016 at 8:07 PM, David Miller wrote: > From: Tom Herbert > Date: Fri, 17 Jun 2016 20:52:55 -0700 > >> For instance, TFO was put in the Linux several years ago, but it >> still hasn't been enabled in Android and only fairly recently >>

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

From: Tom Herbert Date: Fri, 17 Jun 2016 20:52:55 -0700 > For instance, TFO was put in the Linux several years ago, but it > still hasn't been enabled in Android and only fairly recently > enabled in iOS. "Android decided to get locked into a really old kernel for 6+

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

On Fri, 17 Jun 2016 20:52:55 -0700, Tom Herbert wrote: > > > We also now have to debug against every single userland TCP > > implementation someone can come up with, the barrier to entry is > > insanely low with TOU. Maybe this sounds great to you, but to me > > it is quite terrifying > > > No,

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

> We also now have to debug against every single userland TCP > implementation someone can come up with, the barrier to entry is > insanely low with TOU. Maybe this sounds great to you, but to me > it is quite terrifying > No, it doesn't sound great, but the major problem we have is that Android

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

From: Tom Herbert Date: Thu, 16 Jun 2016 10:51:54 -0700 > The goal of this work is twofold: > > 1) Allow applications to run their own transport layer stack (i.e.from >userspace). This eliminates dependencies on the OS (e.g. solves a >major dependency issue for

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

On Thu, Jun 16, 2016 at 4:15 PM, Hannes Frederic Sowa wrote: > On 16.06.2016 19:51, Tom Herbert wrote: >> Transports over UDP is intended to encapsulate TCP and other transport >> protocols directly and securely in UDP. >> >> The goal of this work is twofold: >> >> 1)

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

On 16.06.2016 19:51, Tom Herbert wrote: > Transports over UDP is intended to encapsulate TCP and other transport > protocols directly and securely in UDP. > > The goal of this work is twofold: > > 1) Allow applications to run their own transport layer stack (i.e.from >userspace). This

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

On 06/16/2016 10:51 AM, Tom Herbert wrote: Note that #1 is really about running a transport stack in userspace applications in clients, not necessarily servers. For servers we intend to modified the kernel stack in order to leverage existing implementation for building scalable serves (hence

[PATCH net-next 0/8] tou: Transports over UDP - part I

Transports over UDP is intended to encapsulate TCP and other transport protocols directly and securely in UDP. The goal of this work is twofold: 1) Allow applications to run their own transport layer stack (i.e.from userspace). This eliminates dependencies on the OS (e.g. solves a major