applications have to always consider HTTP Datagrams to be unreliable, even if they were initially sent in a capsule.  5. In order to facilitate extensibility of contexts, the

Credit to NAME for the proposal on the .
reading this in isolation, I'm a but unsure what the "effectiveness of DPLPMTUD" is supposed to mean. Is there something implied here about how the intermediary will pack DATAGRAM frames into QUIC packets? For instance, is it being suggested that to make this work, we really need the intermediary not to pack out the size with other things?
The intent was to enable "end-to-end application DPLPMTUD" though I couldn't come up with a clear and concise name for it - in other words, there will be an application protocol that is running over HTTP Datagrams, and this is about the endpoints of that application performing DPLPMTUD at their layer. Does that make sense? If so, do you have thoughts on how best to word that?
The implication here is that the intermediary (1) knows a lower bound on the QUIC MTU and (2) never adds frames to a packet that is already larger than this bound (if it allows such packets at all). I believe this is always true for QUIC, although I'm not sure it's stated explicitly anywhere.
NAME can you clarify what you meant by "a lower bound on the QUIC MTU" ? The MTU can change dynamically due to changes outside of QUIC's control so the only real lower bound is 1200 - and we need to be able to send packets larger than that.
I mean that, at any given time, a QUIC endpoint has a lower bound L on the estimated path MTU. This lower bound is sometimes wrong, but it's never zero. If an H3 DATAGRAM produces a QUIC packet that is larger than L, we just need to be sure that QUIC won't add other frames to this packet. (I don't know if QUIC will send this packet or just drop the datagram, but either way, DPLPMTUD on the inner connection will work fine.)
The in the PR sounds fine. I'm still confused by the justification though, even after these comments. For hop2, which is QUIC, it must have a minimum PMTU of 1200. The maximum PMTU could be bigger. The maximum QUIC packet size that can be sent should be the min(max MTU, maxudppayload_size advertised by peer). After the intermediary gets the H3 DATAGRAM payload, it will need to reencode it. We're suggesting into a QUIC DATAGRAM frame, with H3 DATAGRAM headers. This reencoding could have different overhead sizes (hop2 might have larger QUIC packet overheads, or H3 DATAGRAM overheads. Is the suggestion that the intermediary is using a PMTU size P1, and if it sees a H3 DATAGRAM that would produce a packet larger that P1, it should try to send it as a sort of probe?
That's fine, so long as the overhead of each hop rarely changes. It could try to send it, or it could drop it. (It's not much of a "probe", since the intermediary won't necessarily know if it was dropped.) Either way, the end-to-end DPLPMTUD will converge to some working value, which is all that matters.
So, can we remove this statement wrt to DPLPMTUD? I don't know what I'm supposed to apply it to.
I'm OK removing it, but in general I think it would be helpful to have the draft explain why that SHOULD NOT is there. And the motivation is to allow e2e DPLPMTUD. Because if the intermediary reencodes as capsules some of the time, the application-endpoints won't be able to get a sense for what packet sizes get through or not.
What you just said is much clearer than the proposed text. Longer term, I think what we'll probably end up with is a whole section that collects intermediary concerns. But until we arrive at that point, a better way to present the matter at hand could be something like the following, which is intended to follow on the theme of discussion from the paragraphs in that section. "Intermediaries that receive HTTP Datagrams in QUIC DATAGRAM frames need to decide how to forward them. If the onward connection supports QUIC DATAGRAM frames, intermediaries SHOULD attempt to forward HTTP Datagrams in a QUIC frame. If the HTTP Datagram is too large to fit in a QUIC frame, the intermediary SHOULD drop it. This preserves the end-to-end unreliability characteristic that methods such as DPLPMTUD depend on. An intermediary that forwards HTTP Datagrams in DATAGRAM capsules allows HTTP Datagrams to be arbitrarily large. This can misrepresent the true path properties, defeating methods such a DPLPMTUD."
I like that, NAME I've updated the text based on your comment, let me know what you think.
So this is the first step to drop them. However, I am fairly convinced that we also need the signal to the Intermediaries when they need to send a HTTP datagram over the reliable stream instead of over the QUIC Datagram. Otherwise we will have MTU black holes for the minimal IPv6 packet size.
To expand on my previous comment. At least in CONNECT-IP and I think also for CONNECT-UDP. We do need a solution to ensure that we can tunnel and not blackhole inner payloads that correspond to the IPv6 minimal packet size. So for Connect-IP with all the overhead we need to send HTTP datagram containing a payload for 1280 IPv6 packets, otherwise we are not IPv6 compliant. For CONNECT-UDP this is not as clearly required as in the case of IPv6, however I think it would be a tradgic if this solution couldn't handle the required smallest allowed size of QUIC initial packets. That is why I think we need to have a solution where the endpoint can be certain that even if less efficient that the packets make it through if they are below these minimal sizes.
This sounds like a form of fragmentation to me. I'd rather fail hard than be fooled by unknown intermediaries that the path supports the size required. Instead of signalling the explicit MTUs as suggested on the mialing list, what about a capsule type equivalent to PTB that could be returned to the client to indicate something was too large and dropped. Then the client can make the active decision whether to reduce size (if possible) or retry by putting the HTTP Datagram in a DATAGRAM capsule itself.
NAME that I think works for me. In fact I think that is a better solution then the boundary value which requires state keeping and allows the HTTP endpoint to decided what to do. Also it can provide an endpoint with the actual current MTU. It is only executed when you can't forward the HTTP Datagram so it appear simpler than my original idea which would have needed cross layer interaction on changes in lower layers independent of when it occurs. But, yes this is fragmentation and reassembly. Just the matter that we have the facilities available in the form of QUIC streams or TCP.
I think a PTB reply is likely unnecessary complexity. Anything on CONNECT-IP has to exit the tunnel eventually, and it still needs PMTUD on that path. ICMP connectivity is not reliable, so PLPMTUD is mandatory regardless, and will automatically handle any bottlenecks in the tunnel without the need for PTB.
just to clarify a little, I didn't mean a literal PTB. I meant to address Magnus' point that an end-to-end QUIC connection could fail to even get an client Initial through because the intermediary willingfully dropped it. A client might benefit from an immediate signal from the intermediary in such a case. I'm not sworn to this idea though.
Note that in CONNECT-UDP, the Initial should almost always travel in a CAPSULE, so it can be sent immediately ("false start") without worrying about reordering or packet loss. That has ... interesting implications for MTU.
interesting, I hadn't thought of doing that. Right now my implementation buffers received datagrams, so whether I receive the DATAGRAM frame before a corresponding HEADERS is negligible. Agree it might have interesting implications.
NAME I don't think it is sufficient for us to simply declare that it is someone else problem with the MTU. From an Internet Architecture perspective the MASQUE tunnel is the equivalent of a link layer. There are certain requirements on link layers that carry IP packets, especially IPv6 packets. This requires support of the 1280 MTU, so we need a solution for that case. Secondly, I am a bit intrigued by your statement that in the case of Connect-UDP the first UDP packets would travel as capsule. I don't think the HTTP Datagram mandates that in any way. To my understanding, which appears to match NAME ones. Is that one can send a Connect-UDP request, followed by a HTTP Datagram context registration capsules for the needed Context IDs and then send HTTP Datagrams. There is nothing in the protocol that prevents this. Our Connect-UDP implementation will buffer these early HTTP datagrams and provide them to the Masque Server when it has processed the registration to create the IP/UDP packets based on the payload.
Hi folks, as per let's have this discussion somewhere that's not a GtiHub PR. I'd suggest . Since I haven't heard any objections on the text in this PR, I'm going to merge it. Let's discuss on the list whether we think more should be done about MTU or not.
This has been sent to the MASQUE WG mailing list in hopes to get some discussion there. However, I want an issue that tracks this: In the work of writing up our Connect-IP proposal (URL) we looked into how to deal with MTU issues effectively. Our conclusion was that this is going to be a general problem for any user of HTTP Datagrams. Thus, we like to propose that MTU handling is done within HTTP datagram. This email will start explaining what we see as requirements for a MTU signaling solution for HTTP datagram, then propose a potential solution. Lets start with a figure that provides us with a framework to discuss the requirements: I think what makes this a bit more complex is the fact that we need to consider HTTP intermediaries, such as a front end load balancer that terminates a first QUIC and HTTP/3 connection between the client and that intermediary. From that intermediary another HTTP connection is used towards the HTTP server that consumes and produces the HTTP datagrams, and in the case of CONNECT-UDP and CONNECT-IP it also have a third path towards the target to consider. This figure includes two clients to remind us to consider that the HTTP intermediary may actually aggregate the HTTP request and response and HTTP datagram over one HTTP/2 or HTTP/3 connection over Path . In the case of MTU this complicates things more as the proxy cant assume that all HTTP requests have the same MTU for its datagrams on a HTTP/3 connection. And the Intermediary will be the entity that have direct knowledge of the client facing as well as the next hop MTU over the HTTP connections that may all differ in MTU. We also have to consider the fact that the underlying transport connection may at any time be subject to a IP MTU change due to route change for the path between the nodes. In addition if one have enabled PMTUD in TCP or QUIC a larger MTU on the individual path could be made available and in some case desirable to use. Thus, we need to consider dynamic changes during the HTTP connections life time and each HTTP request response pairs usage of HTTP datagram. So when using HTTP/3 datagram there are a strict MTU limit on the individual datagrams for it to be possible to be sent as QUIC datagrams, and not being forced to be encapsulated as CAPSULES over the reliable stream. This is clearly a possibility but results in that the datagrams are sent reliable and in order for each HTTP request, i.e. Connect-UDP or CONNECT-IP request. Also in case some end-to-end payloads fit in HTTP datagrams and others don’t there is potential for reordering among the payloads. Thus, to avoid this the client and the proxy needs to determine what the lowest currently supported HTTP datagram size on the path. For each QUIC connection the end point will know what the initial MTU value is for this path when the HTTP/3 connection has been successful completed. However, that knowledge will not be available if one attempt to construct and send the HTTP request prior to connection establishment has concluded. So the requirements we see for an MTU handling solution for HTTP Datagrams are the following. 1) Hop-by-hop signaling across the HTTP entities of the lowest MTU of any sub-path 2) Needs to be associated to a particular HTTP request or end-to-end path to support aggregation by HTTP intermediaries 3) Endpoints needs to be able to initiate update of the MTU value upon detection of any changes during HTTP Datagram streams lifetime. 4) HTTP Intermediaries needs to be able to initiate updates of the MTU value upon detecting MTU changes from the individual HTTP connections. Solution proposal A new HTTP Datagram Capsule is defined for MTU value exchange. This one is intended for the HTTP intermediary that needs to interpret, update or initiate sending of it. Thus, it needs to be a fixed registered type so it can be easily processed. It can also be exchanged in parallel to the RegisterDatagram* capsules as at that point the underlying HTTP connection is established and initial HTTP Datagram values will be known. A capsule will also travel all the way to the end. And an intermediary can initiate one in each direction for request paths. The only downside I see of this is that one is required per open stream when MTU changes occurs. Maybe someone have an idea of how to handle signaling when aggregating multiple endpoints streams onto one HTTP/3 connection. To make it more efficient, rather than sending one MTU capsule per stream, an MTU capsule could list all streams it is applicable to. That way the number of MTU capsules would be no more than the number of end-to-end paths actually used.
Hi NAME thanks for proposing this work item. From reading your problem statement and proposal, this will require non-trivial amounts of complexity. Resolving that will take time. I don't see a reason to delay the HTTP Datagrams draft because of this, so I'd suggest building this as an extension to HTTP Datagrams. I think this would even be a great way to test out our new extensibility mechanism! Can you write this up as a separate draft please?
Yes, it is non-trivial. However, I think we need to settle if we have a day one need for this mechanism to ensure that CONNECT-UDP actually can work properly and handle QUIC in QUIC when the outer tunnel uses minimal QUIC packets. Similarly we have a need for CONNECT-IP to handle IPv6 minimal packet size. So I think we need to discuss if this needs to be solved. But, yes I am willing to write this up in spec form, but I was more thinking of a PR to the HTTP-DATAGRAM draft.
I don't see a day one need here that isn't addressed by . Given the current text, CONNECT-UDP (and -IP) endpoints can detect datagram blackholing and switch to capsules.
I don't understand the following statement "CONNECT-UDP (and -IP) endpoints can detect datagram blackholing and switch to capsules." I don't believe that is true in scenarios with HTTP Intermediaries as the MASQUE endpoint in those case lacks visibility of the dropping of the HTTP Datagram, unless additional signals are added. But, I would also prefer that we discuss this on the mailing list. I just think closing the issue was premature.
You don't need an explicit signal to know that a packet was dropped, you can infer that through lack of acknowledgements. Since there aren't acknowledgements at the datagram layer itself, you'd need to partner with the transport protocol running over CONNECT-UDP or CONNECT-IP to get that signal. That isn't trivial, but if we transparently solve this at the datagram layer (let's say we add a "datagram too big" capsule and then have the datagram layer use it to switch to reliable capsules for example) then you'd end up with terrible performance because in most scenarios you'd be much better off with the higher level transport protocol using a smaller MSS that fits in datagrams. So all this to say: this isn't an easy problem to solve, and having an explicit signal isn't a silver bullet that solves it easily. Since we need to involve the higher layers, then we have many options to pick from, and not all of them require an explicit signal.
Agree that for sufficiently large MTU you want the end-to-end PMTUD to work and dropping will be necessary. However, we are going to have requirements on minimal packet sizes, that is where we end up in needing a signal. In addition if the tunnel HTTP Datagram ingress knows the MTU, then for the MASQUE use cases it can send back the appropriate signal towards an remote IP point or through the API to the application using MASQUE. If an HTTP intermediary simply drop packets that are to large and send no signal back. Then the HTTP datagram ingress has no knowledge and no type of signal intended to speed up PMTUD is also sent. Which, makes results us from potentially breaking the IPv6 specification requirements in two ways when using it for CONNECT-IP. First we may not support the required datagram size of 1280 bytes. Secondly, we are not supporting the IPv6 PMTUD model of actually sending ICMPv6 PTBs. Yes, this may not work as well as it should, but it is still required functionality.
This sounds like a good use case for . It's a great example of a context ID extensions that can benefit multiple methods. As long as draft-ietf-masque-h3-datagram is extensible enough to allow this kind of extension, I don't think we need to solve this in draft-ietf-masque-h3-datagram.
Summarizing the we had on this topic, both WebTransport and CONNECT-UDP are working well in production without an MTU solution at the HTTP Datagrams layer. There is also no proposal for an MTU solution that works for all possible use cases of HTTP Datagrams. The only unsolved problem here is how to reconcile a low HTTP Datagram MTU with the IPv6 minimum link MTU. Since that's specific to CONNECT-IP, I've filed a specific issue for that there: URL Based on this, I'm going to close this issue with no action. If you disagree, please reopen/comment. Hi, In the work of writing up our Connect-IP proposal (URL) we looked into how to deal with MTU issues effectively. Our conclusion was that this is going to be a general problem for any user of HTTP Datagrams. Thus, we like to propose that MTU handling is done within HTTP datagram. This email will start explaining what we see as requirements for a MTU signaling solution for HTTP datagram, then propose a potential solution. Lets start with a figure that provides us with a framework to discuss the requirements: +--------+ PathA +--------+ +-------+ +--------+ +--------+ +--------+ PathB +--------+ +--------+ +-------+ +--------+ I think what makes this a bit more complex is the fact that we need to consider HTTP intermediaries, such as a front end load balancer that terminates a first QUIC and HTTP/3 connection between the client and that intermediary. From that intermediary another HTTP connection is used towards the HTTP server that consumes and produces the HTTP datagrams, and in the case of CONNECT-UDP and CONNECT-IP it also have a third path towards the target to consider. This figure includes two clients to remind us to consider that the HTTP intermediary may actually aggregate the HTTP request and response and HTTP datagram over one HTTP/2 or HTTP/3 connection over Path . In the case of MTU this complicates things more as the proxy cant assume that all HTTP requests have the same MTU for its datagrams on a HTTP/3 connection. And the Intermediary will be the entity that have direct knowledge of the client facing as well as the next hop MTU over the HTTP connections that may all differ in MTU. We also have to consider the fact that the underlying transport connection may at any time be subject to a IP MTU change due to route change for the path between the nodes. In addition if one have enabled PMTUD in TCP or QUIC a larger MTU on the individual path could be made available and in some case desirable to use. Thus, we need to consider dynamic changes during the HTTP connections life time and each HTTP request response pairs usage of HTTP datagram. So when using HTTP/3 datagram there are a strict MTU limit on the individual datagrams for it to be possible to be sent as QUIC datagrams, and not being forced to be encapsulated as CAPSULES over the reliable stream. This is clearly a possibility but results in that the datagrams are sent reliable and in order for each HTTP request, i.e. Connect-UDP or CONNECT-IP request. Also in case some end-to-end payloads fit in HTTP datagrams and others don't there is potential for reordering among the payloads. Thus, to avoid this the client and the proxy needs to determine what the lowest currently supported HTTP datagram size on the path. For each QUIC connection the end point will know what the initial MTU value is for this path when the HTTP/3 connection has been successful completed. However, that knowledge will not be available if one attempt to construct and send the HTTP request prior to connection establishment has concluded. So the requirements we see for an MTU handling solution for HTTP Datagrams are the following. Hop-by-hop signaling across the HTTP entities of the lowest MTU of any sub-path Needs to be associated to a particular HTTP request or end-to-end path to support aggregation by HTTP intermediaries Endpoints needs to be able to initiate update of the MTU value upon detection of any changes during HTTP Datagram streams lifetime. HTTP Intermediaries needs to be able to initiate updates of the MTU value upon detecting MTU changes from the individual HTTP connections. Solution proposal A new HTTP Datagram Capsule is defined for MTU value exchange. This one is intended for the HTTP intermediary that needs to interpret, update or initiate sending of it. Thus, it needs to be a fixed registered type so it can be easily processed. It can also be exchanged in parallel to the RegisterDatagram* capsules as at that point the underlying HTTP connection is established and initial HTTP Datagram values will be known. A capsule will also travel all the way to the end. And an intermediary can initiate one in each direction for request paths. The only downside I see of this is that one is required per open stream when MTU changes occurs. Maybe someone have an idea of how to handle signaling when aggregating multiple endpoints streams onto one HTTP/3 connection. To make it more efficient, rather than sending one MTU capsule per stream, an MTU capsule could list all streams it is applicable to. That way the number of MTU capsules would be no more than the number of end-to-end paths actually used. Cheers Magnus Westerlund
I agree that MTU discovery is valuable, and I think we should try to provide a workable solution. However, I think the solution you've sketched sounds very complicated, and I have some concerns about whether it would be implemented correctly. Here's an alternative proposal: An HTTP intermediary routes each datagram from an "incoming" link to an "outgoing" link. When the outgoing link is DATAGRAM-capable, intermediaries SHOULD NOT convert DATAGRAMs to CAPSULEs, and SHOULD NOT fragment (or permit fragmentation of) the corresponding QUIC packets. DATAGRAMs that are too large for any segment's MTU will therefore be dropped silently, and will not reach their destination. This is sufficient to enable end-to-end PMTUD over MASQUE. I think this arrangement is likely preferable: it avoids adding complexity to intermediaries, and places responsibility for PMTUD at the endpoints, who have the clearest incentive to make it work well. Endpoints who need to send packets larger than the MTU, or who need to send large packets before PMTUD converges, can use CAPSULEs at their discretion. >

applications have to always consider HTTP Datagrams to be unreliable, even if they were initially sent in a capsule. <ins> If an intermediary receives an HTTP Datagram in a QUIC DATAGRAM frame and is forwarding it on a connection that supports QUIC DATAGRAM frames, the intermediary SHOULD NOT convert that HTTP Datagram to a DATAGRAM capsule.  If the HTTP Datagram is too large to fit in a DATAGRAM frame (for example because the path MTU of that QUIC connection is too low or if the maximum UDP payload size advertised on that connection is too low), the intermediary SHOULD drop the HTTP Datagram instead of converting it to a DATAGRAM capsule.  This preserves the end-to-end unreliability characteristic that methods such as Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) depend on RFC8899.  An intermediary that converts QUIC DATAGRAM frames to DATAGRAM capsules allows HTTP Datagrams to be arbitrarily large without suffering any loss; this can misrepresent the true path properties, defeating methods such a DPLPMTUD. </ins> 5. In order to facilitate extensibility of contexts, the


the connection with error H3_SETTINGS_ERROR.  In all cases, the maximum permitted value of the H3_DATAGRAM SETTINGS parameter is 1.  7. Prioritization of HTTP/3 datagrams is not defined in this document.

This will help interop efforts before publication.
I think we can address many of the complexity concerns with the H3 Datagrams draft by adjusting the architecture to focus more on WebTransport. Here's a sketch of the required changes: In WebTransport, Datagrams are associated with Streams, not Sessions. This requires simplifying H3 Datagram's "Quarter Stream ID" to just "Stream ID". Get rid of "Datagram Contexts". The context for a Datagram is its associated Stream. Run the MASQUE services over WebTransport. The URL must distinguish the service in use (e.g. UDP vs. IP proxying). The value is . UDP and IP proxy services only use Datagrams and Bidirectional Streams. The stream contains messages in a simple TLV format ("capsules"). There are three basic capsule types: No payload Contains an integer success/error code Arbitrary payload Equivalent to an associated Datagram, but reliable and in-order "False Start" is supported by sending a capsule (or a Datagram) immediately after . Non-default datagram formats can be enabled later by defining an capsule type, which would elicit an error from basic implementations. Intermediaries that relay between H2 and H3 need to understand WebTransport, but do not need to know anything about MASQUE or the Stream contents. More aggressive variations: Use the "CONNECT stream" for the default format. Avoids the need for , but may not be compatible with the expected WebTransport APIs and use patterns. Move target host and port specification from the URL to an capsule. Perhaps clearer, but would deviate from the current CONNECT-IP and CONNECT-UDP consensus plans. Reuse HTTP/3 frames instead of capsules (/ -> , -> ). Simpler and more flexible, but possibly confusing.
This sounds more complicated than the current design, and much more complicated than the . In what way does this simplify things?
Using that PR as a baseline, this change would eliminate most of the text in the H3 Datagrams document. All mention of contexts, Sec-Use-Datagram-Contexts, etc. (Sections 2.1, 2.2, 6, and 9.2) would be deleted. All discussion of Capsules (Sections 4 and 9.3) would be extracted to a separate document, as Capsules are now a framing layer used only by MASQUE, inside WebTransport. All discussion of intermediary processing (Section 4.3, much of Section 4.4) would be deleted. We could also consider eliminating the H3_DATAGRAM setting (Sections 5 and 9.1), as there would no longer be any active use case for it independent of WebTransport. It would also be dramatically simpler to implement for any parties that already carry a WebTransport implementation.
Remember that the complexity that we care about is the aggregate complexity of what needs to be implemented, not the complexity of this one draft in isolation. This proposal removes some complexity from this draft but introduces a large dependency; this increases overall complexity.
I disagree. The total amount of specification text is greatly reduced. The total amount of code in a typical participating intermediary, client, or server is reduced in each case. The complexity of reasoning about the system is greatly reduced, as the behavior of each component is simpler and can be analyzed independently (e.g. intermediaries don't interact with capsules and don't need to know anything about MASQUE). Perhaps a relevant question here is: do you believe a typical MASQUE implementation will live in a codebase that also carries a WebTransport implementation? I do, so we can simplify the MASQUE design by using it. I also think there are positive ecosystem effects to consider. If we can agree on a single thing that intermediaries have to do ("implement WebTransport relaying"), we are likely to get to much broader compatibility than if intermediaries have to take distinct actions for compatibility with WebTransport and MASQUE.
On first inspection of this proposal, I do not like the idea of coupling MASQUE to WebTransport.
I think this is intriguing and should be explored further. I've often found it confusing that both WebTransport and masque are defining similar concepts like the CONNECT stream and how to associate datagrams with it. Deferring those concepts to WebTransport means there's only one way to do this. For example, I think connect-udp implemented with this proposal would result in almost identical bits being sent on the wire, so it's hard to argue that it's more complex. It also establishes clear boundaries about where the contexts, etc, belong -- in the protocols that are layered on top. Intermediaries that are not participating in those protocols just have to know how to relay WebTransport (translating between HTTP versions) as Ben says. And intermediaries that are participating aren't HTTP intermediaries at all, they are WebTransport servers. In a way, datagrams never really belonged in HTTP itself, as they have no semantic meaning to HTTP, any more than server initiated bidirectional streams do. In the early days it wasn't clear that WebTransport would be over HTTP, so there was less similarity. But now that it is, having WebTransport be the single way for HTTP to access QUIC transport features beyond request/response is appealing. A couple notes on the proposal itself: WebTransport -02 uses HTTP Datagram, so the "Quarter Stream ID" is implicit. It doesn't preclude you from attaching datagrams to WebTransport client initiated bidi-streams that are not HTTP request streams, but that's most likely an oversight. I believe the intent is for datagrams to only associated with the CONNECT stream (Session). Why can they not also send datagrams?
That's not the case today. Capsules and how to send datagrams are defined in draft-ietf-masque-h3-datagram, and both WebTransport and CONNECT-UDP have a dependency on it. There is only one way to do this and there's no concept that is defined twice. Implementing a WebTransport-supporting intermediary is much more complex than implementing a datagram-supporting intermediary. You now need to implement all of the stream logic form WebTransport which CONNECT-UDP doesn't need. In the Privacy Proxy space there's interest in building CONNECT-UDP intermediaries that have no interest in WebTransport.
Yes. I'm proposing a modification to HTTP Datagram, replacing "Quarter Stream ID" with "Stream ID". Yes, they can. I meant that they don't use unidirectional streams. Sorry if that was confusingly worded.
The extended CONNECT setup and how to translate between protocol versions is defined twice, right? Maybe the latter would be reduced to once if the H2 version of WebTransport adopts Capsules. Can you clarify "intermediary" here? Are they looking to build an endpoint that terminates the CONNECT-UDP request and forwards raw UDP datagrams? If this is all you do, you do not need to be a full WebTransport proxy, and the code is basically the same. If they want to have a chain of proxies, then the non-terminating "intermediaries" would need to understand how to translate datagrams via WebTransport across HTTP/3 datagrams capable and non-HTTP/3 capable transports. If they have no interest beyond datagrams, you can make a minimal WebTransport proxy that sets the stream limits to 0 and only handles datagrams, and again -- same code. Where'd you run into trouble is that these layered protocols may need a control channel, and the Capsule protocol has been created to allow them to use the CONNECT stream for this. The WebTransporty design would be a protocol specific control stream. There you'd need the WebTransport machinery for streams, which is pretty simple over H3 but heavierweight over H2.
You're right, I was assuming a world where WebTransport-over-h2 uses capsules. I was using the definition from , which would be the "non-terminating intermediary" from your last comment. So you're saying we put MASQUE over WebTransport and then have MASQUE only implement a part of WebTransport. What's the value in pulling in WebTransport then? WebTransport and CONNECT-IP both need a control stream for operation of their base protocol, and CONNECT-UDP will most likely need one for extensibility. If you're suggesting we scrap capsules and have them all build their own control stream, that's not going to improve complexity.
I can believe that there may be a need for single-purpose CONNECT-UDP intermediaries. However, if we believe these intermediaries will normally be implemented using a general-purpose H3 server framework (e.g. Envoy), then the codebase will likely already contain a WebTransport forwarder, and we aren't helping anyone by not using it. I also don't see a lot of complexity in H3->H3 WebTransport forwarding, especially if we fully remove Capsules from WebTransport-H3. H3H2 forwarding is complicated, but basically similar in all the different proposals. The important thing (it seems we agree) is to avoid specifying it twice. This works fine within the proposal here. The default stream type for CONNECT-IP (created by ) would allow some more capsule types for all the address management stuff. If you don't like , you could possibly send all those capsules on the CONNECT stream (in H3), and use its associated Datagrams for packets. The other WebTransport streams would be used for extensibility, i.e. non-default format types, As NAME noted, this would allow a baseline-only MASQUE service to implement a subset of WebTransport.
You're saying you get simplicity by removing capsules, and then you add TLVs which are basically capsules. So it's unclear to me what complexity is saved by removing capsules, which probably means I'm not understanding the proposal here. NAME could I ask to show me the wire interactions (something like what we have in the ) for these two scenarios? "vanilla" CONNECT-UDP without any extensions CONNECT-UDP with an extension such as your PMTUD extension
No, I'm saying you get overall simplicity by removing Contexts, which duplicate the functionality of WebTransport Streams. Capsules are relocated from H3 Datagram to "MASQUE", simplifying H3 Datagrams but not MASQUE. Both and this proposal start with 3 capsule types and expect more to be defined. Here are some interaction diagrams. These show interaction on top of the WebTransport layer. That could be considered cheating, but I'm assuming that a WebTransport implementation is available. Vanilla CONNECT-UDP CONNECT-UDP with the PING extension
I don't understand how this proposal allows a simple way to run multiple tunnels over a single QUIC connection. Can you explain how it would be supported to, for example, open multiple independent connections to e.g. conn-URL for N up to 10? How can errors the server encounters opening tunnels be reflected back to the client (e.g. NXDOMAIN, or other such problems)?
NAME In this proposal, each tunnel would be a separate WebTransport "session". WebTransport supports multiplexing many sessions over a single HTTP/3 connection. (I'm not sure if this was always true, but it's true in the latest draft.) Errors could be reflected in the HTTP status code. (This proposal does not alter the URL format used for CONNECT-UDP or CONNECT-IP.)
Thanks for the clarification. I have concerns on how easy it would be to conflate webtransport for application services and for proxying services, that might be able to be solved with design changes, not sure. I would also be concerned about how many resources an HTTP/3 server might need to allocate to allowing sufficient bidirectional streams for WebTransport sessions, and conventional CONNECT streams. In contrast, the current design of HTTP datagrams and CONNECT-UDP mean is more straightforward to add CONNECT(-UDP) to an extant form of proxy server.
What's the memory cost of an idle stream? Is it significant?
My concern is more that, right now I can bound the number of concurrent CONNECT(-UDP) streams easily by managing the concurrent stream limit (in either H2 or H3). In a WebTransport server, I would need to possibily also accomodate the additional bidi streams that can be latched onto web transport sessions. I'm assuming that in this proposal, MASQUE would actually need them. But if I'm standing up a webtransport service, then it isn't clear to me how clients might need to mix different actual usage of the webtransport sessions. That makes capacity planning harder that it is already for this use case. This concern probably reflects more on the WebTransport design more than anything, but illustrates a concern we would place on proxy deployments that don't even have to worry about it today.
Interesting. However, as you hint, a better solution might be to make SETTINGSENABLEWEBTRANSPORT an integer, the maximum number of open WebTransport sessions allowed. That would allow improved control over proxy resource usage.
NAME your second example from URL is incomplete. "CONNECT-UDP with the PING extension" needs the ability to send both UDP payloads and pings, not just pings. I'm interested in understanding how demultiplexing works
NAME It's just Example 1 again, unmodified, so I didn't want to duplicate it. Demultiplexing within a Session is by Stream ID.
I see, thanks for explaining. I think I understand the proposal now. If one accepts your premise that "WebTransport is deployed everywhere, MASQUE arrives after that", then your solution makes sense. I completely reject the premise though, as it doesn't match reality.
This issue has reframed for me the way I think about CONNECT-UDP and CONNECT-IP. CONNECT-UDP is a subset of the WebTransport functionality that piggybacks a control stream on the CONNECT stream, and disallows other kinds of streams. WebTransport could certainly provide required functionality. David may be right that coupling could slow adoption because WebTransport has more moving pieces. Lucas raises a good point that managing resources for those pieces is more complex too. I wonder how we think about what other applications might try to use H3-Datagram rather than WebTransport to leverage datagrams within an HTTP connection, and if we think any of those are good ideas.
This has been supplanted by the proposal in .

the connection with error H3_SETTINGS_ERROR.  In all cases, the maximum permitted value of the H3_DATAGRAM SETTINGS parameter is 1. <ins> 6.1. [[RFC editor: please remove this section before publication.]] Some revisions of this draft specification use a different value for the H3_DATAGRAM Settings Parameter.  This allows new draft revisions to make incompatible changes.  Multiple draft versions MAY be supported by either endpoint in a connection.  Such endpoints MUST send multiple values for H3_DATAGRAM.  Once an endpoint has sent and received SETTINGS, it MUST compute the intersection of the values it has sent and received, and then it MUST select and use the most recent draft version from the intersection set.  This ensures that both endpoints negotiate the same draft version. </ins> 7. Prioritization of HTTP/3 datagrams is not defined in this document.


initiated bidirectional stream MUST be treated as a connection error of type H3_FRAME_UNEXPECTED.  4.1. The REGISTER_DATAGRAM_CONTEXT capsule (type=0x00) allows an endpoint MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. <del> Endpoints MUST NOT send a REGISTER_DATAGRAM_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 endpoint needs information from headers to determine how to react to the capsule.  If an endpoint receives a REGISTER_DATAGRAM_CONTEXT capsule on a stream that hasn't yet received a HEADERS frame, the endpoint MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. </del> Servers MUST NOT send a REGISTER_DATAGRAM_CONTEXT capsule on a stream before they have received at least one REGISTER_DATAGRAM_CONTEXT capsule or one REGISTER_DATAGRAM_NO_CONTEXT capsule from the client MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. <del> 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. </del> 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

This makes the requirement global to clients, servers, and intermediaries.
NAME does the PR address your issue?
merging, please reopen the ticket if you need anything more
The HTTP/3 RFC states The current draft instead recommends closing the stream rather than the connection and with the generic H3GENERALPROTOCOLERROR According to URL H3GENERALPROTOCOLERROR is to be used when a more specific error code isn't available, but here we have clearly a more specific error available. Also, what is the rationale for closing just the stream and not the whole connection? Furthermore, a more general question: right now the above recommendation only exists for REGISTERDATAGRAMNOCONTEXT and REGISTERDATAGRAM_CONTEXT capsule types. Would it be fair to say that no Capsule frame is allowed before headers instead?
Thanks. I think it would be for us to clarify a) strict ordering rules of capsule amongst HTTP message frames. b) strict ordering rules of capsule types. For (a), I'm inclined to state a top-level requirement that CAPSULE frames MUST NOT arrive before the first HEADERS on a request stream. Violation of that is connection error of type H3FRAMEUNEXPECTED. For (b), I'm slightly less sure. We clearly have some ordering requirements. The H3 base spec treats misordering as a critical failure. We treat it here as a stream error. I think we could make things more similar to H3. For instance, I can't think of a good reason right now why we are so loose with handling of datagram capsules; if they arrive on a stream before a register capsule, that smells broken.
Banning all capsules before headers sounds reasonable to me. Strict ordering of capsules is required on the sender, but enforcing that on the receiver isn't always easy so I don't think we can mandate it. I honestly don't care if it's a stream or connection error, either works for me.
Happy to write the PR for this. Right now I'm thinking we cam make (b) a more specific error code too. I think H3FRAMEUNEXPECTED is good enough for capsule types but we could always define a H3CAPSULE UNEXPECTED is people felt strongly.
Do you have an example of where (b) is useful? In other words, what's a sequence of events that leads a receiver to detect a capsule illegal ordering?
The following sequence is legal by (a) but illegal by (b) Client HEADERS Server HEADERS, Server CAPSULE (registerdatagramcontext) So is this sequence Client HEADERS Client CAPSULE (registerdatagramnocontext) Client CAPSULE (registerdatagramnocontext) From what the spec says, I'm less clear on if this sequence is illegal Client HEADERS Client CAPSULE (datagram) Client CAPSULE (registerdatagramno_context) There's a lot of text about DATAGRAM frames and ordering. But when sending Datagram capsules on streams, they can be strictly ordered on sender and receiver. H3 treats such ordering as specific problem because it is avoidable.
That last sequence probably can't be illegal, since it is possible when forwarding through an intermediary with and without datagram support. Eg: Client Intermediary supports native datagram and Intermediary Server only supports datagram CAPSULE. Since the intermediary only needs to forward and not inspect, the datagram CAPSULE can arrive before the registerdatagramno_context CAPSULE.
That's what I thought initially, but the spec presently says By my read, an intermediary that receives a DATAGRAM frame and wants to convert it to a capsule needs to wait for the register capsule.
The spec doesn't define endpoint. Is an intermediary an endpoint?
Need to nail that down. Having different sending rules for clients and "intermediary doing client behaviour" is a recipe for illness, the server can't know what the sender thinks it is.
An endpoint is the opposite of an intermediary. If that's not obvious then we should spell it out in the draft. Intermediaries do not parse register capsules.
I think the parsing stuff is clear. What's a bit unclear is the message forwarding requirements. The HTTP definition [1] of intermediary allows some variance. In the gateway case, it's stated that third-party HTTP servers needs to conform to user agent requirements on the gateway's inbound connection. Allowing deviation is permitted but might cause interop problems. [1] - URL
I'm not sure what you're suggesting in terms of changes to the draft NAME could you elaborate?
The specific suggestion in this case is, disallow intermediaries from sending datagram capsules before register capsules. This might make Alan sad because an intermediary would need to buffer DATAGRAM frames and only forward them as capsules once a register is seen. Note that it would not require the intermediary to act on the register capsule, just enforce sequencing rules between datagrams and streams
I'd rather we didn't add that suggestion. It increases complexity for intermediaries and I'm not sure what problem it solves?
That's fine. I'd be happy with not adding that. However, to make it clear what the spec is allowing, we should make a note in Section 4.4 that the ordering/buffering requirements of DATGRAM frames and register capsules (from sec 3) do not apply to intermediaries when forwarding. That's tangential to Luca's OP so we can spin it off separately.
I agree, that sounds like a good resolution. Can you file an issue please?

initiated bidirectional stream MUST be treated as a connection error of type H3_FRAME_UNEXPECTED. <ins> CAPSULE frames MUST NOT be sent on a stream before at least one HEADERS frame has been sent on that stream.  This removes the need to buffer capsules when the endpoint needs information from headers to determine how to react to the capsule.  If a CAPSULE frame is received on a stream before a HEADERS frame, the receiver MUST treat this as a connection error of type H3_FRAME_UNEXPECTED. </ins> 4.1. The REGISTER_DATAGRAM_CONTEXT capsule (type=0x00) allows an endpoint 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 before they have received at least one REGISTER_DATAGRAM_CONTEXT capsule or one REGISTER_DATAGRAM_NO_CONTEXT capsule from the client 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


Endpoints MUST NOT send DATAGRAM frames using a Context ID until they have either sent or received a REGISTER_DATAGRAM_CONTEXT Capsule with <del> the same Context ID.  However, due to reordering, an endpoint that receives a DATAGRAM frame with an unknown Context ID MUST NOT treat it as an error, it SHALL instead drop the DATAGRAM frame silently, or buffer it temporarily while awaiting the corresponding REGISTER_DATAGRAM_CONTEXT Capsule. </del>  Endpoints MUST NOT register the same Context ID twice on the same stream.  This also applies to Context IDs that have been closed using

URL it clear what the spec is allowing, we should make a note in Section 4.4 that the ordering/buffering requirements of DATGRAM frames and register capsules (from sec 3) do not apply to intermediaries when forwarding. That's tangential to Luca's OP so we can spin it off separately. Originally posted by NAME in URL

Endpoints MUST NOT send DATAGRAM frames using a Context ID until they have either sent or received a REGISTER_DATAGRAM_CONTEXT Capsule with  <ins> the same Context ID.  However, reordering can cause DATAGRAM frames to be received with an unknown Context ID.  Receipt of such frames MUST NOT be treated as an error.  Endpoints SHALL drop the DATAGRAM frame silently, or buffer it temporarily while awaiting the corresponding REGISTER_DATAGRAM_CONTEXT Capsule.  Intermediaries SHALL drop the DATAGRAM frame silently, MAY buffer it, or forward it on immediately. </ins> Endpoints MUST NOT register the same Context ID twice on the same stream.  This also applies to Context IDs that have been closed using


6. <del> Implementations of HTTP/3 that support this mechanism can indicate </del>  that to their peer by sending the H3_DATAGRAM SETTINGS parameter with a value of 1.  The value of the H3_DATAGRAM SETTINGS parameter MUST <del> be either 0 or 1.  A value of 0 indicates that this mechanism is not </del>  supported.  An endpoint that receives the H3_DATAGRAM SETTINGS parameter with a value that is neither 0 or 1 MUST terminate the connection with error H3_SETTINGS_ERROR. <del> An endpoint that sends the H3_DATAGRAM SETTINGS parameter with a value of 1 MUST send the max_datagram_frame_size QUIC Transport Parameter DGRAM.  An endpoint that receives the H3_DATAGRAM SETTINGS parameter with a value of 1 on a QUIC connection that did not also receive the max_datagram_frame_size QUIC Transport Parameter MUST terminate the connection with error H3_SETTINGS_ERROR. Endpoints MUST NOT send QUIC DATAGRAM frames nor HTTP/3 CAPSULE frames until they have both sent and received the H3_DATAGRAM SETTINGS parameter with a value of 1. </del>  When clients use 0-RTT, they MAY store the value of the server's H3_DATAGRAM SETTINGS parameter.  Doing so allows the client to send <del> QUIC DATAGRAM frames and HTTP/3 CAPSULE frames in 0-RTT packets. When servers decide to accept 0-RTT data, they MUST send a H3_DATAGRAM SETTINGS parameter greater than or equal to the value they sent to the client in the connection where they sent them the </del>  NewSessionTicket message.  If a client stores the value of the H3_DATAGRAM SETTINGS parameter with their 0-RTT state, they MUST validate that the new value of the H3_DATAGRAM SETTINGS parameter

As per h3 rules, it's fine to send capsules without a setting. The setting is about the semantics of datagrams. Also remove the requirement to send the datagram transport parameter because we now have capsules.
I'm a bit confused about this one with the removal of the requirement. What purpose does the setting have now? Is it "I'm an endpoint that supports both H3 DATAGRAM frame and DATAGRAM capsule"? If so, using settings doesn't seem to gel well with the possible change of capsules to be conveyed in the datastream rather than in a CAPSULE frame.
Discussed offline and clarified. This spec defines the format of DATAGRAM frame or capsule. The SETTING helps articulate how the endpoint intends to consume things it receives. This might raise some interesting questions if someone tries to define a new formation the future. But they'll have to solve the problem they've made for themselves. This is fine as it is.
In section 6, it says "A value of 0 indicates that this mechanism is not supported." The draft actually has two mechanisms: the DATAGRAM frame and the CAPSULE frame. It would be useful to clarify that the parameter only refers to support for the DATAGRAM frame.

6.  <ins> Implementations of HTTP/3 that support HTTP Datagrams can indicate </ins> that to their peer by sending the H3_DATAGRAM SETTINGS parameter with a value of 1.  The value of the H3_DATAGRAM SETTINGS parameter MUST  <ins> be either 0 or 1.  A value of 0 indicates that HTTP Datagrams are not </ins> supported.  An endpoint that receives the H3_DATAGRAM SETTINGS parameter with a value that is neither 0 or 1 MUST terminate the connection with error H3_SETTINGS_ERROR.  <ins> Endpoints MUST NOT send QUIC DATAGRAM frames nor DATAGRAM capsules until they have both sent and received the H3_DATAGRAM SETTINGS parameter with a value of 1. </ins> When clients use 0-RTT, they MAY store the value of the server's H3_DATAGRAM SETTINGS parameter.  Doing so allows the client to send  <ins> QUIC DATAGRAM frames and Datagram capsules in 0-RTT packets.  When servers decide to accept 0-RTT data, they MUST send a H3_DATAGRAM SETTINGS parameter greater than or equal to the value they sent to the client in the connection where they sent them the </ins> NewSessionTicket message.  If a client stores the value of the H3_DATAGRAM SETTINGS parameter with their 0-RTT state, they MUST validate that the new value of the H3_DATAGRAM SETTINGS parameter


the datagram: the context identifier then maps to a compression context that the receiver can use to reconstruct the elided data. <del> 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). </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 receives a QUIC DATAGRAM frame whose payload is too short to allow parsing the Quarter Stream ID field, the intermediary MUST treat it as an HTTP/3 connection error of type H3_GENERAL_PROTOCOL_ERROR.  The <del> Context ID field is optional and its use is negotiated end-to-end, see register-no-context-capsule.  Therefore intermediaries cannot know whether the Context ID field is present or absent and they MUST ignore any HTTP/3 Datagram fields after the Quarter Stream ID. </del>  Endpoints parse both the Quarter Stream ID field and the Context ID field in order to associate the QUIC DATAGRAM frame with a stream and MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. <del> Extensions MAY define a different mechanism to negotiate the presence of contexts, and they MAY do so in a way which is opaque to </del>  intermediaries. 4.4.3.

It doesn't appear that the peer has any say in the allocation of context IDs. If not, they're not really "negotiated." Perhaps better to say that they are "declared" or merge with "allocated."

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, whether to use them or not is decided by the client 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 receives a QUIC DATAGRAM frame whose payload is too short to allow parsing the Quarter Stream ID field, the intermediary MUST treat it as an HTTP/3 connection error of type H3_GENERAL_PROTOCOL_ERROR.  The  <ins> Context ID field is optional and whether it is present or not is decided end-to-end by the client, see register-no-context-capsule. Therefore intermediaries cannot know whether the Context ID field is present or absent and they MUST ignore any HTTP/3 Datagram fields after the Quarter Stream ID. </ins> Endpoints parse both the Quarter Stream ID field and the Context ID field in order to associate the QUIC DATAGRAM frame with a stream and MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR.  <ins> Extensions MAY define a different mechanism to communicate whether contexts are in use, and they MAY do so in a way which is opaque to </ins> intermediaries. 4.4.3.


The REGISTER_DATAGRAM_CONTEXT capsule (see iana-types for the value of the capsule type) allows an endpoint to inform its peer of the encoding and semantics of datagrams associated with a given context <del> ID.  Its Capsule Data field consists of: </del>  The context ID to register. value of the capsule type) 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 <del> this stream.  Its Capsule Data field consists of: </del>  A variable-length integer that defines the semantics and encoding of the HTTP Datagram Payload field of datagrams, see datagram- The CLOSE_DATAGRAM_CONTEXT capsule (see iana-types for the value of the capsule type) allows an endpoint to inform its peer that it will no longer send or parse received datagrams associated with a given <del> context ID.  Its Capsule Data field consists of: </del>  The context ID to close. The DATAGRAM capsule (see iana-types for the value of the capsule type) allows an endpoint to send a datagram frame over an HTTP stream.  This is particularly useful when using a version of HTTP <del> that does not support QUIC DATAGRAM frames.  Its Capsule Data field consists of: </del>  A variable-length integer indicating the context ID of the datagram (see datagram-contexts).  Whether or not this field is

The thing that sucks here is that the diagram won't auto expand , so we can't easily ref the section. Manually referring to the section is a maintenance pain. So instead just state the actual type in the text an the diagram. I have a feeling you were linking to the section to avoid the maintenance hassle of updating type codes in multiple place. But I'm quite happy to take that burden because I find it more pleasant to read this way.
Perfectly reasonable
QUIC and HTTP/3 style is to define the general format and then in each instance define the object including all of its fields. This would look like This can later be updated with the actual type value once things settle down
Fine by me.
There's a disparity between the largest flow ID that can be carried in the DATAGRAM frame and the largest that we can express in Datagram-Flow-Id. Draft 00 prevents a flow ID allocation of >= 10^15-1 but doesn't seem to address the case where a DATAGRAM frame contains that value. This is clearly an error, and I'd suggest that it is a connection error; probably or some new codepoint if we really wanted.
I don't think that needs to be an error, we can simply treat this like any other unknown flow ID?
IMO this is clearly a situation that shouldn't happen and indicates the sending endpoint probably has some bug. I'm not sure on what being silent on the matter helps.
This issue is no longer relevant now that we have merged , closing.

The REGISTER_DATAGRAM_CONTEXT capsule (see iana-types for the value of the capsule type) allows an endpoint to inform its peer of the encoding and semantics of datagrams associated with a given context  <ins> ID. </ins> The context ID to register. value of the capsule type) 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  <ins> this stream. </ins> A variable-length integer that defines the semantics and encoding of the HTTP Datagram Payload field of datagrams, see datagram- The CLOSE_DATAGRAM_CONTEXT capsule (see iana-types for the value of the capsule type) allows an endpoint to inform its peer that it will no longer send or parse received datagrams associated with a given  <ins> context ID. </ins> The context ID to close. The DATAGRAM capsule (see iana-types for the value of the capsule type) allows an endpoint to send a datagram frame over an HTTP stream.  This is particularly useful when using a version of HTTP  <ins> that does not support QUIC DATAGRAM frames. </ins> A variable-length integer indicating the context ID of the datagram (see datagram-contexts).  Whether or not this field is


demultiplexing layer.  Additionally, this document defines how to convey datagrams over prior versions of HTTP.  1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

err'ing on the side of succinct
There's now several different concepts to wrangle in this document. Reading from the top, we first tackle multiplexing (the major motivation for the document), then the frame, then capsules. Capsules underpin the mechanics of multiplexing. I don't think we can fix this chicken and egg problem but adding a brief overview of the concepts and terms before they are tackled in the prose could help readability.
I think that sounds like a great idea!
Thanks for doing this!

demultiplexing layer.  Additionally, this document defines how to convey datagrams over prior versions of HTTP. <ins> This document is structured as follows: multiplexing presents core concepts for multiplexing across HTTP versions. datagram-contexts defines datagram contexts, an optional end- to-end multiplexing concept scoped to each HTTP request. datagram-formats defines datagram formats, which are scoped to contexts.  Formats communicate the format and encoding of datagrams sent using the associated context. Contexts are identified using a variable-length integer. Requirements for allocating identifier values are detailed in context-id-alloc. format defines how QUIC DATAGRAM frames are used with HTTP/3. setting defines an HTTP/3 setting that endpoints can use to advertise support of the frame. capsule introduces the Capsule Protocol and the "data stream" concept.  Data streams are initiated using special-purpose HTTP requests, after which Capsules, an end-to-end message, can be sent. The following Capsule types are defined, together with guidance for defining new types: REGISTER_DATAGRAM_CONTEXT REGISTER_DATAGRAM_NO_CONTEXT CLOSE_DATAGRAM_CONTEXT DATAGRAM </ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",


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 <del> 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 A variable-length integer that contains the value of the client- initiated bidirectional stream that this datagram is associated <del> with, divided by four.  (The division by four stems from the fact </del>  that HTTP requests are sent on client-initiated bidirectional <del> streams, and those have stream IDs that are divisible by four.) </del>  A variable-length integer indicating the context ID of the datagram (see datagram-contexts).  Whether or not this field is

…king hte law Also, switch to format to beatuiful superscript HTML rendering as used by RFC 9000.
Stating the obvious here. But we're using value with a legal range larger than semantically legal. RFC 9000 has some similar caveats with MAX_STREAMS URL To address this, the suggestion is to add something like
That suggestion sounds good to me.

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  <ins> 62-bit integer (0 to 2 -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 A variable-length integer that contains the value of the client- initiated bidirectional stream that this datagram is associated  <ins> with, divided by four (the division by four stems from the fact </ins> that HTTP requests are sent on client-initiated bidirectional  <ins> streams, and those have stream IDs that are divisible by four). The largest legal QUIC stream ID value is 2 -1, so the largest legal value of Quarter Stream ID is 2 -1 / 4.  Receipt of a frame that includes a larger value MUST be treated as a connection error of type FRAME_ENCODING_ERROR. </ins> A variable-length integer indicating the context ID of the datagram (see datagram-contexts).  Whether or not this field is


consider the effects of network design decisions on application-level performance, with considerations for the impact on video delivery. <del> Much of the focus of this document is on reliable media using HTTP over TCP, which is widely used because </del>  support for HTTP is widely available in a wide range of operating systems, HTTP can make use of already-deployed caching infrastructure.  Unreliable media delivery using RTP and other UDP-based protocols is also discussed in ultralow, udp-behavior, and hop-by-hop-encrypt, but it is difficult to give general guidance for these applications.  For

From NAME " reliable media using HTTP over TCP," should MOQ be cited here ? or HTTP/3 over QUIC ?
NAME - Thanks for catching this. The relevant point here is that HTTP is carried over reliable transport protocols. The behavior of specific transport protocols is described in subsections of Section 6. I've clarified that in Section 2.

consider the effects of network design decisions on application-level performance, with considerations for the impact on video delivery.  <ins> Much of the focus of this document is on reliable media using HTTP. HTTP is widely used because </ins> support for HTTP is widely available in a wide range of operating systems, HTTP can make use of already-deployed caching infrastructure. <ins> Various HTTP versions have been used for media delivery.  HTTP/1.0, HTTP/1.1 and HTTP/2 are carried over TCP, and TCP's transport behavior is described in tcp-behavior.  HTTP/3 is carried over QUIC, and QUIC's transport behavior is described in quic-behavior. </ins> Unreliable media delivery using RTP and other UDP-based protocols is also discussed in ultralow, udp-behavior, and hop-by-hop-encrypt, but it is difficult to give general guidance for these applications.  For


internet service provider (ISP) to attempt to "throttle" these transfers in order to to mitigate the load that these hosts placed on their network.  These efforts were met by increased use of encryption <del> in Bittorrent, similar to an arms race, and set off discussions about "Net Neutrality" and calls for regulatory action. </del>  Especially as end users increase use of video-based social networking applications, it will be helpful for access network providers to

From NAME Unsure whether the end part of this section is relevant to the document as it is rather anecdotical.
We should explain the impact on the Internet, the IETF, and regulatory agencies from the BitTorrent experience.
Working session discussion: yes this is anecdotal, but is a worthwhile example to keep because it adds a concrete example to the abstract notion of unpredictable traffic and its impacts. We think the right response is to add a paragraph to this anecdote explaining the ultimate impact to the internet that this example of unpredictable traffic had as a conclusion to explain how the experiences from unpredictable traffic can cause large and sudden shifts in network operational practice.
NAME - I agree. I suspect that the number of people who remember the impact of Comcast attending to "manage" BitTorrent on residential networks is declining every year, but it was horrendous at the time. We should make it clear that you don't have to have a hurricane to end up with sudden and massive spikes in network traffic that you never planned for.
I teach this every year to keep the new generation aware of some of the non-sense stuff their elder brothers (or sisters) had to put up with. It was not just Comcast, I can name 5 other names based on my own testing at that time.
I like the last paragraph of the PR ;-) Thanks
LGTM

internet service provider (ISP) to attempt to "throttle" these transfers in order to to mitigate the load that these hosts placed on their network.  These efforts were met by increased use of encryption  <ins> in Bittorrent, and complaints to regulators calling for regulatory action. The BitTorrent case study is just one example, but the example is included here to make it clear that unpredicted and unpredictable massive traffic spikes may not be the result of natural disasters, but they can still have significant impacts. </ins> Especially as end users increase use of video-based social networking applications, it will be helpful for access network providers to


HTTP can make use of already-deployed caching infrastructure. Unreliable media delivery using RTP and other UDP-based protocols is <del> also discussed in ultralow, unreliable, udp-behavior, and hop-by-hop- encrypt, but it is difficult to give general guidance for these applications.  For instance, when loss occurs, the most appropriate response may depend on the type of codec being used. </del>  3. standardized media-relevant information to the CDNs while they are fetching data.  CTA-5004 was developed exactly for this purpose. <del> 5.7. In contrast to segmented delivery, several applications use unreliable UDP or SCTP with its "partial reliability" extension RFC3758 to deliver Media encapsulated in RTP RFC3550 or raw MPEG Transport Stream ("MPEG-TS")-formatted video MPEG-TS, when the media is being delivered in situations such as broadcast and live streaming, that better tolerate occasional packet loss without retransmission. Under congestion and loss, this approach generally experiences more video artifacts with fewer delay or head-of-line blocking effects. Often one of the key goals is to reduce latency, to better support applications like videoconferencing, or for other live-action video with interactive components, such as some sporting events. The Secure Reliable Transport protocol SRT also uses UDP in an effort to achieve lower latency for streaming media, although it adds reliability at the application layer. Congestion avoidance strategies for deployments using unreliable transport protocols vary widely in practice, ranging from being entirely unresponsive to congestion, to using feedback signaling to change encoder settings (as in RFC5762), to using fewer enhancement layers (as in RFC6190), to using proprietary methods to detect "quality of experience" issues and turn off video in order to allow less bandwidth-intensive media such as audio to be delivered. More details about congestion avoidance strategies used with unreliable transport protocols are included in udp-behavior. </del> 6. Because networking resources are shared between users, a good place DNS requests, in practice, that was rare enough that DNS included few mechanisms to resolve contention between DNS users and other users (whether they are also using DNS, or using other application <del> protocols). </del>  In recent times, the usage of UDP-based applications that were not simple query-response protocols has grown substantially, and since impacts on other users, application-level protocols such as RTP RFC3550 have been responsible for the decisions that TCP-based applications have delegated to TCP - what to send, how much to send, <del> and when to send it.  So, the way some UDP-based applications interact with other users has changed. It is also worth pointing out that because UDP has no transport-layer </del>  feedback mechanisms, UDP-based applications that send and receive substantial amounts of information are expected to provide their own <del> feedback mechanisms.  This expectation is most recently codified in Best Current Practice RFC8085. </del>  RTP relies on RTCP Sender and Receiver Reports RFC3550 as its own feedback mechanism, and even includes Circuit Breakers for Unicast

I've edited NAME suggested text a bit, but the proposed structure was WAY more coherent than what I had assembled. Thank you for that!
From NAME Unsure whether this section really belongs to section 5 based on its contents vs. section 5 title. Especially when placed just before section 6, which is about transport protocols.
Hi, NAME I'm actually pretty sure Section 5.7 doesn't below in Section 5. :rofl: I moved the text from Section 5.7 INTO the section on UDP in Section 6, with minimal editing. I need to think about whether I need to do some more editing, but at least it's where it ought to be now.

HTTP can make use of already-deployed caching infrastructure. Unreliable media delivery using RTP and other UDP-based protocols is  <ins> also discussed in ultralow, udp-behavior, and hop-by-hop-encrypt, but it is difficult to give general guidance for these applications.  For instance, when loss occurs, the most appropriate response may depend on the type of codec being used. </ins> 3. standardized media-relevant information to the CDNs while they are fetching data.  CTA-5004 was developed exactly for this purpose.  6. Because networking resources are shared between users, a good place DNS requests, in practice, that was rare enough that DNS included few mechanisms to resolve contention between DNS users and other users (whether they are also using DNS, or using other application  <ins> protocols that share the same pathways). </ins> In recent times, the usage of UDP-based applications that were not simple query-response protocols has grown substantially, and since impacts on other users, application-level protocols such as RTP RFC3550 have been responsible for the decisions that TCP-based applications have delegated to TCP - what to send, how much to send,  <ins> and when to send it.  Because UDP itself has no transport-layer </ins> feedback mechanisms, UDP-based applications that send and receive substantial amounts of information are expected to provide their own  <ins> feedback mechanisms, and to respond to the feedback the application receives.  This expectation is most recently codified in Best Current Practice RFC8085. In contrast to adaptive segmented delivery over a reliable tansport as described in adapt-deliver, some applications deliver streaming media using an unreliable transport, and rely on a variety of approaches, including: raw MPEG Transport Stream ("MPEG-TS")-formatted video MPEG-TS over UDP, which makes no attempt to account for reordering or loss in the transport, RTP RFC3550, which can notice loss and repair some limited reordering, SCTP RFC4960, which can use partial reliability RFC3758 to recover from some loss, but can abandon recovery to limit head-of-line blocking, and SRT SRT, which can use forward error correction and time-bound retransmission to recover from loss within certain limits, but can abandon recovery to limit head-of-line blocking. Under congestion and loss, approaches like the above generally experiences transient video artifacts more often and delay of playback effects less often, as compared with reliable segment transport.  Often one of the key goals of using a UDP-based transport that allows some unreliability is to reduce latency and better support applications like videoconferencing, or for other live-action video with interactive components, such as some sporting events. Congestion avoidance strategies for deployments using unreliable transport protocols vary widely in practice, ranging from being entirely unresponsive to congestion, to using feedback signaling to change encoder settings (as in RFC5762), to using fewer enhancement layers (as in RFC6190), to using proprietary methods to detect "quality of experience" issues and turn off video in order to allow less bandwidth-intensive media such as audio to be delivered. </ins> RTP relies on RTCP Sender and Receiver Reports RFC3550 as its own feedback mechanism, and even includes Circuit Breakers for Unicast


forwarding re-encrypted media content (in this document referred to as "hop-by-hop media encryption"). <del> Both "hop-by-hop" and "end-to-end" encrypted transport may carry media that is, in addition, encrypted at the application layer. </del>  Each of these encryption strategies is intended to achieve a different goal.  For instance, application-level encryption may be This document does not take a position on whether those goals are "valid" (whatever that might mean). <del> In this document, we will focus on media encrypted at the transport layer, whether encrypted "hop-by-hop" or "end-to-end".  Because media encrypted at the application layer will only be processed by application-level entities, this encryption does not have transport- layer implications. </del> Both "End-to-End" and "Hop-by-Hop" media encryption have specific implications for streaming operators.  These are described in hop-by- hop-encrypt and e2em-encrypt.

From NAME Based on the title it is unclear whether this section also covers "app layer encryption", I guess no but this should be made clear (perhaps high in section 7 by stating that this doc does not cover app layer encryption).
This paragraph appears later in the document - I can move this up under the bullet points and make that clearer.
Fixed as in my previous comment.
BTW, unsure how the authors want me to mark "I have read the change and I like it" ? Currently, simply using a "thum up" emoticon on the solution comment. Let me know if you prefer another marking.
NAME If I can't hear you either giggling or screaming all the way to Texas, and I see a "thumbs up" emoticon, that's clear enough to me!
LGTM

forwarding re-encrypted media content (in this document referred to as "hop-by-hop media encryption").  <ins> In this document, we will focus on media encrypted at the transport layer, whether encrypted "hop-by-hop" or "end-to-end".  Because media encrypted at the application layer will only be processed by application-level entities, this encryption does not have transport- layer implications.  Of course, both "hop-by-hop" and "end-to-end" encrypted transport may carry media that is, in addition, encrypted at the application layer. </ins> Each of these encryption strategies is intended to achieve a different goal.  For instance, application-level encryption may be This document does not take a position on whether those goals are "valid" (whatever that might mean).  Both "End-to-End" and "Hop-by-Hop" media encryption have specific implications for streaming operators.  These are described in hop-by- hop-encrypt and e2em-encrypt.


dependent on interactions between the congestion controllers in use for TCP-based HTTP traffic and UDP-based HTTP/3 traffic. <del> More broadly, I-D.ietf-quic-manageability discusses manageability of the QUIC transport protocol, focusing on the implications of QUIC's design and wire image on network operations involving QUIC traffic. It discusses what network operators can consider in some detail. </del> 7. "Encrypted Media" has at least three meanings: these reasons, HTTP/3 is significantly more "opaque" than HTTPS with HTTP/1 or HTTP/2.  7.2. Although the IETF has put considerable emphasis on end-to-end

From NAME Authors may also want to refer to drafts about the same considerations (i.e., end-to-end crypto hindering operations).
Agree, will reference (was draft-ietf-tsvwg-transport-encrypt) Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols

dependent on interactions between the congestion controllers in use for TCP-based HTTP traffic and UDP-based HTTP/3 traffic.  7. "Encrypted Media" has at least three meanings: these reasons, HTTP/3 is significantly more "opaque" than HTTPS with HTTP/1 or HTTP/2. <ins> I-D.ietf-quic-manageability discusses manageability of the QUIC transport protocol that is used to encapsulate HTTP/3, focusing on the implications of QUIC's design and wire image on network operations involving QUIC traffic.  It discusses what network operators can consider in some detail. More broadly, RFC 9065 RFC9065, "Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols" describes the impact of increased encryption of transport headers in general terms. </ins> 7.2. Although the IETF has put considerable emphasis on end-to-end


1. <del> This document examines networking issues as they relate to quality of experience in Internet media delivery, especially focusing on capturing characteristics of streaming video delivery that have surprised network designers or transport experts who lack specific video expertise, since streaming media highlights key differences between common assumptions in existing networking practices and observations of video delivery issues encountered when streaming media over those existing networks. </del>  This document specifically focuses on streaming applications and defines streaming as follows: communications (for example, online videoconferencing) has also grown significantly.  While both streaming video and videoconferencing have real-time delivery and latency requirements, these requirements vary <del> from one application to another.  For example, videoconferencing demands an end-to-end (one-way) latency of a few hundreds of milliseconds whereas live streaming can tolerate latencies of several seconds. </del>  In many contexts, video traffic can be handled transparently as generic application-level traffic.  However, as the volume of video loaded, offer lower total bandwidth, or simply cover more distance. <del> Recognizing that a path carrying streaming media is "not behaving 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 </del>  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 adaptation or bitrate selection algorithms) to perform available bandwidth estimation/prediction and the bitrate selection. <del> Many server-player systems will do an initial probe or a very simple throughput speed test at the start of a video playback.  This is done to get a rough sense of the highest video bitrate in the ABR ladder that the network between the server and player will likely be able to provide under initial network conditions.  After the initial testing, clients tend to rely upon passive network observations and will make use of player side statistics such as buffer fill rates to monitor and respond to changing network conditions. </del>  <del> The choice of bitrate occurs within the context of optimizing for some metric monitored by the client, such as highest achievable video quality or lowest chances for a rebuffering event (playback stall). </del>  5.4. 5.5. This kind of bandwidth-measurement system can experience trouble in <del> several ways that are affected by networking issues.  Because adaptive application-level response strategies are often using rates as observed by the application layer, there are sometimes inscrutable transport-level protocol behaviors that can produce surprising measurement values when the application-level feedback loop is interacting with a transport-level feedback loop. </del>  A few specific examples of surprising phenomena that affect bitrate detection measurements are described in the following subsections.

From NAME Same comment as for section 1, "networking issues" actually means something broader than the plain layer-3. Suggest introducing the shortcut in the terminology part of section 1, e.g., "this document uses the wording networking issues to represent the conjunction of IP and transport layers" ?
Hi, NAME I thought this might be a quick addition of an umbrella definition of "networking" to include transport protocols, but a significant chunk of the text was distinguishing between network and transport protocols, so I added "and transport protocols" to the few occurrences of "networking" that were intended to include both.
Thank you, NAME , this is more work for the authors but less ambiguous for the readers.
From NAME Unsure whether "server-player systems" is well understood by the readers. Nit: "some metric monitored by the client" should the plural form be used ?
I dont think we made the exercise of going thru all the mixed-up terms like clients vs. players in the text. One simple solution is to do the following: (streaming) client: the part of the (media) player that deals with the transmission/reception and buffer related matters. (media) player: on top of the streaming client, this includes the media decoders, UI, user controls, DRM, authentication modules, etc.
"many systems" -
From NAME " Know Your Network Traffic" what is "your" in this section ? My network used by other parties (server and consumer) to transfer streaming video ? My network as the servers, layer-3, and consumers are all in my administrative domain? Suggest removing the 'your'
Knowing expected traffic and traffic growth baselines before something goes wrong.
From NAME While I am not an expert, I am surprised by the acceptable latency numbers, I would have written 100 msec for videoconference and "couple of seconds" for streaming live events. Video streaming (netflix like) is indeed several seconds. But, I am trusting the authors on their statement. Section 4.2 explains a little more those numbers so a forward reference to section 4 would be beneficial.
On-list discussion so far concluded that we are best off leaving it alone, with no dissent yet: URL
I've raised this issue a few times, but suspect that the right answer is to Don't change any of the numbers in this document, Recognize that latency goals are falling year by year, and Wait until we better understand the thinking in MOQ discussions about the latency requirements for live media streaming and other forms of media handling to revisit this The likely improvements from continued discussions about latency categories aren't worth holding up this document.
Up to the authors, really, but suggest to add some text about those numbers are in flux ?
Yeah, that sounds like a good idea. Some clarifying context in the section 4 header where these numbers appear might help avoid some confusion.
NAME - that sounds like a win to me. My goal was to NOT say something like "these numbers are old and inaccurate, so good luck!"
We agree with the suggestion for forward reference to Section 4.
LGTM Hi, Jake, Holland, Jake wrote: specifically about the 1 second for videoconferencing, which is clearly wrong, because we've known that people accidentally talk over other people when latencies are more than 200 ms for decades, but it's probably not wrong enough to be worth talking about changing it. Honestly, if this document is about Operational Considerations for Streaming Media, anyone reading it for guidance about videoconferencing probably has bigger problems than the latency categories. I think we're through discussing that part, at least for now. Best, Spencer

1.  <ins> This document examines networking and transport protocol issues as they relate to quality of experience in Internet media delivery, especially focusing on capturing characteristics of streaming video delivery that have surprised network designers or transport experts who lack specific video expertise, since streaming media highlights key differences between common assumptions in existing networking practices and observations of video delivery issues encountered when streaming media over those existing networks. </ins> This document specifically focuses on streaming applications and defines streaming as follows: communications (for example, online videoconferencing) has also grown significantly.  While both streaming video and videoconferencing have real-time delivery and latency requirements, these requirements vary  <ins> from one application to another.  For additional discussion of latency requirements, see latency-cons. </ins> In many contexts, video traffic can be handled transparently as generic application-level traffic.  However, as the volume of video loaded, offer lower total bandwidth, or simply cover more distance.  <ins> In order 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 </ins> 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 adaptation or bitrate selection algorithms) to perform available bandwidth estimation/prediction and the bitrate selection.  <ins> Many systems will do an initial probe or a very simple throughput speed test at the start of a video playback.  This is done to get a rough sense of the highest video bitrate in the ABR ladder that the network between the server and player will likely be able to provide under initial network conditions.  After the initial testing, clients tend to rely upon passive network observations and will make use of player side statistics such as buffer fill rates to monitor and respond to changing network conditions. </ins>  <ins> The choice of bitrate occurs within the context of optimizing for one or more metrics monitored by the client, such as highest achievable video quality or lowest chances for a rebuffering event (playback stall). </ins> 5.4. 5.5. This kind of bandwidth-measurement system can experience trouble in  <ins> several ways that are affected by networking and transport protocol issues.  Because adaptive application-level response strategies are often using rates as observed by the application layer, there are sometimes inscrutable transport-level protocol behaviors that can produce surprising measurement values when the application-level feedback loop is interacting with a transport-level feedback loop. </ins> A few specific examples of surprising phenomena that affect bitrate detection measurements are described in the following subsections.