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

[Joe Touch <[e-mail]>]

On 5/19/2016 5:13 PM, Toerless Eckert wrote:
> On Thu, May 19, 2016 at 03:21:18PM -0700, Joe Touch wrote:
>> At some point, when the version of TCP you want is in the kernel, you'll
>> want to transition. That begs the question of demuxing incoming
>> services, and whether the kernel peeks into the packet to send them to
>> the right place (which might be at a different port inside the kernel).
> Nah. Thats where i started off from as well. But then think about you having
> this wonderful application that started out with a cool & better TCP stack.
> Maybe the kernel catches up some time to do exactly what you want. But it
> could equally evolve into soment which may be better but not really for
> your application - at least not without improving/changing your app.
>
> If i want to deploy one binary of an app and let it run stable, kernel changes
> are the worst thing that can happen to me. Having my transport stack in my
> app is a godsend to decouple me from this.
I don't disagree with the potential benefits. I disagree with using UDP
encapsulation to achieve an end-run around the OS exerting control.

> Why do apps want containers ? To decouple them from the variability of userland.
Hmm. So containers are good, but doing a full hypervisor with an
(encapsulated) OS isn't as good?

See the analogy? You're arguing for user access to rawIP.


> ...
>> I'm confused now; above you assumed IPv6. Now you're comparing UDP/IPv4
>> vs. IPv6?
> No, i am saying that a loss in packet efficiency (sizze of header) did not
> stop us to do IPv6, it shouldn't stop us to run transport over UDP.
I wasn't arguing solely on the basis of the additional bytes. It's the
additional protocol layer that is expensive.

...
>> I'm not in favor of creating a mess for the future for a little
>> short-term benefit. Effort would be better spent getting the desired
>> features into these OS transport implementations.
> This is really a matter of lifecycle management of software. And you do NOT
> want to get all "desired" features into OS implementations.
OK, so put differently, I don't want to create a mess in the Internet to
fix an OS problem. The OS problem is lack of access to raw IP. If you
had that, you wouldn't need any of this.

That's a simple direct target. A lot simpler than untangling the mess
that this reinvention will cause.

Joe