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 support whereas TFO didn't.
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.
>
> The fear isn't doing legitimate thin
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 co
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? Or it was for say SACK or PAWS?
>>>
>> ECN
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 seeing
deployment :-( Fr
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 upgrade issues on client
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 with
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 wrote:
Transports over UDP is intended to encapsulate TCP and o
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
>>> protocols directly and securely in UDP.
>>>
>>>
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 goal of this work is twofold:
>>
>> 1) Allow applica
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 of this work is twofold:
>>
>> 1) Allow applications
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 (i.e.from
>userspace). T
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.
>
> There are userspace netw
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 on purpose.
Also,
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.
>>
>> QUIC, a new protocol used for specific purposes and implemented in
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 device
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 from the start is significantly different from
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
>>> > filter/rewrite the contents. This is even
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 userl
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.
>>>
>>> The goal of this work 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 bypassed into a userspa
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
>> enabled in iOS.
>
> "Android decided to get lo
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+ years"
is not really a good
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,
> 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 a
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 Facebook on clients).
Cli
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) Allow applications to run the
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 elimina
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 the
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 dep
30 matches
Mail list logo