Draft: draft-ietf-masque-h3-datagram

Commentary: Punt prioritization to extensions like QUIC and HTTP/3 did . 
 I think it 's be valuable for h3 - datagram to be able to use the new HTTP priority draft . I think it 'd be ok to say that the datagram flow has the same prioritization as the request that initiated it . I do n't think anything more complex is necessary , but I could be wrong . 
 That seems reasonable to me , assuming that we can get some implementations of this first . I suspect that we 'll want this text to live in whichever gets published last between draft - ietf - masque - h3 - datagram and . 
 The extensible priorities draft does n't prioritise streams , it prioritizes responses . Is it sufficient that only a client can control the relative priority of datagrams coming back to it ? 
 oh and FWIW as an editor on priorities , we are pretty close to a WGLC . If there 's merit in saying something about datagrams and priorities , putting it here feels like the right thing . 
 Given the client already has the ability to control the relative priority of datagrams its sending , I think that 's ok ? Possibly there are use cases where the server wants to indicate a priority to the client as well ? My strawman use case is tunneling multiple HTTP/3 connections : One goes to the origin , one goes to a static content server , ads , etc , and the client wants to receive data from the origin at a higher priority than the other data . 
 I think that is a good use case ! I do n't know if someone will turn around and say they really want to support that server control use case , I 'm keen to hear strong proponents to really understand why . Making DATAGRAM priority based on streams aids parity between CONNECT and CONNECT - UDP cases . To your mind , would datagrams be prioritized against other datagrams and other streams ? There 's probably something to say here , especially the edge case where there is data to be sent non - incrementally on the stream AND the datagram flow . Something to consider is also that if we go ahead with a 2 - layer approach , whether we want to expose per - flow priorities . Maybe that can be done by carrying the extensible priority value as an extension field in the flow creation message . Although it does sound a bit too much complexity . 
 I really hope we can avoid that , since it means the proxy / intermediary would have to deal with subflows , whereas currently it does n't have to . Also , for most of the subflow use cases I 've heard , I do n't think that would be valuable or necessary . 
 Agree about the context / subflows things . Lets avoid that . For the bigger picture stuff I 'd need to think on this some more . Perhaps a mildly flexible solution is to define an extensible priorities extension that would 1 ) explain some of the considerations into scheduling relative priorities between streams and datagrams 2 ) define a parameter to allow explicit setting of datagram flow priority . For example , to have an incremental stream at urgency 1 and incremental datagram at urgency 3 We could then state that omitting the parameter means the stream 's priority is used . 3 ) by adding more params to we could even support explicit signalling of the wish for shared priority space , or segregated . 
 I 'd say that defining a new prioritization parameter should be left to its own document , I 'd prefer not to have this in h3 - datagram itself 
 I agree its scope creep . I would be ok with this document saying very little and punting the problem to a ( which I would entertain co - writing ) 
 I think defining priorities of sub - flows would be useful in  's use case if you wanted to merge the priorities of streams within the tunneled QUIC connections at the entry proxy , rather that strictly prioritize one tunnel over another . One could do this by registering a context - ID for each priority level . This context - ID could be used by the intermediary ( did I break the rules again ? ) to determine the priority of the datagram back towards the client . 
 I 'm going to propose closing this issue with no action , with the intent to leave this functionality to extensions . 
 Adding text that says by default datagrams inherit the priority of the stream they are associated with seems likely to capture the most common cases . If we ca n't agree on that and want to punt , it would be good to indicate in the draft that priority of datagrams is undefined / implementation specific . 
 I 'll would be happy with  's suggestion . I will prepare a PR unless someone beats me too it . Edit : suggestion to state that it is undefined 
 stating that it is undefined sounds great to me . 
 I prefer it inherit the priority of the associated stream as suggested . 
 I think that sounds like an easy suggestion but in practice does n't help implementers . Inheriting the same signal does n't really help the multiplexing scheduling conundrum - IMO trying to make any reasonable suggestion will tie up time in this document development that could be answered elsewhere . 
 If I 'm an intermediary l7 load balancer , and support h3 - datagram but am not looking deeper into the payload , I 'm going to have to make scheduling decisions , so leaving it undefined could cause large differences in how h3 - datagram based applications work on different intermediaries . 
 Right but that 's the situation the base HTTP/3 specification has right now too . And even if the  balancer applies scheduling logic based on the extensible priorities draft , 1 ) it would need to decide how to schedule ingress data ( request content ) itself , since that is not defined 2 ) we have little experience about how to schedule datagram and stream data concurrently . I would expect implementers to turn around immediately and ask us how to do that if we say explicitly here that there is a datagram priority signal . I am not saying we punt the question indefinately . But in the interest of making progress here ( especially to limit feature creep ) I am suggesting we write a standalone document that can capture all the concerns as completely as is useful . If that draft makes rapid progress it might be a candidate for getting incorporated back into the H3 datagram specification . I would be happy to bootstrap that document in a new repo and work with  ,  or other folks that can give some opinions . 
 +1 to The more I think about this the more I believe that H3DGRAM has to match what H3 does - in a vacuum as an implementor I do n't know how to implement " datagram should inherit priority of the corresponding stream " when no one has actually defined what a priority is . There are important questions like " should higher priority completely starve lower priority or not ? " that are not answered by H3 . H3DGRAM itself can not depend on a given priorities extension , because we might define a different priorities scheme later . Having a separate draft that explains how to combine draft - ietf - masque - h3 - datagram and draft - ietf - httpbis - priority sounds like the best option .
Prioritization of HTTP/3 datagrams is not defined in this document.
Future extensions MAY define how to prioritize datagrams, and MAY
define signaling to allow endpoints to communicate their
prioritization preferences.