search

quicwg / datagram

In-progress version of draft-ietf-quic-datagram
https://quicwg.org/
31 stars 8 forks source link

Question about: "not used for loss recovery" #47

Closed ddragana closed 3 years ago

ddragana commented 3 years ago

Can someone explain why the ack from Datagram-only packets are not used for loss recovery?

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.

I would appreciate if someone can point me to an existing discussion or explanation. Thanks.

DavidSchinazi commented 3 years ago

That's because datagram-only packets don't contain any frames that need to be retransmitted - so there's no recovery to be done. In other words: what was lost doesn't need to be retransmitted. Therefore it's not urgent to let the peer know that this packet was lost because the peer isn't rushing to retransmit anything.

ddragana commented 3 years ago

That's because datagram-only packets don't contain any frames that need to be retransmitted - so there's no recovery to be done. In other words: what was lost doesn't need to be retransmitted. Therefore it's not urgent to let the peer know that this packet was lost because the peer isn'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?

DavidSchinazi commented 3 years ago

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.

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.

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?

Those aren'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?

MikeBishop commented 3 years ago

It feels like the key realization chain here is:

So perhaps something like:

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 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 max_ack_delay or other protocol components.

Note also "reponse" => "response"

ddragana commented 3 years ago

Thanks. That is more clear.