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

[Toerless Eckert <[e-mail]>]

Thanks, Joe, inline

On Fri, May 20, 2016 at 10:22:08AM -0700, Joe Touch wrote:
> On 5/19/2016 6:24 PM, Toerless Eckert wrote:
> > On Thu, May 19, 2016 at 06:06:11PM -0700, Joe Touch wrote:
> >> I don't disagree with the potential benefits. I disagree with using UDP
> >> encapsulation to achieve an end-run around the OS exerting control.
> > Don't think of it as UDP. Think of it as creating multiple layers inside the current
> > transport layer. The lowest layer is demultiplexing. Architecturally very clean.
> Here's why it's not:
> 
> TCP isn't a layer by itself; it relies on the IP pseudoheader.

Ack.

> TCP in UDP in IP is architecturally incomplete.

Right. but i am claiming that is possible and not too difficult. Eg:
remove TCP header port fields, just rely on UDP port fields, adopt
pseudoheader rules for TCP/UDP, etc. pp.

> TCP in IP in UDP in IP would be fine, as would TCP in IP in IP. But we
> already have those.
> That's why we don't need this and why it's a mess.

Still not clear how you jump from architectural incomplete to "no need, it's a mess".

> That's also why other tunnels - which encapsulate transport through net
> or link inside transport, net, or link - are much more architecturally
> clean and have not generated this reaction.

I think network layer overlay solutions are architecturally fare less clean
that modularizing the transport layer and cleaning up historic dependencies
against network layer.

Toerless