Re: [arch-d] FYI: closure of the IAB Stack Evolution program

> On Aug 23, 2019, at 4:27 AM, Fernando Gont <fgont@si6networks.com> wrote:
> 
> On 23/8/19 13:19, Brian Trammell (IETF) wrote:
> [....]
>>>> 
>>>> That has changed. QUIC has demonstrated that it is possible to
>>>> deploy a new transport protocol at scale, and the QUIC WG has
>>>> nearly finished an IETF standard version of that protocol.
>>> 
>>> I'm certainly not much of a QUIC expert, but... isn't QUIC tunneled
>>> over UDP?
>>> 
>>> If so, then deployment of QUIC doesn't prove that it's possible to 
>>> deploy new transport protocols in the big-I Internet. Actually,
>>> the decission to make QUIC run over UDP would seem to me quite the
>>> opposite: that you cannot deploy a new transport prootocol
>>> natively, and thus need to tunnel it on something that actually is
>>> known to work (TCP or UDP).
>> 
>> This is a well known discussion rabbithole, but.. no, QUIC is not
>> tunneled over UDP, it uses a UDP header as an encapsulation but is a
>> distinct transport protocol on its own.
> 
> Yes, you are tunneling one transport protocol into another. You could
> have also tunneled on QUIC on top of TCP.

It may become clearer if we look at what elements make up the various protocols.

In a typical HTTP/2 stack, you would see the following (I'm simplifying, of course):

HTTP/2: Application stream multiplexing + message encoding
TLS: Encryption/authentication
TCP: Port demultiplexing + reliability + congestion control
IP: Addressing

With HTTP/3 (the one over QUIC), you would see the same roles divided up differently:

HTTP/3: Message encoding
QUIC: Application stream multiplexing + encryption/authentication + reliability + congestion control
UDP: Port demultiplexing
IP: Addressing

UDP alone is being used as a common way to encode port fields; it's not providing true transport functionality. Moving QUIC over TCP, on the other hand, is just like tunneling TCP over TCP, and comes with the many costs and caveats of multiple layers of reliability, congestion control, etc.

Thanks,
Tommy

> 
> 
> 
>> You're right that we can't
>> deploy new *headers* in the Internet because of middleboxes, but a
>> key insight behind QUIC is that you can run a new protocol over old
>> headers.
> 
> I guess I'm missing something here, but: isn't this the sort of thing we
> have been doing for ages? e.g., we tunnel IPsec over UDP (e.g. RFC3948)
> because of middleboxes, and I seem to remember being told that SCTP is
> also run at times over UDP.
> 
> (at times we even go up even one more layer, and tunnel over HTTPS, when
> that's the only thing that works).
> 
> 
>> I would argue that thinking of UDP as a transport protocol is itself
>> a mistake; it is a UNIX sockets model friendly way to allow
>> applications to access an IP datagram service in a multiuser
>> environment. But I think I'm in the minority there.
> 
> What would be the rationale for not considering UDP a transport protocol
> -- albeit one providing unreliable service?
> 
> 
> Thanks,
> -- 
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
> 
> 
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss