Draft: draft-ietf-masque-h3-datagram

Commentary: in Section 2 " Flow Identifiers " it reads this to me seems to be in conflict with the opening statement if the flow - id is in the DATAGRAM payload , the transport is not supposed to be peeking at it . While it could be a nice ( but a bit hacky ) optimization in a real - world implementation , I feel like the RFC having it as a SHOULD is not ideal . 
 In my experience , in order to build a high performance implementation of QUIC , you have to leverage the fact that layers can share information to improve performance . Are you saying that you 'd prefer not using SHOULD for this kind of optimization ? 
 I think Luca might have a point . If we consider this as a feature that a transport provides as a service , I do n't really know what the service provides . There is n't another transport mechanism that relies on the ordering , or an interoperable aspect ( would the other side be able to detect this ? ) . It seems this is an aspect more about the API that QUIC provides , which is going to be a rich field of opportunity . There could be benefits but I do n't know if we need to use the SHOULD . We could probably relax the language and try to articulate the benefits or tradeoffs of packetization and frame bundling . For instance , batching might interfere with timeliness , and controlling that might start creeping into prioritisation territory . The more I think about it , the described behaviour about batch processing might assume the receiver behaves a certain way , which might not be true . Therefore this might not be a good default to recommend . 
 Fair enough . Perhaps we remove this for now , and add guidance once we have more implementation / deployment experience ? 
 I can live with a less drastic edit , leaving the text in draws the reader attention to the idea that packing could be important . I 'd be happy to put together an editorial replacement for review , and if we hate it , then drop the concrete recommendation ? 
 Thanks Lucas , you framed it way better than I could . Also I believe that whether shared - fate within a flow is desirable or not may depend on the application . 
 I came here looking for the same information : Why is fate - sharing desired ? Is there some background to this ? 
 I think more implementation and deployment experience would help here . I can see cases like tunneling IP flows containing TCP where fate sharing is preferable , since it 's better to lose two adjacent packets in one flow than one packet each in two flows . But it seems a bit use - case specific ? Also , you would expect most TCP segments to be large enough you could n't put two into a single QUIC packet .
Flows lack any of the ordering or reliability guarantees of streams.
Beyond this, a sender SHOULD ensure that DATAGRAM frames within a
single flow are transmitted in order relative to one another.  If
multiple DATAGRAM frames can be packed into a single QUIC packet, the
sender SHOULD group them by flow to promote fate-sharing within a
specific flow and improve the ability to process batches of datagram
messages efficiently on the receiver.
Flows lack any of the ordering or reliability guarantees of streams.
Beyond this, a sender SHOULD ensure that DATAGRAM frames within a
single flow are transmitted in order relative to one another.