Draft: draft-ietf-quic-datagram

Commentary: I 've dramatically simplified what we say for pacing now , to just call it out and the fact that it can add slight delays . thoughts ? 
 I like the latest text , it 's clear about things that are required , but it does n't provide advice that we have n't tested . LGTM . 
 I am having trouble parsing this . I think that this is saying that if you have a pacer , then an endpoint might delay DATAGRAM frames to avoid overriding the sending rate of the pacer . However , this seems to imply that the maximum delay imposed here is the inter - packet interval of the pacer . I think that is a bad assumption , even if it might be a simplifying assumption that some implementations might choose to adopt . In some cases , the pacer interval will be too slow for the application ( for low BDP , high RTT connections especially ) or in some cases the pacer interval might be short enough to allow multiple intervals before dropping the packet ( for high BDP , short RTT connections ) . The goal should just be to avoid deferring DATAGRAM sending indefinitely , with controls over any delays being available to applications . Maybe : 
 I think the goal here was to prevent implementations naively dropping DATAGRAM frames anytime they could n't be sent immediately , which would be a pathologically bad case when a packet pacer is being used . But good point that this should be clarified . 
 Early in our VPN implementation , we sent QUIC datagrams without any queueing , assuming that if a datagram gets dropped , then we exceeded the cwnd ( and thus the estimated channel capacity ) , so it would likely not reach the peer anyways . In practice , this turned out to be a terrible idea that lead to underutilization of the channel ; our implementation always does pacing , so if you do n't queue the datagram , it will get dropped unless it just happens to fit into the current pacing quantum . Because pacing is RECOMMENDED for QUIC , I believe some form of queueing should be RECOMMENDED for datagrams , otherwise the users risk running into the same hard - to - debug problem that we had . 
 I think adding a note about pacing to the " Congestion Control " subsection makes sense to me . 
 +1 , if you 're in the bucket of implementations that have insight into their pacing algorithm , it should be reasonable to expect that you 'd avoid dropping your own datagrams unless you make a queue and then build up too much in that queue . 
 Small wording nits around " allows it " twice , but I do n't have a radically better wording handy so looks good :)
DATAGRAM frames employ the QUIC connection's congestion controller.
As a result, a connection might be unable to send a DATAGRAM frame
generated by the application until the congestion controller allows
it RFC9002.  The sender implementation MUST either delay sending the
frame until the controller allows it or drop the frame without
sending it (at which point it MAY notify the application).
Implementations that use packet pacing SHOULD support delaying the
transmission of DATAGRAM frames for at least the time it takes to
send the paced packets allowed by the congestion controller to avoid
dropping frames excessively.
DATAGRAM frames employ the QUIC connection's congestion controller.
As a result, a connection might be unable to send a DATAGRAM frame
generated by the application until the congestion controller allows
it RFC9002.  The sender implementation MUST either delay sending the
frame until the controller allows it or drop the frame without
sending it (at which point it MAY notify the application).
Implementations that use packet pacing (Section 7.7 of RFC9002) can
also delay the sending of DATAGRAM frames to maintain consistent
packet pacing.