WIP: Begin lightly abstracting over the use of UDP as the underlying transport #4043

Ericson2314 · 2020-08-21T05:07:16Z

Based on recent mailing list feedback that this might possibly be OK, I
decided to take a crack at reducing the "hard coding" of UDP in the
spirit of other RFCs which strive to be agnostic to the underlying
protocol.

Due to the controversy over this, I imposed these constraints on myself
to try to be as conservative as possible.

Absolutely no design changes on things which are already standardized,
just editorial changes, and very simple extrapolation of the existing
design. (I never ever considered the former at this time, just
documenting this for posterity.
Anything that is not UDP (over IP) is deemed experimental. The size
limitations I figure may not make sense for other transports / during
other experiments, so I call that out.
When UDP was mentioned in some interesting way that generalized (e.g.
something that separately mentions IP address and UDP port), I provide
the general language (plain "address", but also provide the UDP common
case as before so no specificity is lost.

The purpose of this exercise is not to get QUIC over UDP "more ready
for production", as that would slow down the WG for little gain, but
rather to call out the dependencies that currently do exist so as to be
sure there is no unintentional coupling. I fully leave to others to
decide what coupling is intenional or unintentional, and whether
anything at all is cause for concern.

In this first commit, I just audited all the occurrence of "UDP". If
this looks good, I would then go back and likewise scan for "port"
"IPv4", and "IPv6".

My one regret is that in keeping the line length the same, I made the
diff more complicated than it would otherwise be. Do you all have a
process for that?

Progress towards issue #4061.

…transport Based on recent mailing list feedback that this might possibly be OK, I decided to take a crack at reducing the "hard coding" of UDP in the spirit of other RFCs which strive to be agnostic to the underlying protocol. Due to the controversy over this, I imposed these constraints on myself to try to be as conservative as possible. - Absolutely no design changes on things which are already standardized, just editorial changes, and very simple extrapolation of the existing design. (I never ever considered the former at this time, just documenting this for posterity. - Anything that is not UDP (over IP) is deemed experimental. The size limitations I figure may not make sense for other transports / during other experiments, so I call that out. - When UDP was mentioned in some interesting way that generalized (e.g. something that separately mentions IP address and UDP port), I provide the general language (plain "address", but also provide the UDP common case as before so no specificity is lost. The purpose of this exercise is *not* to get QUIC over UDP "more ready for production", as that would slow down the WG for little gain, but rather to call out the dependencies that currently do exist so as to be sure there is no unintentional coupling. I fully leave to others to decide what coupling is intenional or unintentional, and whether anything at all is cause for concern. ---- In this first commit, I just audited all the occurrence of "UDP". If this looks good, I would then go back and likewise scan for "port" "IPv4", and "IPv6". My one regret is that in keeping the line length the same, I made the diff more complicated than it would otherwise be. Do you all have a process for that?

LPardue · 2020-08-21T11:31:42Z

Hi @Ericson2314. Would you mind creating an accompanying issue for this PR so that we can track continued discussion on the concept of abstracting UDP. The PR can then stay focused on discussion of the file changes.

Wrt line length, that's just something we have grown to deal with. Well done for keeping the CI checks happy on your first attempt 👍

LPardue · 2020-08-21T11:37:45Z

draft-ietf-quic-transport.md

+: A message of the underlying transport protocol, which when used by QUIC will
+  contain multiple QUIC packets. Calling this a "datagram" and not a "packet"
+  emphasizes the message-oriented nature of the underlying transport, and helps
+  distinguish these from QUIC packets.


Are you suggesting that that the underling transport has to be message based? That seems to be a large caveat that restricts the value of these changes.

Based on the feedback thread, I was trying to be super conservative, even if that risks an "any color as long as it's black" situation where UDP is basically the only protocol that meets the requirements.

If you think this is too cautious, I'm perfectly fine dropping it.

draft-ietf-quic-transport.md

LPardue · 2020-08-21T11:52:25Z

draft-ietf-quic-transport.md

+This protocol SHOULD NOT have automatic retransmission, ordering, congestion
+control, or other such mechanisms that would overlap with those provided by QUIC
+and therefore not actually enhance the overall quality of service.  This
+protocol SHOULD be message-oriented.


This answers my earlier point (sorry for not reading in completeness). Are there many examples of IP-based, message-based, Internet transport protocols? My sense is that the scope of these changes are putting it in the "Yah Ain't Gonna Need It" bracket.

Personally, I'm reviewing this through the mental model of two additional transports:

Message-based Websockets across an HTTP proxy

Local datagram sockets for IPC

Websockets are clearly going to provide all those services which an underlying transport SHOULD NOT have, but that's just the suck you live with if that's your only way to speak QUIC to an endpoint. Local sockets, on the other hand, mean that a lot of the machinery within QUIC simply won't be needed -- but if you're porting over a protocol that's already built atop QUIC, that might be okay.

MikeBishop

An interesting foray. I think this generalizes some pieces that really are UDP-specific, and would need to be redefined (or at least reconsidered) in other aspects.

MikeBishop · 2020-08-21T14:06:47Z

draft-ietf-quic-transport.md

+datagram as necessary. (The payload is the assembled QUIC packets, and does not
+include any headers associated with the underlying protocol that are also part
+of the datagram.) A client that sends padded datagrams allows the server to send
+more data prior to completing address validation.


I feel like the anti-amplification features -- minimum initial size, the 3x limit, etc. -- really are UDP-focused because they mitigate attacks we know are common with UDP. A different transport might have such concerns, or might not. Perhaps, rather than generalizing these requirements, we should instead condition them on UDP.

draft-ietf-quic-transport.md

MikeBishop · 2020-08-21T14:15:10Z

draft-ietf-quic-transport.md

+conventional situations using UDP, the client cannot freely vary the IP address,
+but can much more readily change the UDP port.  Since an address for QUIC when
+using UDP is the tuple of the IP address and UDP port, changing the source port
+along constitutes changing the QUIC address.) So changing the address from which
+it sends packets at the same time might cause the packet to appear as a
+connection migration.  This ensures that the mechanisms that support migration


This seems really wordy explaining why this is useful for UDP while still trying to generalize. You already changed the specific of UDP port to "source address"; probably all you need to add is that "When the underlying transport protocol is UDP, changing the source port is sufficient."

It might also be the case that changing the source address isn't possible with the alternate transport, so this is an "if supported by the underlying protocol" thing. (For that matter, the CID itself might be irrelevant on a transport where addresses can't change.)

draft-ietf-quic-transport.md

MikeBishop · 2020-08-21T14:21:03Z

draft-ietf-quic-transport.md

+This protocol SHOULD NOT have automatic retransmission, ordering, congestion
+control, or other such mechanisms that would overlap with those provided by QUIC
+and therefore not actually enhance the overall quality of service.  This
+protocol SHOULD be message-oriented.


Personally, I'm reviewing this through the mental model of two additional transports:

Message-based Websockets across an HTTP proxy

Local datagram sockets for IPC

Websockets are clearly going to provide all those services which an underlying transport SHOULD NOT have, but that's just the suck you live with if that's your only way to speak QUIC to an endpoint. Local sockets, on the other hand, mean that a lot of the machinery within QUIC simply won't be needed -- but if you're porting over a protocol that's already built atop QUIC, that might be okay.

MikeBishop · 2020-08-21T14:25:36Z

draft-ietf-quic-transport.md

+An underlying datagram MUST correspond to a single IP packet, if it is sent over
+IP.  That means IP fragmentation MUST NOT be used.  When using IPv4
+({{!IPv4=RFC0791}}), the DF bit MUST be set to prevent fragmentation on the
+path.


I'm not certain QUIC generically has this requirement across all underlying transports. The requirement is that datagrams be delivered whole to QUIC; if they were fragmented and reassembled along the way, that's irrelevant. For UDP, we don't fragment because we want to be able to assess the maximum packet size; for some other transport, we might be able to query the maximum size directly or have effectively-infinite maximum size.

In fact, given the way encryption overhead decreases with larger units of encryption, we might find that very large datagrams perform really well in certain environments with certain transports, even in the presence of fragmentation.

draft-ietf-quic-transport.md

MikeBishop · 2020-08-21T14:34:35Z

draft-ietf-quic-transport.md

@@ -4030,12 +4086,16 @@ address of the client; see {{address-validation}}.

 ## Path Maximum Transmission Unit


Much of the work referenced here is specific to UDP. I'd leave this as UDP-specific and merely note that a QUIC implementation on a different transport might need to use similar techniques to learn the properties of the path.

MikeBishop · 2020-08-21T14:36:19Z

draft-ietf-quic-transport.md

 : The maximum UDP payload size parameter is an integer value that limits the
-  size of UDP payloads that the endpoint is willing to receive.  UDP packets
-  with payloads larger than this limit are not likely to be processed by the
-  receiver.
+  size of underlying datagram payloads that the endpoint is willing to receive.
+  Datagrams with payloads larger than this limit are not likely to be processed


A parameter that's specifically named UDP doesn't tell you anything about other underlying protocols. Either the parameter becomes generic (i.e. renamed, perhaps max_datagram_size) or it remains specific to UDP and other parameters might be defined for other contexts.

MikeBishop · 2020-08-21T14:37:30Z

draft-ietf-quic-transport.md

@@ -6669,7 +6736,7 @@ attacker to establish connectivity on a given path.
 An on-path attacker can:

 - Inspect packets
- Modify IP and UDP packet headers
+- Modify underlying transport headers (e.g. UDP and IP headers)


Here again, it's really going to depend on what that underlying transport is. This security analysis assumes UDP/IP; I think the safest statement is that QUIC over another transport needs its own security analysis to see what attackers might be able to do.

Co-authored-by: Mike Bishop <mbishop@evequefou.be>

…ardcode

Instead, just mention that it is one such example, since UDP is not the only option for the underlying transport.

@MikeBishop

As @MikeBishop points it the node may be assigned multiple IPv6 addresses.

Ericson2314 · 2020-08-28T04:04:52Z

Thanks for the feedback so far, just knocked off the easy stuff. I'll next switch to conditioning a lot of this stuff on UDP in particular as suggested.

larseggert · 2020-08-28T06:33:01Z

FYI, I converted this to a draft PR for now so we can track it better.

DavidSchinazi · 2020-08-28T21:03:33Z

I think that this PR makes the spec harder to read, with no obvious benefit. If someone wants to standardize QUIC over another medium, they'll have to write some sort of document for that, and simply saying "replace UDP with X" in that document should be good enough. I'd strongly prefer we didn't make the spec more generic at the cost of readability.

Ericson2314 · 2020-08-29T03:05:15Z

@LPardue @MikeBishop So, going the basic thrust of both your comments so far, We'd end up with fewer constraints on the underlying protocol (e.g. need not be message-origin) and a good bit of information being conditioned on UDP only (ECN, MTU discovery and associated limits and restrictions, etc.). I see very different conclusions one might make based on that, such as:

Negative: Meaningfully generalizing QUIC is too difficult because so much is UDP specific, and we'd need to make sure the remainder stands on its own.
Neutral: Fine to just continue conditioning sections on being UDP-specific, and just leave fleshing out the remainder for other transports as a future exercise.
Positive: It's great there are so many UDP-specific details we can cut away. It would be good to reorder or even split the document to make UDP-specific vs UDP-agnostic a prominent axis around which the standard is organized.

I think before I put too much more work with it, would be good to confirm whether you agree with this analysis, and if so, which outlook you both take. Most of the broad feedback is still negative, so I don't want to just stir emotions while beating a dead horse.

larseggert · 2020-08-31T13:13:15Z

I'm seeing quite a bit of pushback on the issue and #4061. People who are in favor of making this change should please state their case soon.

MikeBishop · 2020-09-02T19:11:56Z

Personally, I come back to Christian's comment. I'm hesitant to publish a specification that hasn't been implemented and interoperated at all. If all we've got experience with is UDP, let's publish UDP. Nothing stops us from writing a subsequent spec about how to do QUIC over a different transport and making these changes in that doc.

larseggert · 2020-09-03T11:14:48Z

Since we closed the issue (#4061) as being out-of-charter, I"ll close this PR as well.

Ericson2314 force-pushed the transport-udp-unhardcode branch from 49fd64f to ca022d8 Compare August 21, 2020 05:27

LPardue reviewed Aug 21, 2020

View reviewed changes

draft-ietf-quic-transport.md Outdated Show resolved Hide resolved

LPardue reviewed Aug 21, 2020

View reviewed changes

MikeBishop reviewed Aug 21, 2020

View reviewed changes

Ericson2314 and others added 2 commits August 27, 2020 23:12

Apply suggestions from code review

1a5c504

Co-authored-by: Mike Bishop <mbishop@evequefou.be>

Merge remote-tracking branch 'upstream/master' into transport-udp-unh…

c1151bc

…ardcode

Ericson2314 mentioned this pull request Aug 28, 2020

Generalizing QUIC to allow underlying tranports other than UDP #4061

Closed

Ericson2314 added 2 commits August 27, 2020 23:50

Don't abstract over UDP for this specific bit of empiracal evidence

56d0b98

Instead, just mention that it is one such example, since UDP is not the only option for the underlying transport.

Don't imply UDP without "real migrations" means constant IP.

367347b

As @MikeBishop points it the node may be assigned multiple IPv6 addresses.

larseggert marked this pull request as draft August 28, 2020 06:32

larseggert linked an issue Aug 28, 2020 that may be closed by this pull request

Generalizing QUIC to allow underlying tranports other than UDP #4061

Closed

larseggert closed this Sep 3, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

WIP: Begin lightly abstracting over the use of UDP as the underlying transport #4043

WIP: Begin lightly abstracting over the use of UDP as the underlying transport #4043

Ericson2314 commented Aug 21, 2020 •

edited

Loading

LPardue commented Aug 21, 2020

LPardue Aug 21, 2020

Ericson2314 Aug 28, 2020

LPardue Aug 21, 2020

MikeBishop Aug 21, 2020

MikeBishop left a comment

MikeBishop Aug 21, 2020

MikeBishop Aug 21, 2020

MikeBishop Aug 21, 2020

MikeBishop Aug 21, 2020

MikeBishop Aug 21, 2020

MikeBishop Aug 21, 2020

MikeBishop Aug 21, 2020

Ericson2314 commented Aug 28, 2020

larseggert commented Aug 28, 2020

DavidSchinazi commented Aug 28, 2020

Ericson2314 commented Aug 29, 2020

larseggert commented Aug 31, 2020

MikeBishop commented Sep 2, 2020

larseggert commented Sep 3, 2020

		@@ -4030,12 +4086,16 @@ address of the client; see {{address-validation}}.

		## Path Maximum Transmission Unit

WIP: Begin lightly abstracting over the use of UDP as the underlying transport #4043

WIP: Begin lightly abstracting over the use of UDP as the underlying transport #4043

Conversation

Ericson2314 commented Aug 21, 2020 • edited Loading

LPardue commented Aug 21, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MikeBishop left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Ericson2314 commented Aug 28, 2020

larseggert commented Aug 28, 2020

DavidSchinazi commented Aug 28, 2020

Ericson2314 commented Aug 29, 2020

larseggert commented Aug 31, 2020

MikeBishop commented Sep 2, 2020

larseggert commented Sep 3, 2020

Ericson2314 commented Aug 21, 2020 •

edited

Loading