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

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Fri, 23 Aug 2019 11:07:18 +0200

Greetings, all,

During the IETF 105 meeting in Montreal, the IAB decided to close the Stack Evolution program in its present form. 

The initial concept behind the IP Stack Evolution program was to investigate how changes to the whole stack, especially to the transport layer, could be deployed in the big-I Internet, and explore the impact of encryption at the transport layer on evolution of the stack. At the time the program started in 2014, there was not much work yet in and around the IETF in this space. 

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. TAPS was chartered, and is well on its way to defining an abstract interface that reduces the rigidness of the binding between interfaces and transports. Conversations (many conversations) have started about the balance between measurability and confidentiality, and some of these have found shape in protocols (e.g., in the form of the QUIC spin bit).

The discussion isn't over, though; the appropriate place for further discussion on stackevo's topics (or adjacent ones) is here, on the architecture-discuss list.

Thanks, cheers,

Brian (for the former IAB Stack Evolution Program)

---

From: Fernando Gont <[email-masked]>
Date: Fri, 23 Aug 2019 13:15:48 +0300

Hi, Brian,

Thanks for the note! In-line...

On 23/8/19 12:07, 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).

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Fri, 23 Aug 2019 12:19:32 +0200

hi Fernando,

> On 23 Aug 2019, at 12:15, Fernando Gont <[email-masked]> wrote:
> 
> Hi, Brian,
> 

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. 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 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.

Cheers,

Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 23 Aug 2019 13:00:04 +0200

Le 23/08/2019 à 12:19, Brian Trammell (IETF) a écrit :
>>> During the IETF 105 meeting in Montreal, the IAB decided to
>>> close the Stack Evolution program in its present form.
>>> 
>>> The initial concept behind the IP Stack Evolution program was to 
>>> investigate how changes to the whole stack, especially to the 
>>> transport layer, could be deployed in the big-I Internet, and 
>>> explore the impact of encryption at the transport layer on 
>>> evolution of the stack. At the time the program started in 2014, 
>>> there was not much work yet in and around the IETF in this 
>>> space.
>>> 
>>> 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?
>> 
>>  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.

Sorry - it makes little sense.

Or maybe we dont understand the same thing by 'being tunneled' over
something.

In my view, once there is an additional header that makes if for being
tunneled.

That additional header could be IP, UDP, TCP or even a Routing Header.

I replied to this email because it popped into my regular inbox, not
being catched by the normal filters.  I dont understand why.

> 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.

That is nothing new.  There are so many people that run new protocols 
over old headers without even telling about this to other people.

> 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.

It is an interesting view of thinking of UDP being more of a UNIX 
sockets model rather than a transport protocol.  In that sense, I also 
see the raw sockets to be more powerful than UDP.  And there is more.

Alex

> 
> Cheers,
> 
> Brian
> 
>> Thanks, -- Fernando Gont SI6 Networks e-mail: [email-masked]
> _______________________________________________ Architecture-discuss 
> mailing list [email-masked] 
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>

---

From: Fernando Gont <[email-masked]>
Date: Fri, 23 Aug 2019 14:27:18 +0300

On 23/8/19 13:19, Brian Trammell (IETF) wrote:
[....]
>> I'm certainly not much of a QUIC expert, but... isn't QUIC tunneled
>> over UDP?
>> 

Yes, you are tunneling one transport protocol into another. You could
have also tunneled on QUIC on top of TCP.

> 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).

> 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,

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 23 Aug 2019 08:07:44 -0700

> On Aug 23, 2019, at 4:27 AM, Fernando Gont <[email-masked]> wrote:
> 

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

> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Fri, 23 Aug 2019 18:19:23 +0300

Hi, Tommy,

>> On 23/8/19 13:19, Brian Trammell (IETF) wrote:
[...]
> 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 com…

I go back to my original question: what functionality do you expect a
transport protocol to ahve to call it a "transport protocol"?

I agree that UDP provides probably implements very simply transport
functionality. However, I fail to see why one wouldn't call it a
transport protocol.

(Some folks might exèct congestion control at the network layer... still
we call IP an Internet Protocol...)

Thanks,

---

From: Chris Morrow <[email-masked]>
Date: Fri, 23 Aug 2019 18:48:05 +0000

On Fri, 23 Aug 2019 15:19:23 +0000,

> functionality. However, I fail to see why one wouldn't call it a

I had figured quic was really an admission that: "Adding a new tcp/udp
like protocol was much harder to swallow for the internet than just
re-using an existing thing (UDP)."

quic COULD have just as easily been done over tcp, esp, ah, icmp ...
all of those come with some baggage though, which UDP didn't have.
(admittedly udp has it's own baggage)

---

From: Ted Hardie <[email-masked]>
Date: Fri, 23 Aug 2019 13:28:43 -0700

Howdy,

> (admittedly udp has it's own baggage)

Changing TCP behavior on most systems requires modifying the kernel.
Having something built so that it could be modified in user space really
was important.  UDP is just a demux for QUIC and that's a success because
it enabled all of the other functionality to go up into the user space.

Just my perspective,

Ted

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 23 Aug 2019 13:40:54 -0700

> On Aug 23, 2019, at 1:28 PM, Ted Hardie <[email-masked]> wrote:
> 
> Howdy,
> 
> On Fri, Aug 23, 2019 at 11:48 AM Chris Morrow <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Changing TCP behavior on most systems requires modifying the kernel.  Having something built so that it could be modified in user space really was important.  UDP is just a demux for QUIC and that's a success because it enabled all of the other functionality to go up into the user space.

+1

I think this argument goes even deeper than the convenience of being able to easily modify kernel code or not, too.

The platform I work on has support for TCP in user-space, so when we want to do experiments, it's just as easy as modifying QUIC. Putting the logic for flow control, congestion control, etc, in to a userspace process is very convenient and a useful feature.

However, the one bit of work that remains crucial for the kernel to do in a multi-process system is demultiplexing inbound packets to the correct processes responsible for flows by port. Having a reusable protocol header that lets us demultiplex, rather than teaching the kernel how to switch for a new kind of identifier for every new IP protocol, is really important. If you want to define a new protocol on bare IP, you either are stuck with the raw IP socket model, in which either only one process gets everything for a protocol, or all processes get everything; or you need to modify the kernel for every kind of demultiplexing identifier you invent. What we've learned is that the port-level demux is simple and reusable, and not useful to change much; while the higher-order notions of richer transport protocols is useful to be able to modify and evolve independently.

Best,
Tommy

---

From: Chris Morrow <[email-masked]>
Date: Fri, 23 Aug 2019 20:41:43 +0000

On Fri, 23 Aug 2019 20:28:43 +0000,
Ted Hardie <[email-masked]> wrote:
> 
> [1  <text/plain; UTF-8 (7bit)>]
> Howdy,
> 

sure, and permitting <new protocol number> though/around/over/etc all
the various 'firewall' things (not to mention that security NAT
device) is also .. fun.

> it enabled all of the other functionality to go up into the user space.

agree, just saying that there are lots of reasons why: "picked udp, not X".
but that really ... as fernando said any other number would have also worked...

except that UDP has pretty universal access end-to-end without
molestation AND it's not something kernels generally do much with
except: "here ya go socket listener!"

> Just my perspective,

thanks! (I also have a perspective! which I hope gets better with new
glasses) :)

-chris

---

From: Fernando Gont <[email-masked]>
Date: Sun, 25 Aug 2019 16:59:57 +0300

On 23/8/19 23:28, Ted Hardie wrote:
> was important.  UDP is just a demux for QUIC and that's a success
> because it enabled all of the other functionality to go up into the user
> space.

I agree with the above, still, the reason for which QUIC employs UDP
(rather than doing mux/demux by itself) is because you can't deploy new
transport protocols on the Internet.

---

From: John Leslie <[email-masked]>
Date: Sun, 25 Aug 2019 12:48:39 -0400

> transport protocols on the Internet.

   Yes, QUIC employs UDP because they despaired of deploying a new
transport protocol.

   However, [email-masked] _really_shouldn't_ abandon hope
of deploying a new transport protocol: it's _hard_; it may not happen in
my lifetime; but the Internet, or its replacement, _will_ need a new
transport procotol some day...

--
John Leslie <[email-masked]>

---

From: Joe Touch <[email-masked]>
Date: Sun, 25 Aug 2019 10:07:34 -0700

> On Aug 25, 2019, at 9:48 AM, John Leslie <[email-masked]> wrote:
> 
>   However, [email-masked] <mailto:[email-masked]> _really_shouldn't_ abandon hope

IMO, it has a chance of happening when the IETF “grows up”.

Trust, but VERIFY.

The IETF started with the assumption that everyone wanted to play together and play nice. That ship sailed decades ago.

The missing step is to create a validation suite and corresponding official endorsement of compliance.

Without that, we’re constantly stuck with the tragedy of the commons, which drives us to the worst of all implementations.

Joe

---

From: Christian Huitema <[email-masked]>
Date: Sun, 25 Aug 2019 11:07:23 -0700

> transport protocols on the Internet.

I think we are getting caught in disputes over vocabulary. Two things
are true at the same time:

1) We cannot send packets in which the IP protocol or IPv6 payload type
is set to a different value than TCP or UDP and expect them to reach
destinations across the Internet.

2) QUIC, BitTorrent and SCTP demonstrate that you can run a protocol on
top of UDP that has all the characteristics of a classic transport
protocol, including error recovery and congestion control. ( QUIC can
perform mux/demux by itself, using the "connection ID" field, but most
deployments refrain from using multiple layers of multiplexing.)

Using UDP causes 8 bytes of overhead per packet, which is unfortunate.
You may call that a middle-box tax if you want. But as long as you are
willing to pay that tax, you can of course deploy new transmission
control protocols over the Internet. Most people will call them
transport protocols.

-- Christian Huitema

---

From: Fernando Gont <[email-masked]>
Date: Sun, 25 Aug 2019 21:05:28 +0300

>    Yes, QUIC employs UDP because they despaired of deploying a new

Well, that's my point.

And me being puzzled about the IAB statement saying that it is possible
to deploy new transport protocolon the *I*nternet, when it seems to be
quite the oposite.

> transport procotol some day...

I tend to associate hope with religion, rather than engineering. :-)

Certainly, hope will not get us there. Probably nothing will... but if
there's any chance that something that will, it's certainly not 'hope'
but some sort of action -- whatever it is.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 25 Aug 2019 21:07:05 +0300

On 25/8/19 20:07, Joe Touch wrote:
> 
> 
>> On Aug 25, 2019, at 9:48 AM, John Leslie <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>   However, [email-masked]
>> <mailto:[email-masked]> _really_shouldn't_ abandon hope
> The IETF started with the assumption that everyone wanted to play
> together and play nice. That ship sailed decades ago.
> 

You mean something along the lines of "If you want to claim you provide
Internet connectivity, then you *must* support all this"?

---

From: Joe Touch <[email-masked]>
Date: Sun, 25 Aug 2019 11:31:25 -0700

> On Aug 25, 2019, at 11:07 AM, Fernando Gont <[email-masked]> wrote:
> 

https://standards.ieee.org/content/ieee-standards/en/products-services/icap/index.html

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 25 Aug 2019 15:16:48 -0400

Some of us who worked on the Open Internet (aka network neutrality) saw
"protocol neutrality" as very much part of the same spirit and possibly a
legal entitlement of customers. And the issue of naming "Internet access"
implying some obligations was also part of the discussion. Experience seems
to indicate that only legal or regulatory requirements are likely to lead
there, given that many carriers have no economic interest to do this - and
carrier-grade NATs make it painful or impossible to move beyond TCP and UDP.

Henning

On Sun, Aug 25, 2019 at 1:07 PM Joe Touch <[email-masked]> wrote:

> The IETF started with the assumption that everyone wanted to play together
> and play nice. That ship sailed decades ago.
>
> Without that, we’re constantly stuck with the tragedy of the commons,
> which drives us to the worst of all implementations.
>
> Joe

---

From: John Leslie <[email-masked]>
Date: Sun, 25 Aug 2019 15:26:54 -0400

> I tend to associate hope with religion, rather than engineering. :-)

   Actually, religion is about "belief," not "hope".

   "Hope" is about imagining a future; and implies that it's a future we
_might_ agree to work towards. (A religious person might pray for God's
help; but _anyone_ could keep the idea in mind in case something changes.)

> but some sort of action -- whatever it is.

   I won't argue lingustics here. You're welcome to substitute your own
word. My point is that we shouldn't rule out a future where we _can_
deploy a new transport protocol, even if we believe it "too hard" right
now.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 25 Aug 2019 22:31:40 +0300

On 25/8/19 22:16, Henning Schulzrinne wrote:
> "protocol neutrality" as very much part of the same spirit and possibly
> a legal entitlement of customers. And the issue of naming "Internet
> access" implying some obligations was also part of the discussion.
> Experience seems to indicate that only legal or regulatory requirements
> are likely to lead there, given that many carriers have no economic
> interest to do this - and carrier-grade NATs make it painful or
> impossible to move beyond TCP and UDP.

You probably wished to blame just CGNATs for that. Unfortunately, you
can't: see RFC7872.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 25 Aug 2019 22:35:50 +0300

>    Actually, religion is about "belief," not "hope".

With hope usually supported by a belief that just can't be
scientifically proven.

> deploy a new transport protocol, even if we believe it "too hard" right

If you are to deploy a new transport protocol, you essentially have two
options:

1) Deploy it as a "native" transport protocol, and fail miserably
2) Tunel/encapsulate it into something that actually works.

I see why Google folks opted for 2), and don't seem to find a reason for
folks doing 1). At the end of the day, if "it doesn't work", you can
complain, and assign blames... but it still won't work. :-)

---

From: John Leslie <[email-masked]>
Date: Sun, 25 Aug 2019 15:41:35 -0400

> destinations across the Internet.

   We certainly _can_ send different payload types.

   We _can_ design protocols which check whether those payload types are
received.

   There are other approaches which _today_ seem much more practical.

> deployments refrain from using multiple layers of multiplexing.)

   Absolutely true!

> Using UDP causes 8 bytes of overhead per packet, which is unfortunate.

   True. We chose the wrong size limits 25 years ago. Next time I hope
we'll know better. (25 years ago, 8 bytes of overhead was significant
by itself.)

> control protocols over the Internet. Most people will call them

   Actually, what we call them _does_ make a real difference. I'd be happy
to call them "transport protocols"...

---

From: Fernando Gont <[email-masked]>
Date: Sun, 25 Aug 2019 22:37:46 +0300

On 25/8/19 22:16, Henning Schulzrinne wrote:
> a legal entitlement of customers. 

That's easier said than done. See e.g.:
https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops

A big part of the solution is: who's willing to pay the associated bill?

---

From: Fernando Gont <[email-masked]>
Date: Mon, 26 Aug 2019 04:47:51 +0300

> destinations across the Internet.

Agreed. But doesn't that mean that you cannot deploy new transport
protocols natively?

Architecturally-wise, in a non-recursive architecture transport runs
over Internet, right?

If IP is Internet, and QUIC is transport, what do you call the UDP that
stis in between?

> deployments refrain from using multiple layers of multiplexing.)

As long as UDP is not filtered, you can run anything you want on top of
UDP. You can run IP or IPv6, too (I regularly do, indeed). (sixxs has
done that for ages, openvpn and IPsec over UDP, too, and I seem to
recall that sctp too)

> control protocols over the Internet. Most people will call them

The point of my original comment was this:

1) You cannot deploy new transport protocols natively. You need to
encapsulate/tunnel, because otherwise the big-i internet will likely
drop your packets. This is kind of well understood.

2) Of course you can always find some protocol that will work, to tunnel
something you want to deploy (go up one layer if the current layer
doesn't work). So I'm not sure there's any news here. -- that doesn't
mean less credit for QUIC at all. I'm wondering if the fact of being
able to find *something* over which a protocol (transport or otherwise)
can work has been a new key finding. -- e.g. any of us have been doing
OpenVPN over UDP and others for quite a while.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 26 Aug 2019 07:25:32 +0300

On 25/8/19 22:41, John Leslie wrote:
[,,,]
> to call them "transport protocols"...

If anything, QUIC without UDP encapsulation is as much of a transport
protocol as IPv6 is as network layer protocol.

If you tried to use IPv6 natively (i.e., a single network layer in the
resulting stack) on the same network on which we employ IPv4, you just
can't: there's only partial support for IPv6, and you need to tunnel it
over something that works (IPv4) to overcome that. Yes, IPv6 is a
network-layer protocol, but if folks assumed that it can be readily
employed on the whole big-I Internet, that would be, of course, a false
expectation: there's lots of parts of the network that simply lack
support for it.

The same analogy applies to transport protocols: lots of portions of the
network just don't support anything else other than, say, TCP and UDP.
In some cases, because of NATs, in others because of firewalls, or boxes
that will drop packets if they cannot tell whether something is a
transport protocol or unknown EH, etc. That's when you end up stacking
one transport over another.

I don't think this is a matter of vocabulary, but one of architecture:
In away, protocols don't work because, for one reason or another, the
layer you had has become broken (into islands, if you want), and you
need to pile protocols of the same rank on top of each other for the
system to work.  In the case of transport, UDP is of course convenient,
because it allows your packets to "get through" while doing as little as
possible. But is a protocol, not a "tax".

If you want to call UDP "middle-box tax", I guess we should also call
IPv4 a "middle-box tax" (or similar name) when tunneling IPv6 over IPv4.

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Joe Touch <[email-masked]>
Date: Sun, 25 Aug 2019 21:45:02 -0700

> If IP is Internet, and QUIC is transport, what do you call the UDP that

Therein lies the error.

QUIC alone is not a transport.

It’s not complete enough to be transport by itself. It doesn’t provide the socket (as in RFC793’s idea of a socket) demuxing.

IMO, QUIC + UDP is a transport layer. A layer that provides a more complex service than UDP alone.

So yes, UDP is a transport layer - when operating by itself. But when paired with QUIC, it is the pair that are the transport.

UDP affords the ability to design new transports on top of a basic muxing service. Those new transports CAN be inside user space, but that’s not the point necessarily - they can easily also be implemented inside an OS.

(and IMO, UDP options help extend that muxing service without necessarily completing all the features we call a transport, so that’s consistent here too).

Joe

---

From: Joe Touch <[email-masked]>
Date: Sun, 25 Aug 2019 21:50:11 -0700

> On Aug 25, 2019, at 12:16 PM, Henning Schulzrinne <[email-masked]> wrote:
> 
> Some of us who worked on the Open Internet (aka network neutrality) saw "protocol neutrality" as very much part of the same spirit and possibly a legal entitlement of customers. And the issue of naming "Internet access" implying some obligations was also part of the discussion. Experience seems to indicate that only legal or regulatory requirements are likely to lead there,

That hasn’t been the case for SONET, ATM, or Ethernet services.

If we had a clear definition of “ISOC-certified Internet service”, then:
	a) customers might be willing to seek that
	b) customers who pay for that have a clear legal path if that’s what was offered and it isn’t true

People pay more for UL-listed equipment, for Good Housekeeping seals of approval, etc. This isn’t any different, except the we have no “seal” authority - yet.

> given that many carriers have no economic interest to do this - and carrier-grade NATs make it painful or impossible to move beyond TCP and UDP.
> 
> Henning

We could have two versions of service - ISOC-certified true Internet and ISOC-certified translated Internet (the latter so we don’t freeze out carriers to start). People might pay more for the former.

——

The trouble with ignoring the need for this sort of certification at the ISOC level is that we’ve basically dumped that work onto the user at run-time - to confirm every feature before using it - and at the protocol level (by adding complex “are you sure” mechanisms).

Joe

---

From: Fernando Gont <[email-masked]>
Date: Mon, 26 Aug 2019 08:19:43 +0300

On 26/8/19 07:45, Joe Touch wrote:
> It’s not complete enough to be transport by itself. It doesn’t provide
> the socket (as in RFC793’s idea of a socket) demuxing.
> 
> IMO, QUIC + UDP is a transport layer. A layer that provides a more
> complex service than UDP alone.>
> So yes, UDP is a transport layer - when operating by itself. But when
> paired with QUIC, it is the pair that are the transport.

Maybe one of the underlying issues here is that one would normally
expect one transport service as a single layer (i.e. protocol layer).
But since this is not feasible in the current Internet, you get two
protocol layers to offer a transport service you'd normally implement in
a single one.

i.e., for QUIC you need two protocols to implement a specific transport
service. You use one transport protocol (UDP) that doesn't provide the
service you want (but get the packets through), and then stack abother
protocol on top of it, that does all that is missing.

So I'd argue that it is correct that you can implement new transport
*services*. However, the statement that you can deploy new transport
*protocols* seems to be misleading (you're actually relying on a very
simple transport protocol, and use its services as a building block for
implementing a different transport service). This is what my original
message tried to point out.

---

From: Joe Touch <[email-masked]>
Date: Sun, 25 Aug 2019 22:24:15 -0700

The only thing QUIC doesn’t do is demux via a single field of the IP header called “protocol”.

So?

Maybe this is a good thing - maybe it just goes to show middleboxes how incapable they are at actually knowing what’s going on.

Joe

> On Aug 25, 2019, at 10:19 PM, Fernando Gont <[email-masked]> wrote:
> 
> e-mail: [email-masked] <mailto:[email-masked]>

---

From: Fernando Gont <[email-masked]>
Date: Mon, 26 Aug 2019 08:30:41 +0300

On 26/8/19 07:50, Joe Touch wrote:
> 
> 
>> On Aug 25, 2019, at 12:16 PM, Henning Schulzrinne <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> Some of us who worked on the Open Internet (aka network neutrality)
>> saw "protocol neutrality" as very much part of the same spirit and
>> possibly a legal entitlement of customers. And the issue of naming
>> "Internet access" implying some obligations was also part of the
>> discussion. Experience seems to indicate that only legal or regulatory
>> requirements are likely to lead there,
> 

If one means to get on that path, I'd start with certified
implementations -- at times, the service is a consequence of this.

One of the most obvious cases is e.g. IPv6 implementations that are
"IPv6 Ready", but then do an extremely lousy job (see "IPv6 Security
Assessment and Benchmarking" at
http://www.ipv6hackers.org/meetings/ipv6-hackers-1).

>> given that many carriers have no economic interest to do this - and
> We could have two versions of service - ISOC-certified true Internet and
> ISOC-certified translated Internet (the latter so we don’t freeze out
> carriers to start). People might pay more for the former.

Without giving this a lot of thought, the problem with "certified
Internet" is that one would expect that to apply to all destinations and
paths.

When should my ISP start billing me for the "true Internet" service?
When it works with Google, or with everyone? If the former: Does it
matter? If the latter: would it ever happen?

(I bet many of us, nevertheless, when prompted with the question of
which one we want to buy, would ask the question: what can I do with the
expensive one that I can't with the other? (as opposed to "what one
could *potentially* do).

---

From: Joe Touch <[email-masked]>
Date: Sun, 25 Aug 2019 22:40:57 -0700

> On Aug 25, 2019, at 10:30 PM, Fernando Gont <[email-masked]> wrote:
> 

1. provide endpoint services that use certified implementations
2. give me real Internet service, per below

No, this won’t fix everything. But it’s the set of steps we need to take first.

The next step is to highlight where these rules don’t work as not working. Not endorse them as “de facto changes to the baseline”.

Joe

Bill of Internet Access Rights

Joe Touch
USC/ISI
June 21, 2006 
(this is an update of a set of rules originally presented at "Preventing the Internet Meltdown", Los Angeles CA 2004; the original is also presented below) 

Internet is an association of communicating parties. This necessarily results in a number of rights which are required for consenting parties to communicate. Consenting parties should be able to communicate in an unrestricted fashion, insofar as they do not impinge on the corresponding rights of other parties. The following is a list of specific rights to that end:

1. REAL IP: Users have the right to obtain a real IP address, routable from anywhere on the Internet.

2. REAL DNS (& REVERSE-DNS): Users have the right to obtain a valid reverse DNS name for that IP address, and the forward lookup of that name should match the same address.

3. RECEIVE ANY: Users have the right to receive any valid IP packet, using any valid transport protocol on any valid port (if applicable), up to the limits of your local resources and network connection.

4. SEND ANY: Users have the right to send any valid IP packet to any valid real IP address, using any transport protocol, on any valid port (if applicable), provided it uses an inconsequential amount of resources of the network and potential receiver until mutual consent is established.

5. ENFORCEMENT: Users have the right to know the ISP responsible for traffic from any valid IP address, sufficient to register a complaint regarding violations of any of these rules.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 26 Aug 2019 08:48:26 +0300

> header called “protocol”.

I go back to my original comment: that you can't deploy new transport
protocols. Yes, you can stack as many layers as you want, but you can't
deploy new transport protocols. You can deploy new transport protocols
as much as you can deploy new internet protocols (you can do overlays as
much as you want). To put it bluntly: you have UDP sitting below QUIC
because you can't deploy new transport protocols on the Internet.

(No need to mention that none of my previous comments was in detriment
of QUIC -- they were very pragmatic, indeed).

> Maybe this is a good thing - maybe it just goes to show middleboxes how
> incapable they are at actually knowing what’s going on.

I'd bet much of the brokenness has nothing to do with middle-boxes that
want to know what's going on (e.g., firewalls enforcing security
policies). A lot has to do with NATs (which need to be aware about the
transport protocol to do the translation), and other boxes that at times
need to drop packets as a side effect of doing something else
(https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops).

Let's also not just blame NATs: we were extremely close to ship what
became RFC8200 with no comments about middle-box insertion of EHs, we
also had SRv6 with in-the-network EH-insertion, and Linux currently
ships with in-the-network SRv6 insertion (see man 8 ip-route). At times
we don't seem to be consistent regarding wether we want middleboxes to
fiddle with packets or not....

---

From: Joe Touch <[email-masked]>
Date: Sun, 25 Aug 2019 22:53:06 -0700

> On Aug 25, 2019, at 10:48 PM, Fernando Gont <[email-masked]> wrote:
> 
> At times

Fixing bad ideas in the IETF is a full time job that none of us want or have.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Mon, 26 Aug 2019 09:00:35 +0300

On 26/8/19 08:40, Joe Touch wrote:
> 
> 
>> On Aug 25, 2019, at 10:30 PM, Fernando Gont <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
> The next step is to highlight where these rules don’t work as not
> working. Not endorse them as “de facto changes to the baseline”.

Some comments:

1) With many current implementations, some of the packets you expect to
pass-through will simply consume lots of resources. SO the will end up
being dropped.

2) "real ip address" is, in many cases, just not feasible --
particularly for folks joining the business late -- unless you're
assuming IPv6.

3) Some of the things you mention below go against current operational
practices -- e.g. packet filtering by operators. -- even the lack of a
dns reverse mapping may make mail-relaying fail (not taht it has proven
to be affective to stop spam ;-), but..)

4) Regarding "SEND ANY", I assume you really mean "SEND". Now, where do
you draw the line as whether filtering does not allow sending, or simply
is a receive policy at some point?

Note: I'm note necessarily arguing against the text you quoted, but
rather arguing about its feasibility.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 26 Aug 2019 10:12:49 -0400

Given that the economic incentives are against providing such services, and
competition in most jurisdictions is weak or largely non-existent (US) and
that competition for user-invisible features is difficult, you are asking
for regulatory intervention. (Nothing wrong with that - you could consider
this a version of a market failure.)

The additional problem is that you need near-100% compliance to allow
systems designers to rely on these capabilities. Thus, unless almost every
ISP allows non-UDP/TCP transport layers, nobody is going to be building
such layers.

As a matter of terminology, we also seem to be re-iterating the old
discussion that layers are no longer quite as simple as they used to be in
the 1980s, where the function of a layer can now be broken up into multiple
sub-layers, shims or whatever else you'd want to call them. As an older
example, you could argue that RTP is a (specialized) transport protocol,
used with UDP or TCP, for timing-sensitive applications.

Henning

On Mon, Aug 26, 2019 at 1:41 AM Joe Touch <[email-masked]> wrote:

> The next step is to highlight where these rules don’t work as not working.
> Not endorse them as “de facto changes to the baseline”.
>
> Joe
>
> (this is an update of a set of rules originally presented at "Preventing
> the Internet Meltdown", Los Angeles CA 2004; the original is also presented
> below)
>
> Internet is an association of communicating parties. This necessarily
> results in a number of rights which are required for consenting parties to
> communicate. Consenting parties should be able to communicate in an
> unrestricted fashion, insofar as they do not impinge on the corresponding
> rights of other parties. The following is a list of specific rights to that
> end:
>
> 2. REAL DNS (& REVERSE-DNS): Users have the right to obtain a valid
> reverse DNS name for that IP address, and the forward lookup of that name
> should match the same address.
>
> 3. RECEIVE ANY: Users have the right to receive any valid IP packet, using
> any valid transport protocol on any valid port (if applicable), up to the
> limits of your local resources and network connection.
>
> 4. SEND ANY: Users have the right to send any valid IP packet to any valid
> real IP address, using any transport protocol, on any valid port (if
> applicable), provided it uses an inconsequential amount of resources of the
> network and potential receiver until mutual consent is established.
>
> 5. ENFORCEMENT: Users have the right to know the ISP responsible for
> traffic from any valid IP address, sufficient to register a complaint
> regarding violations of any of these rules.
>
>

---

From: John Leslie <[email-masked]>
Date: Mon, 26 Aug 2019 12:07:18 -0400

Henning Schulzrinne <[email-masked]> wrote:
> 
> Given that the economic incentives are against providing such services,
> and competition in most jurisdictions is weak or largely non-existent
> (US) and that competition for user-invisible features is difficult,
> you are asking for regulatory intervention. (Nothing wrong with that -
> you could consider this a version of a market failure.)

   It _is_ a market failure, of course; but hardly a failure of a _free_
market. There is no such thing in communication services.

   The proper question, of course isn't whether it's "wrong," but rather
whether "regulatory intervention" is likely to improve things.
 
> systems designers to rely on these capabilities.

   ROTFL.

> Thus, unless almost every ISP allows non-UDP/TCP transport layers,
> nobody is going to be building such layers.

   The classic statement, of course, is that <evil-action> may be
considered "damage" and we "route around it."

   (I thought that was well-known; and we agreed upon it. But I may
be wrong!)

   There is already quite an infrastructure of "virtual private
networks" to bypass censorship choke-points. The same solution can
be set up to bypass other internet choke-points; and I wouldn't be
surprised to see these become popular...

   ... when individual users feel the pain.

   Alas, too many of _us_ expect to replace sub-optimal government
policies with good government policies. (I was guilty of that
myself fifty years ago.)

   Others of us place our faith in government incompetence (which
faith seems well-founded) and think we can use international
organizations such as IETF.org to trump their incompetence. YMMV...

   My attitude is that our salvation lies in numbers: that traffic
_will_ increase, and overheads which were intolerable thirty years
ago will pale into insignificance and no government will be able
to search for them.

   Thus "tunneling" in the generic sense will become our favored
tool. But I'm not wasting my time trying to define the perfect
tunneling tool; least of all chasing the "perfect" tunneling
architecture.

   (Right now, alas, I'm looking for a way to "tunnel" around 30%
packet loss, which is this week's "damage" being inflicted upon
New Hampshire by the incompetence of our too-few home Internet
services.)

> discussion that layers are no longer quite as simple as they used to
> be in the 1980s, where the function of a layer can now be broken up
> into multiple sub-layers, shims or whatever else you'd want to call
> them.

   "shims" is a good name.

   I'd love to facilitate that discussion. I'm not sure I can, since
the backgrounds of our participants vary so much.

> As an older example, you could argue that RTP is a (specialized)
> transport protocol, used with UDP or TCP, for timing-sensitive
> applications.

   ;^)

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 27 Aug 2019 20:34:20 -0400

When the US regulatory landscape was friendlier to Open Internet ideas,
BITAG (https://bitag.org/) was created to look at related issues and make
recommendations.

Unless you can convince people that this yields shorter ping times for FPS
games or "cyber security!", I doubt that this will get much consumer
traction, except from the subscribers of the IETF mailing list.

That said, my sense is that smaller, regional ISPs (such as the emerging
community and rural electric fiber networks in the US) are actually pretty
protocol-transparent - mostly because they run plain-vanilla configurations
of network routers and don't have the in-house engineering resources to do
fancy traffic management. They also generally advertise themselves as
supporters of network neutrality, partially as a differentiator from their
traditional corporate competitors. Having a "good Internet housekeeping"
badge for them that they can readily self-certify for by running some tool
could be quite useful.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 27 Aug 2019 20:38:06 -0400

> That hasn’t been the case for SONET, ATM, or Ethernet services.

Those services were purchases as telecommunication services by
professionals, including other carriers, who wanted as much flexibility as
possible to run random higher-layer protocols (IPX! Netbios! various
versions of IP) on these networks. Each of these purchasers had significant
bargaining power. They are sold by the thousands, at best, not to home
users by the millions. Plus, they are closed, private networks, with no
addressing issues (i.e., no NATs) and relatively simple delivery models.
Thus, I don't think they can teach us much.

Henning

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 Aug 2019 19:28:49 -0700

On Aug 27, 2019, at 5:38 PM, Henning Schulzrinne <[email-masked]> wrote:

> Those services were purchases as telecommunication services by professionals, including other carriers, who wanted as much flexibility as possible to run random higher-layer protocols (IPX! Netbios! various versions of IP) on these networks. Each of these purchasers had significant bargaining power. They are sold by the thousands, at best, not to home users by the millions. Plus, they are closed, private networks, with no addressing issues (i.e., no NATs) and relatively simple delivery models. Thus, I don't think they can teach us much.

Standards compliance means known full behavior. Not lowest common denominator behavior. 

And I doubt there are only just thousands of either SONET or especially Ethernet.  

Joe

---

From: Tony Li <[email-masked]>
Date: Tue, 27 Aug 2019 19:38:35 -0700

> And I doubt there are only just thousands of either SONET or especially Ethernet.  

If you’re thinking that SONET or Ethernet compliance testing is at all meaningful, please think again.

Those systems interoperated due to the exact same market pressures that exist at the protocol level: gear that does not interoperate gets returned.

If a vendor achieves market dominance and their implementation has ‘quirks’, the rest of the market is forced to work around those quirks.

Tony