jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-quic-datagram

Commentary: The draft has some good text in the " Acknowledgement Handling " and " Congestion Control " sections that essentially is stating that DATAGRAM is just like any other ACK - eliciting packet , but is not automatically retransmitted by the transport . That 's all reasonable , but I think there needs to be more text on how the ( suspected ) loss of a packet with a DATAGRAM frame or a PTO with only an outstanding DATAGRAM packet should be handled . I can see two possible models : 's just like any other packet . The goal is to elicit some ACK from the peer to get accurate loss information about the outstanding packet as soon as possible . If there is nothing outstanding we could use to send in a new packet , just send a PING frame . 's special . Because we do n't necessarily intend to retransmit the data in the packet if it is actually lost , we do n't actually care about immediate loss information / feedback . Do n't force anything to be sent immediately to elicit the ACK . So far as I have it coded up in  , I 've assumed ( 1 ) . This essentially results in an immediate PING frame / packet being sent out if I have nothing else to retransmit to try to elicit an ACK for the DATAGRAM frame / packet . This could result in a slightly noisier connection if the app does n't care about all loss information about their datagrams , but , IMO makes for a cleaner design . I do n't know what the general consequences to congestion control might be if we do n't do this . Assuming folks are in agreement , we should have some text on this topic in the draft . 
 as authors of the recovery draft do you have an opinion here ? 
 I support choice of 1 and it aligns with the recovery draft . It also matches our implementation . Adding clarifying text around this SG and I 'd be happy to review it . 
 I agree -- choice ( 1 ) is cleanest and I would argue that choice(2 ) is really not principled . 
 Late to the issue , but I think ( 1 ) is the right choice here . It 's not simply that datagrams are n't retransmitted , but that they might be retransmitted by the application if they 're declared lost . If you do n't have prompt feedback , that scenario suffers . 
 Seems like we have good agreement on this , just need to write the text 
 -- To 's comment at the mic , you should cite . 
 This text sounds good , though I 'd love a little bit more text mentioning the benefit of this probeThis text is fine with me . I am wondering if we should say something additional , like that packets with datagram frames should n't be treated special , with respect to loss recovery .
As with any ack-eliciting frame, when a sender suspects that a packet
containing only DATAGRAM frames has been lost, it MAY send probe
packets to elicit a faster acknowledgement as described in
Section 6.2.4 of RFC9002.
Draft: draft-ietf-quic-datagram

Commentary: Warn against the pathological case of dropping packets due to pacing . 
 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 . 
 Thanks !
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 I-D.ietf-quic-recovery.  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).
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 I-D.ietf-quic-recovery.  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.
Draft: draft-ietf-quic-datagram

Commentary: Current text says : This is nice , but I 'm wondering if it should be . The  UDP payload for a QUIC packet is , which is lower than both . It 's nice for an implementation to only need to store 16 - bit integers for  datagram size to avoid excess memory , and it 's of course easy to round down from to , but it just seems arbitrary to have it be 1 more than the  value for a 16 - bit integer ... 
 thoughts ? 
 That sounds reasonable , is fine by me . ( as long as the 1s do n't take longer to travel than the 0s )
to send the value 65536 in the max_datagram_frame_size transport
parameter as that indicates to the peer that this endpoint will
accept any DATAGRAM frame that fits inside a QUIC packet.
to send the value 65535 in the max_datagram_frame_size transport
parameter as that indicates to the peer that this endpoint will
accept any DATAGRAM frame that fits inside a QUIC packet.