they SHOULD follow the guidance in BCP38 to help prevent denial of service attacks. <del> 8. </del>  <del> 8.1. </del>  This document will request IANA to register "connect-ip" in the HTTP Upgrade Token Registry maintained at

they SHOULD follow the guidance in BCP38 to help prevent denial of service attacks.  <ins> 9. </ins>  <ins> 9.1. </ins> This document will request IANA to register "connect-ip" in the HTTP Upgrade Token Registry maintained at


This document <del> 8.2. This document will request IANA to register IP_PACKET in the "HTTP Datagram Format Types" registry established by HTTP-DGRAM. 8.3. </del>  This document will request IANA to add the following values to the "HTTP Capsule Types" registry created by HTTP-DGRAM:

Aligning CONNECT-IP with the changes in HTTP datagrams and CONNECT-UDP.
NAME when do you plan to merge the other PRs?
NAME I plan on merging the other PRs as soon as we have WG consensus, which (assuming no objections) should happen at the end of the month (see ) Hi folks, During today's interim call, there was strong support to proceed with the output of the Design Team. This email begins a call to confirm that consensus. As a reminder, this consists of the following changes to draft-ietf-masque-h3-datagram and draft-ietf-masque-connect-udp: URL URL Please review these changes and send your comments to the list. This consensus call will conclude on February 28. Thanks, Chris and Eric

This document  <ins> 9.2. </ins> This document will request IANA to add the following values to the "HTTP Capsule Types" registry created by HTTP-DGRAM:


scope for this document but can be implemented using CONNECT-IP extensions. <del> Since CONNECT-IP endpoints can proxy IP packets send by their peer, they SHOULD follow the guidance in BCP38 to help prevent denial of service attacks. </del>  10.

Connect-IP enables the Masque client to set the source address for any IP packets it requests the MASQUE proxy to forward to the external network. This enables the potential for source address spoofing by the MASQUE client or an entity prior to it. For proxies that assign addresses to the client and allows general access to Internet I think it would be really good to recommend or require the masque server to perform source address validation. However, there clearly exist some use cases where the MASQUE will be used to establish a virtual path between two networks and where source address validation is hard as neither network may be stubs networks. However, I think there are several things to address in the document. 1) Include in security description a discussion of the risks here and when it would be useful to perform source address validation. Especially for the assigned address(es) use case where rejecting all but the provided address range would be possible. 2) Consider if the security risks for certain deployments are such that source address validation is RECOMMENDED or REQUIRED
I don't think this is correct. I thought there was text in the draft that enforced that the source address was in the set of addresses the endpoints agreed were routable. [4.2.1] ADDRESSASSIGN capsule says "Any of these addresses can be used as the source address on IP packets originated by the receiver of this capsule.". I suppose this means we need a clarification that a MASQUE proxy MUST drop any packets whose source address is not in the set of addresses agreed upon in ADDRESSASSIGN capsules.
I think we can write a PR that addresses this. Here's a rough shape of a paragraph: how does that sound?
+1 to this text.

scope for this document but can be implemented using CONNECT-IP extensions.  <ins> Falsifying IP source addresses in sent traffic has been common for denial of service attacks.  Implementations of this mechanism need to ensure that they do not facilitate such attacks.  In particular, there are scenarios where an endpoint knows that its peer is only allowed to send IP packets from a given prefix.  For example, that can happen through out of band configuration information, or when allowed prefixes are shared via ADDRESS_ASSIGN capsules.  In such scenarios, endpoints MUST follow the recommendations from BCP38 to prevent source address spoofing. </ins> 10.


4.2.1. The ADDRESS_ASSIGN capsule (see iana-types for the value of the <del> capsule type) allows an endpoint to inform its peer that it has assigned an IP address or prefix to it.  The ADDRESS_ASSIGN capsule allows assigning a prefix which can contain multiple addresses.  Any </del>  of these addresses can be used as the source address on IP packets originated by the receiver of this capsule. <del> If an endpoint receives multiple ADDRESS_ASSIGN capsules, all of the assigned addresses or prefixes can be used.  For example, multiple ADDRESS_ASSIGN capsules are necessary to assign both IPv4 and IPv6 addresses. </del>  In some deployments of CONNECT-IP, an endpoint needs to be assigned an address by its peer before it knows what source address to set on its own packets.  For example, in the Remote Access case (example- remote) the client cannot send IP packets until it knows what address <del> to use.  In these deployments, endpoints need to send ADDRESS_ASSIGN capsules to allow their peers to send traffic. </del>  4.2.2. The ADDRESS_REQUEST capsule (see iana-types for the value of the <del> capsule type) allows an endpoint to request assignment of an IP address from its peer.  This capsule is not required for simple client/proxy communication where the client only expects to receive one address from the proxy.  The capsule allows the endpoint to </del>  optionally indicate a preference for which address it would get assigned.  Upon receiving the ADDRESS_REQUEST capsule, an endpoint SHOULD assign an IP address to its peer, and then respond with an ADDRESS_ASSIGN <del> capsule to inform the peer of the assignment. </del>  4.2.3.

NAME let's discuss that on . I'd like to merge this PR first then decide on a plan for before submitting the next revision to the datatracker
Splitting {ADDRESSREQUESTROUTEADVERTISEMENT} into ...V4 and ..._V6 would result in smaller capsules that have fewer error conditions. It would also keep IPv4 and IPv6 logic distinct.
I don't think the size of these capsules matters given their rarity. I can see the error condition argument but it's pretty minor and would come at the cost of making the specification longer. I don't feel too strongly here, but I think I have a slight preference for keeping things as they are.
I agree with David that size is problem not a big concern. I think having one set of capsule is less complex.
I also have a preference for keeping the capsules as they are with versions included; it also allows the route advertisement capsule to include routes for both v4 and v6 in one capsule, which I think is very important. I wouldn't want to lose that feature.
I similarly have a preference for keeping v4 and v6 in one capsule and agree size is not a big concern.
I just chatted with NAME to see what error conditions he was thinking of. Upon discussion (v6 route advertised when only v4 address is available), we concluded that this is not an error case, it's just a route that's not yet usable. We've concluded that this is something that we're comfortable leaving as-is.
Implementing this on the client I was wondering if there should be a way for the client to ask for the server for an address without specifying what address it wants. This could allow a VPN client to mention that it wants an IPv6 address or not. If we think this could be useful, we could encode it as or .
I believe asking for the Any address is what we discussed previously, so +1
You mean ADDRESS_REQUEST(IPv4-0.0.0.0/32) don't you. I think the format of the request works fine. But we do need to before we implement this into the specification.
Yes — if we have this, one option is to always have an ADDRESS_REQUEST expected from clients, and then there doesn't need to be signaling. Or we do the simple solution to 54 to say "I expect to send N capsules with my request".
You're right this could be a potential solution to . Let's discuss them together tomorrow
Regarding IPv6, I think a standard request that would make sense is asking for any /64. I guess that works fine with this idea too?
Oh that's interesting, if the IP Address is or , the prefix length is a hint for the requested length. I like that.
IETF 114: Add an editorial sentence to "remember, what you ask for may not be what you get, especially with regards to address families". A request should be paired with a response, multiple requests can just say "you have the same ones you had before". Clarify that it's cumulative. Also solves unassign/removal of addresses.
So there appear to exist some downside with the timing of the interactions when one want to use Address-Request capsule. So the basic problem is simply that the proxy will assign an address prior to the Address-Request capsule has been received, thus preventing the proxy from processing the request in the right context. So lets assume that the client has already created one connect-IP request with a limited scope and been assigned IP-A. Then it want to make an additional request for another limited scope proxying and would like to get the same address assigned. Due to the separation between the HTTP request for the Connect-IP and the capsule Address-Request a server can actually process the whole HTTP request prior to receiving the Address-Request. Resulting potentially in that another IP address assignment (IP-B) be provided to the client, despite it asking for IP-A to be assigned also to the request. So does the HTTP request needs an indicator parameter to tell the proxy to wait for one or more "request" capsules from the client before processing the request?
Out of curiosity, in what scenario would the client "like to get the same address assigned"? It makes sense for the proxy to decide to reuse addresses to save its address pool when the scoping allows it, but why would the client care?
I could imagine this happening if the client was trying to resume some previous session that it lost due to an outage? Seems to be niche, but it's certainly possible.
So the most obvious use case for this is to request iproto= CMP in combination with for example UDP. Then getting ICMP for another IP address then the one you already have UDP for is mostly useless if you intended to use the ICMP messages for hints when things fails for you UDP based protocol. I would note that for an endpoint liking to do P2P NAT traversal stuff getting an IP address rather than using Connect-UDP does make sense as it ensure the client has control. It enables the IP address for its UDP traffic to be Endpoint-Independent Mapping (RFC4787). This might be niche usages but I would like to avoid creating artificial barriers that makes things impossible or at least hard to realise.
Thanks, this makes sense. Should we suggest that clients bundle the ADDRESS_REQUEST in the same packet as the HTTP headers and suggest that servers check for those before responding?
I am still worried that this creates issues as your request may not fit in a single packet to begin with. My solution would be to actually move the address request part into the HTTP request itself as header field. That would ensure an atomic operation and no risk for errors.
Magnus, is your proposal to require, or to allow as an option, for the address request to be moved into the HTTP request? Why not bundle the capsules over a reliable delivery mechanism instead?
I first of all want to ensure that you can do a request that ensures that for those cases when it is necessary to interpret the Connect-IP request in the context of desired IP address it can done. Without uncertainties or requiring to have wait time to see if there are capsules incoming. So I think primarily allow as an option. I think a question back to your usages, do you have cases where one would need additional capsules to correctly interpret the option. Should we look for an other solution than the one I proposed to better cover the necessary functionality?
I want to be able to continue to do ADDRESS_ASSIGN capsules during the lifetime of the connection to support e.g., IPv6 Privacy extensions but without having to delegate the entire subnet. So I don't want to move to header-only.
I think NAME is describing something similar to the / capsules that we had in the original Google . The only difference is that we would add an HTTP header to say "start off in atomic mode and wait for atomic end before sending addresses and such". While I think this does sound useful, does it need to be in the core spec or could it be an extension?
Is there any reason to not bring back the capsules?
The only reason I can think of is to keep the core spec as short and simple as possible. But if we think this is an important feature then I'm not opposed to bringing back .
I agree with the sentiment of keeping the core spec short and simple, but the trade-off is also knowing what the minimum viable featureset we can always rely on is. If we conclude that capsules are in that set, that IMHO weighs towards including them. Given that both Magnus and I have now presented use-cases for atomicity, I think this finally swings towards including?
I agree with that
So why I used atomic here, was due to the split between HTTP and Capsules. So I don't see this issue currently motivates the need for ATOMIC capsules. I really would prefer that the necessary parameters for the CONNECT-IP request are in the HTTP request, either in the URI or in an HTTP field. To be clear, I understand the need for the capsules as they are useful for doing things after the initial request, but creating this binding between the HTTP request and the capsules are creating its sets of complexities. Likely bigger than duplicating the carrying of the necessary information results in, especially when they may be use cases related.
I agree I with Magnus and think we should specify a ay to add the address request to the http request. If there is a timing dependency it's better to put all needed information into the same request than specifying extra and complex logic to achieve the same in hindsight. That doesn't mean that we don't need the address request capsule (for later use in the connection). I think we need both.
I dislike having two ways of conveying the same thing. How about a simple HTTP header that tells the receiver that there are 4 capsules coming right after the HTTP headers?
I'd prefer to avoid "atomic capsule" starts and ends. If we need a way to guarantee inclusion of the local address in the first request, having it be in the HTTP request makes sense, either as another URI parameter, a header to say what address you want, or a header to say you will have capsules that need to be parsed before responding. That latter option is flexible, certainly, but could be over-engineered. Another option is to tightly scope a header to the use case we think is relevant. If the use case is "please use the same address as this other request stream I already have for connect-ip or connect-UDP", we could just have a header to say for any connect- request that it is entangled with another and should share some properties. I could imagine this even without CONNECT-IP. Today with private relay, we have to ask the proxies to prefer to use the same local IP for everything in a connection from the client, but letting the client choose what gets grouped might be even nicer. This option also lets you issue multiple requests, say they should share, without needing to know exactly which IP any of them will get assigned first.
Unfortunately requests and headers are end-to-end but streams are hop-by-hop so there is no easy HTTP way to have a request refer to another request. I'd be supportive of adding the header but I'd push back on adding a header that duplicates a capsule. This is starting to feel like something best-served by an extension
You could solve the correlation by having a "group" ID that you attach to all related requests. No need to refer by stream ID.
What is the scope of a group ID? Connection? If so it's the same as stream IDs.
I think this should be some extension, but it could be a UUID too, doesn't need to be connection specific.
Ah, thanks. Yeah UUID would work. Back to the issue at hand, I propose this feature request get moved to an extension.
All of these alternatives strike me as much more complex that the semantics of . I'd rather we have a single mechanism even if it's slightly more powerful and restrain it's use than try to invent new ways to solve each problem that arises.
Atomic doesn't help coordinate between requests on different streams, etc, so it's not really solving the full problem here. Either way, I think this is something to defer to an extension.
Headers don't solve that problem either, so I'm not sure that argument really makes sense in this context. Cross stream coordination seems out of scope to me.
So you are taking this into directions I did not intended. I am just asking for how to ensure that the server does not answers the client's request prior to having received any capsules if they are coming. And the real issue is that the server can't know unless the client either includes the corresponding data in the HTTP request or includes an indication that there will be capsules that are relevant to the requests. So, my main worry is if waiting for capsule to answer will actually work if there are an HTTP 1.x intermediary connection on the path between the client and the server. I guess its is sending the capsule after the request and hope it makes it. Because to my understanding in HTTP datagram the peer does not expect any data to arrive so it must be upgraded. Thus, one can end up in cases where the capsule protocol does not make it, where the HTTP request does arrive.
While we might want to have a more generic extension to relate information to multiple requests, I think the problem Magnus describes needs a solution now. The problem is that there is a dependency between replying/react to a connect request and potentially information send in capsules. The best solution is to send this information together with the connection request instead. I don't see any concern to have a http request or URI parameter and the capsule. What's the problem about that?
Magnus, what is "the client's request" here? Is it the extended-connect itself, or a response to a capsule? If it's the former, the server can't know what capsules, if any, are coming at this time, as we haven't yet established we are using the capsule protocol. If it's the latter, capsules trivially solve this, as you cannot process any of the requests until the capsule is received. Mirja, I'd like to avoid having 2 ways to do things, especially since putting it on the HTTP request is a less-generic mechanism and cannot be reused during the connection, whereas capsules can. If we believe this feature is important, I'd like us to solve it generically, rather than special-casing one use case we are aware of right now.
So the client's request is the HTTP request that is only complete in semantics when combined with the request-address capsule.
Sorry Magnus, I'm not sure I understand what you're trying to say. I don't think we can enforce a semantic that a higher-level HTTP request is only complete after some bytes on the then-negotiated protocol have been exchanged.
But this is really the issue, there is currently no way for a client to ask the server to only provide a targeted connect-IP forwarding if the IP address it can provide is the one the client asks for in a consistent way. My interpretation of the specification is that either; 1) the server will never take the request-addr into account initially for the request, and interpret the request-addr after it has created a Connect-IP forwarding 2) the server will sometime take the request-addr into account by have a short delay awaiting for the request-addr capsule, which may or may not make it in time for the implementation specific timer. This non-consistency or failure to address a use case that I think several was interested in resolving is a real problem. A problem I think we will have to take with us to the meeting.
This ultimately stems from us not having an explicit capsule/message to indicate that forwarding should actually begin. Right now it's implicit as soon as the capsule is assembled with the IP addressing information. This is leading to your proposal to stick more things onto the initial request, whereas I believe the correct solution is to add more capabilities to the capsule protocol to express these scenarios.
I will consider what you are saying. However, I will note that we might have different goals. I do have a need for identifiable streams that can be referred to in extension signalling. Using capsules does not achieve that with the current design as the stream identifier comes from the HTTP request, not the subsequent capsule signalling.
I hope so, constructive discussion relies on all of us considering what the others are saying Given that we're all trying to solve slightly different problems here, I see two outcomes: we have one simple generic solution that happens to work for everyone we punt this to more specific extensions since these problems are not generic
So I think the issue here is what we consider core functionality. My observation here is that Alex is promoting functionality that will make it easy to make quite rich things for the network tunnelling use case that you are promoting. While I am bringing up something that to me appear core for the single endpoint tunnelling. So I think we actually need to understand the issues as well as what usage and how usable this is in common and how to handle where the different use cases actually benefits from having the functionality in different places.
I'll reiterate my suggestion from the meeting: it would be better to have IP-version-specific capsule types for each capsule. It saves a byte and also avoids problems with version mismatches.Thanks! I left 2 minor editorial questions, but feel free to merge as-is.

4.2.1. The ADDRESS_ASSIGN capsule (see iana-types for the value of the  <ins> capsule type) allows an endpoint to inform its peer of the list of IP addresses or prefixes it has assigned to it.  Every capsule contains the full list of IP prefixes currently assigned to the receiver.  Any </ins> of these addresses can be used as the source address on IP packets originated by the receiver of this capsule.  <ins> The ADDRESS_ASSIGN capsule contains a sequence of zero or more Assigned Addresses. Note that an ADDRESS_ASSIGN capsule can also indicate that a previously assigned address is no longer assigned.  An ADDRESS_ASSIGN capsule can also be empty. </ins> In some deployments of CONNECT-IP, an endpoint needs to be assigned an address by its peer before it knows what source address to set on its own packets.  For example, in the Remote Access case (example- remote) the client cannot send IP packets until it knows what address  <ins> to use.  In these deployments, the endpoint that is expecting an address assignment MUST send an ADDRESS_REQUEST capsule.  This isn't required if the endpoint does not need any address assignment, for example when it is configured out-of-band with static addresses. While ADDRESS_ASSIGN capsules are commonly sent in response to ADDRESS_REQUEST capsules, endpoints MAY send ADDRESS_ASSIGN capsules unprompted. </ins> 4.2.2. The ADDRESS_REQUEST capsule (see iana-types for the value of the  <ins> capsule type) allows an endpoint to request assignment of IP addresses from its peer.  The capsule allows the endpoint to </ins> optionally indicate a preference for which address it would get assigned. <ins> The ADDRESS_REQUEST capsule contains a sequence of Requested Addresses. If the IP Address is all-zero (0.0.0.0 or ::), this indicates that the sender is requesting an address of that address family but does not have a preference for a specific address.  In that scenario, the prefix length still indicates the sender's preference for the prefix length it is requesting. </ins> Upon receiving the ADDRESS_REQUEST capsule, an endpoint SHOULD assign an IP address to its peer, and then respond with an ADDRESS_ASSIGN  <ins> capsule to inform the peer of the assignment.  Note that the receiver of the ADDRESS_REQUEST capsule is not required to assign the requested address, and that it can also assign some requested addresses but not others. </ins> 4.2.3.


receiving the response to its IP proxying request, noting however that those may not be processed by the proxy if it responds to the request with a failure, or if the datagrams are received by the proxy <del> before the request. </del>  When a CONNECT-IP endpoint receives an HTTP Datagram containing an IP packet, it will parse the packet's IP header, perform any local

receiving the response to its IP proxying request, noting however that those may not be processed by the proxy if it responds to the request with a failure, or if the datagrams are received by the proxy  <ins> before the request.  Since receiving addresses and routes is required in order to know that a packet can be sent through the tunnel, such optimistic packets might be dropped by the proxy if it chooses to provide different addressing or routing information than what the client assumed. </ins> When a CONNECT-IP endpoint receives an HTTP Datagram containing an IP packet, it will parse the packet's IP header, perform any local


9.  There are significant risks in allowing arbitrary clients to establish a tunnel to arbitrary servers, as that could allow bad actors to send traffic and have it attributed to the proxy.  Proxies

9. <ins> Extensions to CONNECT-IP can define behavior changes to this mechanism.  Such extensions SHOULD define new capsule types to exchange configuration information if needed.  It is RECOMMENDED for extensions that modify addressing to specify that their extension capsules be sent before the ADDRESS_ASSIGN capsule and that they do not take effect until the ADDRESS_ASSIGN capsule is parsed.  This allows modifications to address assignement to operate atomically. Similarly, extensions that modify routing SHOULD behave similarly with regards to the ROUTE_ADVERTISEMENT capsule. 10. </ins> There are significant risks in allowing arbitrary clients to establish a tunnel to arbitrary servers, as that could allow bad actors to send traffic and have it attributed to the proxy.  Proxies


scenarios, endpoints MUST follow the recommendations from BCP38 to prevent source address spoofing. <del> 10. </del>  <del> 10.1. </del>  This document will request IANA to register "connect-ip" in the HTTP Upgrade Token Registry maintained at <<https://www.iana.org/assignments/http-upgrade-tokens>>. <del> 10.2. </del>  This document will request IANA to update the entry for the "masque" URI suffix in the "Well-Known URIs" registry maintained at

scenarios, endpoints MUST follow the recommendations from BCP38 to prevent source address spoofing.  <ins> 11. </ins>  <ins> 11.1. </ins> This document will request IANA to register "connect-ip" in the HTTP Upgrade Token Registry maintained at <<https://www.iana.org/assignments/http-upgrade-tokens>>.  <ins> 11.2. </ins> This document will request IANA to update the entry for the "masque" URI suffix in the "Well-Known URIs" registry maintained at


IANA is requested to update the "Reference" field to include this document in addition to previous values from that field. <del> 10.3. </del>  This document will request IANA to add the following values to the "HTTP Capsule Types" registry created by HTTP-DGRAM:

IANA is requested to update the "Reference" field to include this document in addition to previous values from that field.  <ins> 11.3. </ins> This document will request IANA to add the following values to the "HTTP Capsule Types" registry created by HTTP-DGRAM:


This document defines the "connect-udp" HTTP Upgrade Token. "connect- udp" uses the Capsule Protocol as defined in HTTP-DGRAM. <del> A "connect-udp" request requests that the recipient proxy establish a tunnel over a single HTTP stream to the destination target identified by the "target_host" and "target_port" variables of the URI Template (see client-config).  If the request is successful, the proxy commits to converting received HTTP Datagrams into UDP packets and vice versa </del>  until the tunnel is closed.  Tunnels are commonly used to create an end-to-end virtual connection, which can then be secured using QUIC QUIC or another protocol running over UDP.

The technicalities here are fine but I think someone will pick up on the grammar sooner or later. How about something like below (take or leave it) "Clients issue requests containing a "connect-udp" upgrade token in initiate an UDP tunnel associated with a single HTTP stream. The client indicates, to the proxy, the target of the tunnel using the "targethost" and "targetport" variables of the URI template (see ).

This document defines the "connect-udp" HTTP Upgrade Token. "connect- udp" uses the Capsule Protocol as defined in HTTP-DGRAM.  <ins> Clients issue requests containing a "connect-udp" upgrade token to initiate a UDP tunnel associated with a single HTTP stream.  The target of the tunnel is indicated by the client to the proxy via the "target_host" and "target_port" variables of the URI Template (see client-config).  If the request is successful, the proxy commits to converting received HTTP Datagrams into UDP packets and vice versa </ins> until the tunnel is closed.  Tunnels are commonly used to create an end-to-end virtual connection, which can then be secured using QUIC QUIC or another protocol running over UDP.


udp/{target_host}/{target_port}/" and wishes to open a UDP proxying tunnel to target 192.0.2.42:443, it could send the following request:  3.3. The UDP proxy SHALL indicate a successful response by replying with

Given that this draft is couched in terms of , the use of in HTTP/1.1 is surprising. At the least, a reason should be mentioned.
Closing for now, as I have more serious concerns that may make this OBE.
Reopening.

udp/{target_host}/{target_port}/" and wishes to open a UDP proxying tunnel to target 192.0.2.42:443, it could send the following request: <ins> In HTTP/1.1, this protocol uses the GET method to mimic the design of the WebSocket Protocol WEBSOCKET. </ins> 3.3. The UDP proxy SHALL indicate a successful response by replying with


The path component of the URI Template MUST start with a slash "/". <del> All template variables MUST be within the path component of the URI. </del>  The URI template MUST contain the two variables "target_host" and "target_port" and MAY contain other variables.

The client configuration section says: ... but the examples contain: Which is it?
This was an accident, I suspect it dates back to when the document referred to which contains both path and query. Fixing to mention both path and query via .

The path component of the URI Template MUST start with a slash "/".  <ins> All template variables MUST be within the path or query components of the URI. </ins> The URI template MUST contain the two variables "target_host" and "target_port" and MAY contain other variables.


the method SHALL be "GET". <del> the request-target SHALL use absolute-form (see H1). </del> the request SHALL include a single Host header field containing the origin of the UDP proxy.

Is this strictly necessary?
You're right, it's unnecessary and doesn't add anything. Removing via .

the method SHALL be "GET".  the request SHALL include a single Host header field containing the origin of the UDP proxy.


contains the unmodified payload of a UDP packet (referred to as "data octets" in UDP). <del> Clients MAY optimistically start sending UDP packets in HTTP Datagrams before receiving the response to its UDP proxying request. However, implementors should note that such proxied packets may not be processed by the UDP proxy if it responds to the request with a failure, or if the proxied packets are received by the UDP proxy before the request. </del> By virtue of the definition of the UDP header UDP, it is not possible to encode UDP payloads longer than 65527 bytes.  Therefore, endpoints MUST NOT send HTTP Datagrams with a Payload field longer than 65527

PR in response to Al's OPSDIR review -- Reviewer: Al Morton Review result: Has Nits Hi David, this is the OPS-DIR review. I tried to stay in my lane. I found this paragraph confusing (which doesn't mean it is incorrect, just that someone with limited background read the section 2 requirements list, all MUSTs, and then the paragraph below, which seems to have a conflicting MUST with the SHOULD and MAY that follows). Help readers like me understand the options you are allowing here: If the client detects that any of the requirements above are not met by a URI Template, the client MUST reject its configuration and fail the request without sending it to the UDP proxy. While clients SHOULD validate the requirements above, some clients MAY use a general-purpose URI Template implementation that lacks this specific validation. I see that Christer's GEN_ART review picked-up on this too (I looked after I was done...). In Section 5, there seems to be a possible operations issue for proxy operators: Clients MAY optimistically start sending UDP packets in HTTP Datagrams before receiving the response to its UDP proxying request. However, implementors should note that such proxied packets may not be processed by the UDP proxy if it responds to the request with a failure, or if the proxied packets are received by the UDP proxy before the request. This seems like a good place to limit the amount of optimistic traffic, given that the request is not yet accepted. (also, would the optimistic traffic use Context ID zero?) In Performance Considerations UDP proxies SHOULD strive to avoid increasing burstiness of UDP traffic: they SHOULD NOT queue packets in order to increase batching. This requirement is written qualitatively, so users might "know a violation if they see it", but not hold the proxy system/operator to any specific performance without providing more details here. Inter-packet delay variation measurements on proxy ingress and egress would characterize increased burstiness well. Another solution is s/SHOULD/should/ (I doubt some increased burstiness will be avoidable, or enforceable.) Thanks in advance for considering these comments, Al

contains the unmodified payload of a UDP packet (referred to as "data octets" in UDP).  By virtue of the definition of the UDP header UDP, it is not possible to encode UDP payloads longer than 65527 bytes.  Therefore, endpoints MUST NOT send HTTP Datagrams with a Payload field longer than 65527


Payload field is longer than that limit without buffering the capsule contents.  6. UDP proxies SHOULD strive to avoid increasing burstiness of UDP

Payload field is longer than that limit without buffering the capsule contents. <ins> If a UDP proxy receives an HTTP Datagram before it has received the corresponding request, it SHALL either drop that HTTP Datagram silently or buffer it temporarily (on the order of a round trip) while awaiting the corresponding request. Note that buffering datagrams (either because the request was not yet received, or because the Context ID is not yet known) consumes resources.  Receivers that buffer datagrams SHOULD apply buffering limits in order to reduce the risk of resource exhaustion occuring. For example, receivers can limit the total number of buffered datagrams, or the cumulative size of buffered datagrams, on a per- stream, per-context, or per-connection basis. A client MAY optimistically start sending UDP packets in HTTP Datagrams before receiving the response to its UDP proxying request. However, implementors should note that such proxied packets may not be processed by the UDP proxy if it responds to the request with a failure, or if the proxied packets are received by the UDP proxy before the request and the UDP proxy chooses to not buffer them. </ins> 6. UDP proxies SHOULD strive to avoid increasing burstiness of UDP


consider its CONNECT-UDP request as failed. The proxy that is creating the UDP socket to the destination responds <del> to the CONNECT-UDP request with a 2xx (Successful) response, and indicates it supports HTTP Datagrams by sending the corresponding registration capsule. </del>  Clients MAY optimistically start sending proxied UDP packets before receiving the response to its CONNECT-UDP request, noting however

This text was a mistake I made when converting from Datagram-Flow-Id to capsules.
Section 4 states that the proxy responds to a CONNECT-UDP request with 2xx and a corresponding registration capsule to indicate end-to-end support of datagrams. If the client sends a REGISTERDATAGRAMCONTEXT capsule, the corresponding capsule from the proxy will be of the same kind, and it will register a new server-generated context ID. So now we would have two context IDs for the same stream, which seems a bit unnecessary. Could we simply omit the step where the proxy sends a registration capsule and simply state that a 2xx response to the CONNECT-UDP request is sufficient indication of end-to-end datagram support?
My reading of the spec is different, URL says So for example, if the client sends a request on stream 4 and then REGISTERDATAGRAMCONTEXT { Context ID (0)}, the server will respond with REGISTERDATAGRAMCONTEXT { Context ID (0)} to confirm that the context is accepted.
That makes sense, I was assuming that the "used in both directions" referred to datagrams. I think my confusion in part came from the same section that says: But sending a registration capsule with an already registered context ID is not a new registration I suppose. Maybe it's good to clarify this a bit in the datagram spec. I'll open a separate issue there.
I agree the draft is a bit ambiguous here.
Indeed, the spec is unclear here, my apologies. I got this wrong when I rewrote the old Datagram-Flow-Id text. The server doesn't need to echo the registration capsule here since the client's registration is bidirectional. NAME we should add text to HTTP Datagrams to clarify what we want to do about echoing registrations, is it required allowed forbidden I'm leaning towards (3) unless we have a use case for communicating the fact that a context is "accepted" and in which case I'd say (2).
Aha! In that case I apologise too. This seems important for interop! Now I remember, I think some people felt registration ack wasn't needed as long as there was a way to reject. And we have that with CLOSEDATAGRAMCONTEXT. So I think (3), modelled as implicit accept and explicit close, sounds good. That cuts down the chatter (and probably simplifies some code in my implementation).

consider its CONNECT-UDP request as failed. The proxy that is creating the UDP socket to the destination responds  <ins> to the CONNECT-UDP request with a 2xx (Successful) response. </ins> Clients MAY optimistically start sending proxied UDP packets before receiving the response to its CONNECT-UDP request, noting however


5.1.  UDP proxying does not create an IP-in-IP tunnel, so the guidance in RFC6040 about transferring ECN marks between inner and outer IP headers does not apply.  There is no inner IP header in UDP proxying

A proxy can receive a UDP packet from an origin to a client that cannot fit within a DATAGRAM frame, given either the limit set by the maximum datagram frame size, or based on the current path MTU. In this case, one solution is for the proxy to generate ICMP errors back to the sender. If that sender implements PMTU discovery, it should adjust its size.
I think adding advice here is good, though we can't mandate sending ICMP because most OSes don't let user space applications send ICMP.
Yes, we can't mandate it, but we should recommend it I think. For a full-blown production server, it should be possible.
Recommendation seems sensible. Although this does get me thinking about what the expectations of fragmentation are, we can't expect all UDP protocols to set DF.
The DATAGRAM capsule type offers one way to address this. Capsules can be arbitrarily large, because they'll be reassembled by QUIC. If it won't fit in a QUIC DATAGRAM and you don't want to drop it, it goes in a DATAGRAM capsule. Now, that might not always be desirable, because capsules don't have all the behavior that causes you to choose datagrams in the first place; a proxy that behaves that way will mess with PMTUD, and in the degenerate case cause the server to select an MTU back to the client that always gets encoded in capsules. Perhaps the client should be able to inform the server whether it prefers oversize messages to be tunneled or dropped?

5.1. <ins> When using HTTP/3 with the QUIC Datagram extension DGRAM, UDP payloads are transmitted in QUIC DATAGRAM frames.  Since those cannot be fragmented, they can only carry payloads up to a given length determined by the QUIC connection configuration and the path MTU.  If a proxy is using QUIC DATAGRAM frames and it receives a UDP payload from the target that will not fit inside a QUIC DATAGRAM frame, the proxy SHOULD NOT send the UDP payload in a DATAGRAM capsule, as that defeats the end-to-end unreliability characteristic that methods such as Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) depend on RFC8899.  In this scenario, the proxy SHOULD drop the UDP payload and send an ICMP "Packet Too Big" message to the target RFC4443. 5.2. </ins> UDP proxying does not create an IP-in-IP tunnel, so the guidance in RFC6040 about transferring ECN marks between inner and outer IP headers does not apply.  There is no inner IP header in UDP proxying


recovery (e.g., QUIC), and the underlying HTTP connection runs over TCP, the proxied traffic will incur at least two nested loss recovery mechanisms.  This can reduce performance as both can sometimes <del> independently retransmit the same data.  To avoid this, HTTP/3 datagrams SHOULD be used. </del>  6.1.

recovery (e.g., [QUIC]), and the underlying HTTP connection runs over TCP, the proxied traffic will incur at least two nested loss recovery mechanisms. This can reduce performance as both can sometimes independently retransmit the same data. To avoid this, HTTP/3 datagrams SHOULD be used. This text could maybe be clearer. Is it trying to say "You SHOULD use H3 + Datagram" or "You SHOULD use H3 and if you do you should use datagram". I.e., is it possible to use H3 but not datagram?
You're right, this is unclear. That text predates the refactor of HTTP/3 Datagram to HTTP Datagrams, so we should tweak it to say "To avoid this, UDP proxying SHOULD be performed over HTTP/3 to allow leveraging the QUIC DATAGRAM frame."

recovery (e.g., QUIC), and the underlying HTTP connection runs over TCP, the proxied traffic will incur at least two nested loss recovery mechanisms.  This can reduce performance as both can sometimes  <ins> independently retransmit the same data.  To avoid this, UDP proxying SHOULD be performed over HTTP/3 to allow leveraging the QUIC DATAGRAM frame. </ins> 6.1.


that datagram silently or buffer it temporarily while awaiting the creation of the corresponding stream.  4. This specification introduces the Capsule Protocol.  The Capsule Protocol is a sequence of type-length-value tuples that new HTTP <del> Methods or new HTTP Upgrade Tokens can choose to use.  It allows endpoints to reliably communicate request-related information end-to- end on HTTP request streams, even in the presence of HTTP intermediaries.  The Capsule Protocol can be used to exchange HTTP Datagrams when HTTP is running over a transport that does not support the QUIC DATAGRAM frame. </del>  This specification defines the "data stream" of an HTTP request as the bidirectional stream of bytes that follow the headers in both

This may be answered and I just missed it. After reading I think that for HTTP/1 and HTTP/2 Datagrams (via capsules) can only be sent for new methods/upgrade tokens. But it wasn't clear to me if that same property was true for HTTP/3. For example, would it be valid to send HTTP/3 datagrams along with a GET request? If so, I think this means that for HTTP/3 a GET request could have both a body AND datagrams?
That's a very good point. If anything, we should be prescriptive about what endpoints do if they receive a datagram associated with an existing method like GET. I suspect drop or error are the most likely candidates here.
I vote for close the connection with error. The datagram has the relate to something in the request. If the request doesn't or cannot articulate a datagram use, the sender of datagram is probably broken or stupid.
Since datagrams are strongly associated with a stream, I think it'd be more consistent to make this a stream error. Regardless, folks my want an extension to GET that allows sending datagrams with it, but it makes sense to require that this extension be negotiated via headers or settings first, so the semantics of such datagrams are agreed upon beforehand. So, I'm supportive of making this a stream error, with the understanding that any extension can lift this requirement between consenting parties.
I'd prefer to make people suffer but I could live with a stream error. Like you suggest, by letting people people agree on a change of requirements, we support extension. But the default of erroring helps datagram avoid the mess othat GET with body is.
Also, I reserve the right to count the number of these failures and close the connection if it reaches my annoyance threshold
Ah yes . Sounds good, I'll write up a PR for this once the design team PRs are landed.
Sounds good to me. An extension could just as easily lift a connection error requirement as it could a stream error requirement in case that had any bearing on the thinking here. (A connection error might be nice because it prevents a confused peer from sending a possibly incessant stream of datagrams. On the other hand, confused peers gonna be confused and David's point about datagrams being strongly associated with a request is a good point)
I think it should be a stream error to enable method-agnostic gateways and proxies, which may be multiplexing different clients' traffic onto a single next-hop connection.
In , NAME points out that Content-Type doesn't make sense with the capsule protocol. Should we prohibit it?
In , NAME points out that status codes 204, 205, and 206 don't make sense with the capsule protocol. Should we prohibit them?
The spec currently says: In HTTP/1.x, the message content is generally delineated by the Content-Length header field or the Transfer-Encoding; another request can follow on the same connection. One of the (many) ways in which CONNECT and Upgrade are special is that in H1 it takes over the connection and makes the request extend to the end of the connection, preventing any further requests from being made. The description attempts to be generic about method, but implicitly assumes an indefinite length stream of bytes which (in H1) is only true of CONNECT or Upgrade. This concept is correct for what we have in mind, but the boundaries aren't crisply described right now. NAME may have opinions.
The sentence right after the bit you pasted is: That constrains this to CONNECT/Upgrade/new methods. Is that not enough?
I think "new methods" is probably the most questionable. It's not clear to me that a new method can obtain the special behaviors of CONNECT. If it were restricted to upgrade tokens (whether with HTTP/1.1 Upgrade or RFC 8441 Extended CONNECT), I think that would address the concern.
I believe what he means is this definition of a data stream only holds for CONNECT requests. There is no mechanism to extend that to new request methods since all other methods are required to have length-delimited data (or no data).
Likewise, I don't know of any reason we would want to support such extension methods in the future, since that is a known failure point for CONNECT. It is far simpler for a new method to require chunked or data frames.
Restricting this to extended CONNECT and Upgrade sounds reasonable to me
For Upgrade, the new protocol takes over after the current response is complete. Hence, the description above doesn't really work for Upgrade either.
NAME the intent of that text was to mean "after the current response is complete" - do you have a proposal for phrasing that would work better?
Semantics says: URL I think is consistent with the definition of "data stream" in this document. (And in fact uses the term "data stream" without defining it.) That doesn't seem to match deferring the new protocol until after the response.
I don't think there is any technical distinction between the two descriptions; it's nomenclature to say that what follows the CONNECT is a tunnel ended by connection closure, whereas what follows Upgrade is a different protocol that might very well come back to this one (as determined by the other protocol).
And point to URL This is an important part of the security analysis.
Only if you believe that the Sec- prefix is useful for the Capsule-Protocol header field. I don't.
Sorry, I don't mean that it's the only thing that makes it work, merely that if were going to talk about how to analyze it, this is something we should say.
NAME can you clarify your intent? Your issue title starts with "Add to JS" but I suspect you didn't mean that we should modify the JavaScript specification. Would a note next to where the "Capsule-Protocol" header is defined resolve this?
Aaargh. I meant "add to the security considerations".
Thanks, that makes more sense :) Adding something to security considerations sounds good to me, I'll add text to the . Note that this was filed on the wrong repository, is the droid you're looking for.
So this assumption is useful in that it helps us avoid an analysis. Though my sense is that that analysis isn't especially difficult. The header field exists to enable datagram forwarding behaviour in an intermediary. We only have to show that there is no harm inflicted if a client engages that behaviour for requests, under the constraint that the client is otherwise authorized to make from a web context. The risk comes if this forwarding behaviour somehow generates different semantics as a result. As the same client also provides the stream of data that will be forwarded, it is trivial to see that they are already in a position to engage whatever semantics they choose. The only scenario that might benefit an attacker is where the elision of datagrams (or things that look like them) might be used to evade security protections that scan the stream of data. For an attack to be effective, those same protections would have to be ignorant of datagram forwarding behaviour at the same intermediary. This binding to CONNECT is a useful shortcut that means we don't need to engage with all that stuff, which wouldn't be that easy to write down. (This aversion to engagement is, I believe, a large part of why people want to slap "Sec-" on all new headers.)
MT's framing of this is helpful. Adding some security consideration about what might go wrong for an intermediary seems potentially useful. Spending text on why a browser is special in this regard seems less compelling to nme.
I was about to write a PR for this, but I think we should first If we decide that capsules are only allowed for HTTP upgrade tokens (and not new methods) then we've restricted ourselves to CONNECT and Upgrade which are both inaccessible from JavaScript.
LGTM thanks

that datagram silently or buffer it temporarily while awaiting the creation of the corresponding stream. <ins> HTTP/3 datagrams MUST only be sent with an association to a stream that supports semantics for HTTP Datagrams.  For example, existing HTTP methods GET and POST do not define semantics for associated HTTP Datagrams; therefore, HTTP/3 datagrams cannot be sent associated with GET or POST request streams.  If an endpoint receives an HTTP/3 datagram associated with a method that has no known semantics for HTTP Datagrams, it MUST abort the corresponding stream with H3_GENERAL_PROTOCOL_ERROR.  Future extensions MAY remove these requirements if they define semantics for such HTTP Datagrams and negotiate mutual support. </ins> 4. This specification introduces the Capsule Protocol.  The Capsule Protocol is a sequence of type-length-value tuples that new HTTP  <ins> Upgrade Tokens can choose to use.  It allows endpoints to reliably communicate request-related information end-to-end on HTTP request streams, even in the presence of HTTP intermediaries.  The Capsule Protocol can be used to exchange HTTP Datagrams when HTTP is running over a transport that does not support the QUIC DATAGRAM frame. </ins> This specification defines the "data stream" of an HTTP request as the bidirectional stream of bytes that follow the headers in both


HTTP message content after the headers. Note that use of the Capsule Protocol is not required to use HTTP <del> Datagrams.  If a new HTTP Method or Upgrade Token is only defined over transports that support QUIC DATAGRAM frames, they might not need a stream encoding.  Additionally, definitions of new HTTP Methods or of new HTTP Upgrade Tokens can use HTTP Datagrams with their own data stream protocol.  However, new HTTP Method or Upgrade Tokens SHOULD use the Capsule Protocol unless they have a good reason not to. </del>  4.1. <del> Definitions of new HTTP Methods or of new HTTP Upgrade Tokens can state that their data stream uses the Capsule Protocol.  If they do so, that means that the contents of their data stream uses the following format (using the notation from the "Notational Conventions" section of QUIC): </del>  A variable-length integer indicating the Type of the capsule. Endpoints that receive a capsule with an unknown Capsule Type MUST

HTTP message content after the headers. Note that use of the Capsule Protocol is not required to use HTTP  <ins> Datagrams.  If a new HTTP Upgrade Token is only defined over transports that support QUIC DATAGRAM frames, they might not need a stream encoding.  Additionally, definitions of new HTTP Upgrade Tokens can use HTTP Datagrams with their own data stream protocol. However, new HTTP Upgrade Tokens that wish to use HTTP Datagrams SHOULD use the Capsule Protocol unless they have a good reason not to. </ins> 4.1.  <ins> Definitions of new HTTP Upgrade Tokens can state that their data stream uses the Capsule Protocol.  If they do so, that means that the contents of their data stream uses the following format (using the notation from the "Notational Conventions" section of QUIC): </ins> A variable-length integer indicating the Type of the capsule. Endpoints that receive a capsule with an unknown Capsule Type MUST


By virtue of the definition of the data stream, the Capsule Protocol is not in use on responses unless the response includes a 2xx <del> (Successful) status code.  The Capsule Protocol MUST NOT be used with messages that contain Content-Length or Transfer-Encoding header fields. </del>  4.2. <del> Definitions of new HTTP Methods or of new HTTP Upgrade Tokens that use the Capsule Protocol MAY use the Capsule-Protocol header field to simplify intermediary processing. </del>  "Capsule-Protocol" is an Item Structured Header RFC8941.  Its value MUST be a Boolean.  Its ABNF is:

By virtue of the definition of the data stream, the Capsule Protocol is not in use on responses unless the response includes a 2xx  <ins> (Successful) status code. The Capsule Protocol MUST NOT be used with messages that contain Content-Length, Content-Type, or Transfer-Encoding header fields. Additionally, HTTP status codes 204 (No Content), 205 (Reset Content), and 206 (Partial Content) MUST NOT be sent on responses that use the Capsule Protocol. </ins> 4.2.  <ins> Definitions of new HTTP Upgrade Tokens that use the Capsule Protocol MAY use the Capsule-Protocol header field to simplify intermediary processing. </ins> "Capsule-Protocol" is an Item Structured Header RFC8941.  Its value MUST be a Boolean.  Its ABNF is:


?1.  A Capsule-Protocol header field with a value of ?0 has the same semantics as when the header is not present.  Intermediaries MAY use this header field to allow processing of HTTP Datagrams for unknown <del> HTTP methods or unknown HTTP Upgrade Tokens. </del>  The Capsule-Protocol header field MUST NOT be sent multiple times on a message.  The Capsule-Protocol header field MUST NOT be used on

?1.  A Capsule-Protocol header field with a value of ?0 has the same semantics as when the header is not present.  Intermediaries MAY use this header field to allow processing of HTTP Datagrams for unknown  <ins> HTTP Upgrade Tokens; note that this is only possible for HTTP Upgrade or Extended CONNECT. </ins> The Capsule-Protocol header field MUST NOT be sent multiple times on a message.  The Capsule-Protocol header field MUST NOT be used on


datagrams, it's best for all implementations that support this feature to always send this Settings parameter, see setting.  8. 8.1.

datagrams, it's best for all implementations that support this feature to always send this Settings parameter, see setting. <ins> Since use of the Capsule Protocol is restricted to new HTTP Upgrade Tokens, it is not accessible from Web Platform APIs (such as those commonly accessed via JavaScript in web browsers). </ins> 8. 8.1.


the security and congestion-control properties of QUIC.  However, QUIC DATAGRAM frames do not provide a means to demultiplex application contexts.  This document describes how to use QUIC <del> DATAGRAM frames when the application protocol running over QUIC is HTTP/3.  It associates datagrams with client-initiated bidirectional streams.  Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP. </del>  1.

In Section 2 we start with the statement So let's just use that clearer description in the abstract and introduction too,

the security and congestion-control properties of QUIC.  However, QUIC DATAGRAM frames do not provide a means to demultiplex application contexts.  This document describes how to use QUIC  <ins> DATAGRAM frames with HTTP/3 by association with HTTP requests. Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP. </ins> 1.


leveraging the security and congestion-control properties of QUIC. However, QUIC DATAGRAM frames do not provide a means to demultiplex application contexts.  This document describes how to use QUIC <del> DATAGRAM frames when the application protocol running over QUIC is HTTP/3 H3.  It associates datagrams with client-initiated bidirectional streams.  Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP. </del>  This document is structured as follows:

leveraging the security and congestion-control properties of QUIC. However, QUIC DATAGRAM frames do not provide a means to demultiplex application contexts.  This document describes how to use QUIC  <ins> DATAGRAM frames with HTTP/3 H3 by association with HTTP requests. Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP. </ins> This document is structured as follows:


large as to not be usable, the implementation SHOULD discard the capsule without buffering its contents into memory. <del> Note that use of the Capsule Protocol is not required to use HTTP Datagrams.  If an HTTP extension that uses HTTP Datagrams is only defined over transports that support QUIC DATAGRAM frames, it might not need a stream encoding.  Additionally, HTTP extensions can use HTTP Datagrams with their own data stream protocol.  However, new HTTP extensions that wish to use HTTP Datagrams SHOULD use the Capsule Protocol unless they have a good reason not to. </del>  4.

This is a good step but I think it overlooks one of the points that Magnus articulated. If an HTTP extension does what we say here, it might fall foul of intermediaries and protocol version conversion. That not some we have to solve but I suspect if we can concisely describe those considerations we would address the issue.
Good point, added text
Thanks, this is much clearer and is a descent explanation of the issues and motivation behind the should. I guess a more correct part will require much more text.
The first SHOULD should be a MUST because there is a clear exception specified but in all other cases this is a MUST. The second SHOULD should really be a MUST. Or why is that a SHOULD? If there is a reason for a SHOULD this needs to be explained but I think it would break interoperability.
I personally preferred MUST, however the consensus of the design team was SHOULD, and that was confirmed by the WG. Let's no reopen that unless we have new information.
On , NAME said:
I think the main motivation was that the MUST was unenforceable, and that there will be intermediaries that explicitly want to block unknown extensions for security reasons.
Whatever we might prefer, isn't this a case where whatever the specification says, intermediaries will do what they want?
I agree. That's why in the interest of making progress I'd rather move forward with the design team consensus instead of reopening this topic.
design team outputs don't have any special status here; perhaps the answer is not to say "SHOULD this" or "MUST that" but to instead articulate the intent behind the design and the potential consequences of not complying with that intent. Perhaps the key reason for mandating forwarding is that the meaning of various protocol elements is only valid in the context of all of the messages that an endpoint says. That is, you might send a bunch of datagram capsules that have meaning derived from other capsules. Remove the other capsules and you change the meaning of those datagram capsules. An intermediary that adds, modifies, or removes any capsules needs to understand the totality of the effect of their interventions. This is why I remain skeptical about the value of the generic capsule protocol. It only has value if it can be acted upon generically, but it is not obvious that it can be. Put differently, the existence of a generic capsule protocol implies a number of constraints on the operation of extensions that are not obvious and not clearly articulated. NAME might be asking about similar effects in .
So lets start with explaining the interoperability issue that is at the core of this: So the draft currently has several statements that interact with each other to cause this interoperability issue. Section 3.5 says: 'Note that use of the Capsule Protocol is not required to use HTTP Datagrams. If an HTTP extension that uses HTTP Datagrams is only defined over transports that support QUIC DATAGRAM frames, it might not need a stream encoding.' Section 3.5 also says: 'An intermediary can reencode HTTP Datagrams as it forwards them. In other words, an intermediary MAY send a DATAGRAM capsule to forward an HTTP Datagram which was received in a QUIC DATAGRAM frame, and vice versa.' Thus the following may occur: Endpoint 1 sends a HTTP datagram as HTTP/3 Datagram over QUIC datagram. The HTTP intermediary re-encode this blind of its context to an Capsule Datagram and forward it to another HTTP intermediary that forwards it to an HTTP/3 endpoint using Datagram Capsule. As this HTTP datagram usage is one that does not require to support of Capsule Datagram this endpoint is not setup to handle this Datagram capsule and discards it. So this can either be fixed in various ways, not only what this issue text suggests: requiring the Datagram capsule support for all HTTP datagram handling nodes. In other words change the first quote. Require the HTTP intermediary to re-encode any Datagram capsules to HTTP/3 datagram if the next hop is know to support it. i.e. make additional requirements on how HTTP Intermediaries act when forwarding. Forbid blind forwarding of HTTP datagram in HTTP intermediaries. I think we should settle this part before going back to see how the text Mirja suggested changing matter. I think 1 and 2 are both working solutions, and would like to avoid 3. I think there is also a question on the implication of what it means to support HTTP datagram when one is an HTTP/3 endpoint or intermediary. Who is expected to support the Datagram capsule if the next node is not capable? So I think at the bottom this issue is really the question about the possibility to convert between HTTP/3 Datagram and Datagram capsule. I think we need to settle that question first. It is a question of what requirements one have on endpoints vs intermediaries. Lets start in that end.
I actually think I prefer your option 3, caveated by saying "if you're an intermediary and you don't know the upgrade token, don't insert datagram capsules" . What concern do you have about option 3?
Okay, I am skeptical against 3) on how it may make deployment of future extensions that require HTTP Datagram but doesn't need other than Intermediary forwarding. In that case deployment could be hampered if not all HTTP intermediaries are also HTTP/3 capable. It appears that using capsule protocol would be easier to enable over a legacy system. That might be a misconception from my part.
NAME Thank you for clarifying, now I understand where the disconnect is. The draft currently says and you interpreted that as but that's not what we intended, we meant . I've written up to remedy this
NAME great that we managed to sort out what was the issue. As Lucas noted in the PR unless all HTTP Datagram implementation support and accept receiving Datagram capsule, even if not intended by the HTTP Extension, if unaware of HTTP extension transformation is allowed, it can fail. I think we need a bit more feedback on where people stand in this aspect.
Thanks NAME If the HTTP extension doesn't use capsules, then the implementation won't parse the data stream as capsules so there is no risk of accidentally receiving capsules. We added text to to clarify the risks of not using the capsule protocol.
I think this was closed prematurely because the issue originally was about MUST or SHOULD and I don't think we concluded on this. If the argument is that this is not enforceable, I think we should not use normatively language at all (and say something like "intermediaries are expected ..."). However, using SHOULD were we actually mean MUST, weakens the requirement and risk that this is misunderstood to be optional (while I think this is the core of the whole capsule protocol).
Reopening to discuss SHOULD vs MUST.
I'd consider capsules to be similar to header fields (headers specifically, not trailers). Here's what HTTP says about them in URL >A proxy MUST forward unrecognized header fields unless the field name is listed in the header field () or the proxy is specifically configured to block, or otherwise transform, such fields. Other recipients SHOULD ignore unrecognized header and trailer fields. Adhering to these requirements allows HTTP's functionality to be extended without updating or removing deployed intermediaries. Yeah, in actuality an intermediary can do lots of stuff, and in practice they do. But if a MUST is good enough for HTTP headers, why isn't it here?
From memory it was either NAME or NAME who cared strongly about this not being a MUST. I'm fine either way as long as we don't drag this one needlessly.
To summarize the discussion on this issue up to this point: we're debating whether to tell intermediaries that they MUST or SHOULD forward unknown capsules unmodified implementors of intermediaries will not react to either one of these words differently endpoints have no way of enforcing this MUST some folks felt very strongly against MUST the working group landed on this design and no new information has surfaced since Based on the points above, there is no reason to hold up document progress based on a single word that will not have any impact. Therefore I'm closing this issue with no action. Hearing no objections, we’re declaring consensus. Thanks again to the participants of the Design Team for their hard work in preparing these changes, and to everyone else for offering reviews and feedback! Best, Chris and Eric

large as to not be usable, the implementation SHOULD discard the capsule without buffering its contents into memory.  <ins> Note that it is possible for an HTTP extension to use HTTP Datagrams without using the Capsule Protocol.  For example, if an HTTP extension that uses HTTP Datagrams is only defined over transports that support QUIC DATAGRAM frames, it might not need a stream encoding.  Additionally, HTTP extensions can use HTTP Datagrams with their own data stream protocol.  However, new HTTP extensions that wish to use HTTP Datagrams SHOULD use the Capsule Protocol as failing to do so will make it harder for the HTTP extension to support versions of HTTP other than HTTP/3 and will prevent interoperability with intermediaries that only support the Capsule Protocol. </ins> 4.


8. <del> This document does not have additional security considerations beyond those defined in QUIC and DGRAM. </del>  9.

As discussed at IETF 110, some MASQUE servers may prefer to avoid sticking out (i.e. they may wish to be indistinguishable from a non-MASQUE-capable HTTP/3 server). The H3_DATAGRAM SETTINGS parameter may stick out. Therefore, we should add a note about this to the Security Considerations section. A simple solution could be to encourage widespread HTTP/3 servers to always send this.

8.  <ins> Since this feature requires sending an HTTP/3 Settings parameter, it "sticks out".  In other words, probing clients can learn whether a server supports this feature.  Implementations that support this feature SHOULD always send this Settings parameter to avoid leaking the fact that there are applications using HTTP/3 datagrams enabled on this endpoint. </ins> 9.


given QUIC connection, HTTP datagrams contain two layers of multiplexing.  First, the QUIC DATAGRAM frame payload starts with an encoded stream identifier that associates the datagram with a given <del> QUIC stream.  Second, datagrams carry a context identifier (see datagram-contexts) that allows multiplexing multiple datagram </del>  contexts related to a given HTTP request.  Conceptually, the first layer of multiplexing is per-hop, while the second is end-to-end.

This change allows clients to disable contexts for a given stream. This uses a new REGISTERDATAGRAMNO_CONTEXT capsule for negotiation. The important property here is that it requires capsule support even when contexts are not required. This is critical to the health of the ecosystem as it will ensure that intermediaries that support datagrams but not capsules cannot be deployed, as that would prevent future extensibility.
Editorial comments aside, I support the protocol feature of an optional DATAGRAM Context ID. Using a registration capsule, as proposed in this PR, is a very logical way of achieving that. I plan to implement this in my WIP code.
Looks like there's support for merging this. Some additional editorial work is needed, but we'll do that in followups.
This issue assumes that decide to go with the two-layer design described in . Given that design, some applications might not need the multiplexing provided by context IDs. We have multiple options here: Make context ID mandatory Applications that don't need it waste a byte per datagram Negotiate the presence of context IDs using an HTTP header Context IDs would still be mandatory to implement on servers because the client might send that header Have the method determine whether context IDs are present or not This would prevent extensibility on those methods Create a REGISTERNOCONTEXT message This assumes we use the Message design from We add a register message that means that this stream does not use context IDs This allows avoiding the byte overhead without sacrificing extensibility
Making the context ID mandatory is simple, although slightly wasteful. For the variations where it is optional, I prefer the one that uses a header. It could work with a variant of where we do Header + Message, and the Header determines whether or not you have contexts, and whether or not they can be dynamic.
What are the benefits of message over header to make it optional? To me it seems like header is sufficient, because the context IDs are end-to-end, and should not affect intermediaries, making the header a natural place to put it. I think having the context ID be the default behavior and the header is to opt-out is the right decision if we were to allow removing it.
This is a bit of a bike-shed, but why would it default to having context-IDs instead of not having them?
I think the second option "Negotiate the presence of context IDs using an HTTP header" is the best personally. In terms of: "Context IDs would still be mandatory to implement on servers because the client might send that header", I assume server in this context is the final application server, not a proxy? Even so, I'd argue it's applications which decide if they need this functionality, so if a server only implemented one application and it didn't use Context-IDs, then I don't see why it would need to implement it.
Ian, in your comment, are you talking about an intermediary when you say "proxy"? If so, then an intermediary need not implement anything based on the payload of than H3 DATAGRAM, it only has to pass the data along. That may be worth a clarification.
Having context ID optional has a nice future-proof property - other uses of datagrams in HTTP/3 can decide if they want the second layer or not. I wouldn't even state it as application needing multiplexing or not. Other applications might find it very useful to include a second ((third, fourth, fifth) layer of frame header. I think its fine for us to state as much in this in the spec, while also defining an explicit second layer for multiplexing.
Yes, by proxy I meant intermediary. And I agree about what intermediaries need to do, I just wanted to ensure I understood what server meant when David used it above. Yup, whenever all this gets written up, we can make it clear that intermediaries can ignore much of this.
The method defines the semantics of datagrams for a particular request, thus I think the third option makes most sense. I don't see a point in using explicit negotiation, since in the two cases I can think of the top of the head, the answer is always clear from the method (CONNECT-IP seems to always want context IDs, WebTransport does not ever want context IDs). If some method starts out without context, but wants to add context later, it can add its own negotiation.
One set of use cases for which the method approach(3) is best are those where there are multiple context IDs but they're predefined by the method and don't need negotiation. My strawman is WebRTC.
Looks good overall.

given QUIC connection, HTTP datagrams contain two layers of multiplexing.  First, the QUIC DATAGRAM frame payload starts with an encoded stream identifier that associates the datagram with a given  <ins> QUIC stream.  Second, datagrams optionally carry a context identifier (see datagram-contexts) that allows multiplexing multiple datagram </ins> contexts related to a given HTTP request.  Conceptually, the first layer of multiplexing is per-hop, while the second is end-to-end.


the datagram: the context identifier then maps to a compression context that the receiver can use to reconstruct the elided data. <del> Contexts are identified within the scope of a given request by a numeric value, referred to as the context ID.  A context ID is a 62-bit integer (0 to 2^62-1). </del>  While stream IDs are a per-hop concept, context IDs are an end-to-end concept.  In other words, if a datagram travels through one or more

the datagram: the context identifier then maps to a compression context that the receiver can use to reconstruct the elided data.  <ins> Contexts are optional, their use is negotiated on each request stream using registration capsules, see register-capsule and register-no- context-capsule.  When contexts are used, they are identified within the scope of a given request by a numeric value, referred to as the context ID.  A context ID is a 62-bit integer (0 to 2^62-1). </ins> While stream IDs are a per-hop concept, context IDs are an end-to-end concept.  In other words, if a datagram travels through one or more


streams, and those have stream IDs that are divisible by four.) A variable-length integer indicating the context ID of the <del> datagram (see datagram-contexts). </del>  The payload of the datagram, whose semantics are defined by individual applications.  Note that this field can be empty.

streams, and those have stream IDs that are divisible by four.) A variable-length integer indicating the context ID of the  <ins> datagram (see datagram-contexts).  Whether or not this field is present depends on which registration capsules were exchanged on the associated stream: if a REGISTER_DATAGRAM_CONTEXT capsule (see register-capsule) has been sent or received on this stream, then the field is present; if a REGISTER_DATAGRAM_NO_CONTEXT capsule (see register-no-context-capsule) has been sent or received, then this field is absent; if neither has been sent or received, then it is not yet possible to parse this datagram and the receiver MUST either drop that datagram silently or buffer it temporarily while awaiting the registration capsule. </ins> The payload of the datagram, whose semantics are defined by individual applications.  Note that this field can be empty.


Servers MUST NOT send a REGISTER_DATAGRAM_CONTEXT capsule on a stream before they have received at least one REGISTER_DATAGRAM_CONTEXT <del> capsule from the client on that stream.  This ensures that clients control whether datagrams are allowed for a given request.  If a </del>  client receives a REGISTER_DATAGRAM_CONTEXT capsule on a stream where <del> the client has not yet sent a REGISTER_DATAGRAM_CONTEXT capsule, the </del>  client MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. 4.2.  The CLOSE_DATAGRAM_CONTEXT capsule (type=0x01) allows an endpoint to inform its peer that it will no longer send or parse received datagrams associated with a given context ID.  Its Capsule Data field

Servers MUST NOT send a REGISTER_DATAGRAM_CONTEXT capsule on a stream before they have received at least one REGISTER_DATAGRAM_CONTEXT  <ins> capsule or one REGISTER_DATAGRAM_NO_CONTEXT capsule from the client on that stream.  This ensures that clients control whether datagrams are allowed for a given request.  If a client receives a REGISTER_DATAGRAM_CONTEXT capsule on a stream where the client has not yet sent a REGISTER_DATAGRAM_CONTEXT capsule, the client MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. Servers MUST NOT send a REGISTER_DATAGRAM_CONTEXT capsule on a stream where it has received a REGISTER_DATAGRAM_NO_CONTEXT capsule.  If a </ins> client receives a REGISTER_DATAGRAM_CONTEXT capsule on a stream where  <ins> the client has sent a REGISTER_DATAGRAM_NO_CONTEXT capsule, the </ins> client MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. 4.2. <ins> The REGISTER_DATAGRAM_NO_CONTEXT capsule (type=0x03) allows a client to inform the server that datagram contexts will not be used with this stream.  It also informs the server of the encoding and semantics of datagrams associated with this stream.  Its Capsule Data field consists of: A string of comma-separated key-value pairs to enable extensibility, see the definition of the same field in register- capsule for details. Note that this registration is unilateral and bidirectional: the client unilaterally defines the semantics it will apply to the datagrams it sends and receives with this stream. Endpoints MUST NOT send DATAGRAM frames without a Context ID until they have either sent or received a REGISTER_DATAGRAM_NO_CONTEXT Capsule.  However, due to reordering, an endpoint that receives a DATAGRAM frame before receiving either a REGISTER_DATAGRAM_CONTEXT capsule or a REGISTER_DATAGRAM_NO_CONTEXT capsule MUST NOT treat it as an error, it SHALL instead drop the DATAGRAM frame silently, or buffer it temporarily while awaiting a REGISTER_DATAGRAM_NO_CONTEXT capsule or the corresponding REGISTER_DATAGRAM_CONTEXT capsule. Servers MUST NOT send the REGISTER_DATAGRAM_NO_CONTEXT capsule.  If a client receives a REGISTER_DATAGRAM_NO_CONTEXT capsule, the client MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. Clients MUST NOT send more than one REGISTER_DATAGRAM_NO_CONTEXT capsule on a stream.  If a server receives a second REGISTER_DATAGRAM_NO_CONTEXT capsule on the same stream, the server MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. Clients MUST NOT send a REGISTER_DATAGRAM_NO_CONTEXT capsule on a stream before they have sent at least one HEADERS frame on that stream.  This removes the need to buffer REGISTER_DATAGRAM_CONTEXT capsules when the server needs information from headers to determine how to react to the capsule.  If a server receives a REGISTER_DATAGRAM_NO_CONTEXT capsule on a stream that hasn't yet received a HEADERS frame, the server MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. Clients MUST NOT send both REGISTER_DATAGRAM_CONTEXT capsules and REGISTER_DATAGRAM_NO_CONTEXT capsules on the same stream.  If a server receives both a REGISTER_DATAGRAM_CONTEXT capsule and a REGISTER_DATAGRAM_NO_CONTEXT capsule on the same stream, the server MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. 4.3. </ins> The CLOSE_DATAGRAM_CONTEXT capsule (type=0x01) allows an endpoint to inform its peer that it will no longer send or parse received datagrams associated with a given context ID.  Its Capsule Data field


MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. <del> 4.3. </del>  The DATAGRAM capsule (type=0x02) allows an endpoint to send a datagram frame over an HTTP stream.  This is particularly useful when

MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR.  <ins> 4.4. </ins> The DATAGRAM capsule (type=0x02) allows an endpoint to send a datagram frame over an HTTP stream.  This is particularly useful when


Its Capsule Data field consists of: A variable-length integer indicating the context ID of the <del> datagram (see datagram-contexts). </del>  The payload of the datagram, whose semantics are defined by individual applications.  Note that this field can be empty.

Its Capsule Data field consists of: A variable-length integer indicating the context ID of the  <ins> datagram (see datagram-contexts).  Whether or not this field is present depends on which registration capsules were exchanged on the associated stream: if a REGISTER_DATAGRAM_CONTEXT capsule (see register-capsule) has been sent or received on this stream, then the field is present; if a REGISTER_DATAGRAM_NO_CONTEXT capsule (see register-no-context-capsule) has been sent or received, then this field is absent; if neither has been sent or received, then it is not yet possible to parse this datagram and the receiver MUST either drop that datagram silently or buffer it temporarily while awaiting the registration capsule. </ins> The payload of the datagram, whose semantics are defined by individual applications.  Note that this field can be empty.


3.2.1. <del> There are many reasons why path characteristics might change suddenly, but we can divide these reasons into two categories: </del>  If the path topology changes.  For example, routing changes, which can happen in normal operation, may result in traffic being

This tries to address both of:
Discussion from editor's conference call: Can we provide a reference for useful properties? Network analytics, application analytics, or both? Currently application analytics, which is OK. Is that clear enough? Who is supposed to notice changes from an expected baseline? Is mentioning QLOG helpful? Have we said clearly enough that baselines themselves can fluctuate, before the kinds of path characteristic changes we're talking about kick in?
I think just "baseline" is clear enough to me, in context with this section listing some relevant stats. I guess "baseline pattern of some relevant statistics" is maybe more precise, but I'm not sure "baseline pattern" really gets there.
from NAME 's review (URL) Section 5.5.3. Wide and Rapid Variation in Path Capacity The statement "As many end devices have moved to wireless connectivity for the final hop (Wi-Fi, 5G, or LTE), new problems in bandwidth detction have emerged from radio interference and signal strength effects." could be moved to earlier parts of the document. Quite a bit of new computers apparently only have Wifi connectivity and no Ethernet port, i.e., Wifi may just be their default. Also, wireless may not only be used on the last hop, for instance in meshed setups. This may make the problem even harder.
This comment helpfully points out the changing network architecture (a LOT of wireless), and we should be clearer about what we're talking about in Section 3.2 (our mental was mostly wired) and in 5.5.3 (where we focused on wireless). This material should go in Section 3.2, and should be referenced in 5.5.3..
Related to
From NAME (URL) Section 3.2.1. Recognizing Changes from an Expected Baseline This section apparently assumes relatively static path properties, e.g., fixed network connectivity. It would be more useful to analyze the impact of Wifi and 4G/5G networks in one place. Some of this follows later in sections 3.2.1 and Yet, the split between these three sections is unclear. Having a discussion about today's Internet path characteristics and the dynamics at one place could be more useful.
Related to
This works for me. I'll merge it. Reviewer: Michael Scharf Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC EMAIL if you reply to or forward this review. This informational document surveys network and transport protocol issues that affect quality of experience for streaming applications, in particular video. The overview covers many topics across different technologies. Readers may only be familiar with a subset of these topics and could therefore learn quite a bit from this kind of tutorial. Nonetheless, it remains somewhat unclear what the actual objective of some of the text is. For some topics, quite a bit of technical background is provided, but the discussion is not really comprehensive. In many sections, the document neither derives technical challenges, nor system/protocol requirements, nor practical usage guidance. It is just a kind of tutorial. Quite a bit of text also presents ongoing IETF work, and an RFC with this scope may thus get outdated soon. Section 6.2 deals with topics owned by TCPM. In similar past documents, I have asked for a TCPM presentation prior to an IETF last call in order to ensure that owners of running code are in the loop. I believe this strategy has worked well in the past. Having said this, as TSV-ART reviewer I don't strongly disagree with a publication. All these issues may just be OK for an informational RFC. Some more specific comments: Section 3.2.1. Recognizing Changes from an Expected Baseline This section apparently assumes relatively static path properties, e.g., fixed network connectivity. It would be more useful to analyze the impact of Wifi and 4G/5G networks in one place. Some of this follows later in sections 3.2.1 and Yet, the split between these three sections is unclear. Having a discussion about today's Internet path characteristics and the dynamics at one place could be more useful. The text could also better distinguish between what matters to endpoints and considerations relevant only for middleboxes (such as passive monitors). Section 3.3 Path Requirements The statement "to find the bandwidth requirements for a router on the delivery path" may assume that the bottleneck on the path will be routers. Yet, on a path the bottlenecks could also be a link layer device (e.g., an Ethernet Switch, a Wifi access point, etc.). RFC 6077 (specifically Section 3.1.3) also explains that issue. A better wording may be "to find the bandwidth requirements for a delivery path". Section 3.6. Unpredictable Usage Profiles / Section 3.7. Extremely Unpredictable Usage Profiles I am not fully convinced by the distinction between "unpredictable" and "extremely unpredictable". To me, these two sections could be merged and maybe also be shortened. More specifically, Section 3.7 lists a lot of statistics from the past. What is IMHO a bit missing in Section 3.7 are actual operational considerations. For instance, are there any lessons learnt for the future? Note that Section 3.6 has a reasonable conclusion at the end. Section 4. Latency Considerations and Section 4.1. Ultra Low-Latency I am surprised by the definition "ultra low-latency (less than 1 second)", as well as some of the other numbers. For other real-time communication use cases, "ultra low-latency" would probably imply a latency requirement of the order of one millisecond. For instance, isochronous traffic for motion control in industrial networks may require a latency of 1 ms, and such "ultra-low latency" requirements are discussed elsewhere, e.g., in the DetNet WG. The terminology in this section should be better explained to readers dealing with networked systems with much harder latency requirements. And a reference should be added for these definitions in the context of video streaming. Section 5.5.2 Head-of-Line Blocking If Head-of-Line Blocking is indeed a relevant operational problem, it would be useful to add a corresponding reference (e.g., with measurements). Section 5.5.3. Wide and Rapid Variation in Path Capacity The statement "As many end devices have moved to wireless connectivity for the final hop (Wi-Fi, 5G, or LTE), new problems in bandwidth detction have emerged from radio interference and signal strength effects." could be moved to earlier parts of the document. Quite a bit of new computers apparently only have Wifi connectivity and no Ethernet port, i.e., Wifi may just be their default. Also, wireless may not only be used on the last hop, for instance in meshed setups. This may make the problem even harder. Section 6. Evolution of Transport Protocols and Transport Protocol Behaviors I really wonder whether UDP vs. TCP vs. QUIC is actually the relevant distinction. What may actually matter are the transport services provided by the protocol stack (e.g., RFC 8095). I fully agree to a related comment in the INTDIR review. Section 6.1. UDP and Its Behavior UDP is also used for encrypted tunnels (OpenVPN, Wireguard, etc.). Does encrypted tunneling really have no operational impact on streaming apps other than circuit breakers? (I am thinking about 4K streaming over OpenVPN and the like.) Section 6.2. TCP and Its Behavior This text should IMHO be presented and be discussed in TCPM. Personally, I am not convinced that this document is a good place for discussing the long history of TCP congestion control. If the objective of the document is to provide a tutorial, IMHO it would be more useful to briefly explain the state-of-the-art in year 2022. Some further specific comments on TCP congestion control: It is surprising that RFC 5681 is not referenced.793bis has normative statements regarding congestion control, and most stacks are compatible to what is written in 793bis. Several operating systems use CUBIC by default and support standard Reno. Another general good reference for TCP standards is RFC 7414.Does ECN, DCTCP, etc. really not matter at all, for instance, if a data center hosts video playout servers? Section 6.3. QUIC and Its Behavior As already noted, the discussion about head-of-line-blocking would really benefit from backing by a reference. Section 7. Streaming Encrypted Media As far as I know, streaming users sometimes use encrypted tunnels such as OpenVPN or WireGuard (or IPsec) to access video content. I may miss something, but it is unclear to me how that fits into the categories presented in Section

3.2.1.  <ins> There are many reasons why path characteristics might change in normal operation, for example: </ins> If the path topology changes.  For example, routing changes, which can happen in normal operation, may result in traffic being


If cross traffic that also traverses part or all of the same path topology increases or decreases, especially if this new cross <del> traffic is "inelastic," and does not, itself, respond to indications of path congestion. To recognize that a path carrying streaming media is not behaving the way it normally does, having an expected baseline that describes the way it normally does is fundamental.  Analytics that aid in that recognition can be more or less sophisticated and can be as simple as noticing that the apparent round trip times for media traffic carried over TCP transport on some paths are suddenly and significantly longer than usual.  Passive monitors can detect changes in the elapsed time between the acknowledgements for specific TCP segments from a TCP receiver since TCP octet sequence numbers and acknowledgements for those sequence numbers are carried in the clear, even if the TCP payload itself is encrypted.  See reliable-behavior for more information. As transport protocols evolve to encrypt their transport header fields, one side effect of increasing encryption is the kind of passive monitoring, or even "performance enhancement" (RFC3135) that was possible with the older transport protocols (UDP, described in unreliable-behavior and TCP, described in reliable-behavior) is no longer possible with newer transport protocols such as QUIC (described in quic-behavior).  The IETF has specified a "latency spin bit" mechanism in Section 17.4 of RFC9000 to allow passive latency monitoring from observation points on the network path throughout the duration of a connection, but currently chartered work in the IETF is focusing on endpoint monitoring and reporting, rather than on passive monitoring. One example is the "qlog" mechanism I-D.ietf-quic-qlog-main-schema, a protocol-agnostic mechanism used to provide better visibility for encrypted protocols such as QUIC (I-D.ietf-quic-qlog-quic-events) and for HTTP/3 (I-D.ietf-quic-qlog-h3-events). </del>  3.3.

If cross traffic that also traverses part or all of the same path topology increases or decreases, especially if this new cross  <ins> traffic is "inelastic," and does not respond to indications of path congestion. Wireless links (Wi-Fi, 5G, LTE, etc.) often see rapid changes to capacity from changes in radio interference and signal strength as endpoints move. To recognize that a path carrying streaming media has experienced a change, maintaining a baseline that captures its prior properties is fundamental.  Analytics that aid in that recognition can be more or less sophisticated and can usefully operate on several different time scales, from milliseconds to hours or days. Useful properties to monitor for changes can include: round-trip times loss rate (and explicit congestion notification (ECN) (RFC3168 when in use) out of order packet rate packet and byte receive rate application level goodput properties of other connections carrying competing traffic, in addition to the connections carrying the streaming media externally provided measurements, for example from network cards or metrics collected by the operating system </ins> 3.3.


5.5.3. <del> As many end devices have moved to wireless connectivity for the final hop (Wi-Fi, 5G, or LTE), new problems in bandwidth detection have emerged from radio interference and signal strength effects. </del>  <del> Each of these technologies can experience sudden changes in capacity as the end user device moves from place to place and encounters new sources of interference.  Microwave ovens, for example, can cause a throughput degradation of more than a factor of 2 while active Micro. 5G and LTE likewise can easily see rate variation by a factor of 2 or more over a span of seconds as users move around. </del>  These swings in actual transport capacity can result in user <del> experience issues that can be exacerbated by insufficiently responsive ABR algorithms. </del>  5.6.

5.5.3.  <ins> As many end devices have moved to wireless connections for the final hop (such as Wi-Fi, 5G, LTE, etc.), new problems in bandwidth detection have emerged. </ins>  <ins> In most real-world operating environments, wireless links can often experience sudden changes in capacity as the end user device moves from place to place or encounters new sources of interference. Microwave ovens, for example, can cause a throughput degradation in Wi-Fi of more than a factor of 2 while active Micro.  5G and LTE likewise can easily see rate variation by a factor of 2 or more over a span of seconds as users move around. </ins> These swings in actual transport capacity can result in user  <ins> experience issues when interacting with ABR algorithms that aren't tuned to handle the capacity variation gracefully. </ins> 5.6.


Operational Considerations for Streaming Media <del> draft-ietf-mops-streaming-opcons-00 </del>  Abstract

This is based on the post-IETF 107 MOPS meeting where we talked about this. I chased some more references.
We should try to improve this reference - it's a long page, additions are at the top, so we have to either scroll for a long time or search for the date to get the relevant part of the page. Maybe reach out to ATT to get fragment tags that work?

Operational Considerations for Streaming Media  <ins> draft-ietf-mops-streaming-opcons-01 </ins> Abstract