Draft: draft-ietf-quic-datagram

Commentary: This was a suggestion from 
 Can someone explain why the ack from Datagram - only packets are not used for loss recovery ? I would appreciate if someone can point me to an existing discussion or explanation . Thanks . 
 That 's because datagram - only packets do n't contain any frames that need to be retransmitted - so there 's no recovery to be done . In other words : what was lost does n't need to be retransmitted . Therefore it 's not urgent to let the peer know that this packet was lost because the peer is n't rushing to retransmit anything . 
 Side note : the last sentence is not correct : the peer does not know that the packet only contains Datagram frames , because the packet has been lost . Back to the original text quoted above . The ack for a Datagram - only packet can still be use to detect loss of other packets , therefore it may be used for loss recovery . In my opinion it should be treated the same as the other ack - eliciting packets . Can we improve he sentence ? 
 In that sentence , the peer was the endpoint who sent the datagram - only packet , so they know what frames it contains . Apologies if that was unclear . Those are n't mutually exclusive . If you receive a train of many datagram - only packets , it is useful to delay acks . If you receive a datagram - only packet whose packet number is more than one apart from the previous packet you saw , then it 's indicative of a lost ( or reordered ) packet so you can act on that to trigger a more urgent ack , regardless of the frame content of the latest received packet . But it 's possible we can improve the phrasing in the draft . Do you have a proposal in mind ? 
 It feels like the key realization chain here is : DATAGRAM - only packets have nothing to retransmit if they 're lost Therefore , senders do n't need to keep the payload of these packets around in case they need to retransmit them Therefore , receipt of an acknowledgement for a DATAGRAM - only packet frees minimal resources on the sender 's side Therefore , it 's not urgent for receivers to signal that they successfully received a DATAGRAM - only packet So perhaps something like : Receivers SHOULD support delaying ACK frames ( within the limits specified by maxackdelay ) in response to receiving packets that only contain DATAGRAM frames , since the sender takes no action if these packets are temporarily unacknowledged . Receivers SHOULD continue to send ACK frames when conditions indicate a packet might be lost , since the packet 's payload is unknown to the receiver , and when dictated by maxackdelay or other protocol components . Note also " reponse " = " response " 
 Thanks . That is more clear . 
 Seems strictly more clear , nice!This is an editorial change that clarifies the intent of the text .
Although DATAGRAM frames are not retransmitted upon loss detection,
they are ack-eliciting (RFC9002).  Receivers SHOULD support delaying
ACK frames (within the limits specified by max_ack_delay) in reponse
to receiving packets that only contain DATAGRAM frames, since the
timing of these acknowledgements is not used for loss recovery.
Although DATAGRAM frames are not retransmitted upon loss detection,
they are ack-eliciting (RFC9002).  Receivers SHOULD support delaying
ACK frames (within the limits specified by max_ack_delay) in response
to receiving packets that only contain DATAGRAM frames, since the
sender takes no action if these packets are temporarily
unacknowledged.  Receivers will continue to send ACK frames when
conditions indicate a packet might be lost, since the packet's
payload is unknown to the receiver, and when dictated by
max_ack_delay or other protocol components.