MAY send 1 packet entering recovery #3443
Conversation
Similar to TCP as described in Section 5 of RFC 6675 Fixes #3335
ianswett
added
design
|
Should we restrict this to retransmittable frames that were lost in the packet? If it was a small packet, can I pack to the MTU? What about pure ACKs that I've declared lost? |
|
Those are great questions. There are two goals in my mind. The first is to ensure loss recovery is not unnecessarily slower than TCP. The second is to ensure this behavior isn't significantly more aggressive than TCP. But within those bounds, I'm inclined to not be too restrictive, if that makes sense? Suggestions welcome if you think they'd be an improvement. |
|
Well the pedantic answer is that TCP would only detect a loss if there was something in the bytestream. the QUIC equivalents would then be any packet that contained STREAM, CRYPTO, MAX_STREAM_DATA, etc, plus any packet that flipped the key update bit. But not ACK, MAX_DATA, and other things that are in the TCP header. That is obviously a dumb way to approach things. I don't actually have a strong opinion on this one way of the other, but if I read the draft correctly, the loss of an ACK-only packet will affect cwnd in QUIC but not TCP (granted, a cwnd-constrained endpoint sending pure ACKs is a corner case). So I guess I'd err on the side of permitting the packet in response to loss of an ACK, as we're already quite a bit less aggressive than TCP in that case. Anyway, do we want any normative language against, say, using this permission to send high-priority new data instead of the lost data? |
|
Adding language against sending new data or data besides data that's been lost couples the "can I send" with "what should I send" questions more than I would like unless it's absolutely critical. FYI, to be declared lost, it must be in-flight: https://github.com/quicwg/base-drafts/blob/master/draft-ietf-quic-recovery.md#acknowledgement-based-detection-ack-loss-detection
|
|
Ah, I think we're fine then. |
| @@ -706,6 +706,13 @@ The recovery period limits congestion window reduction to once per round trip. | |||
| During recovery, the congestion window remains unchanged irrespective of new | |||
| losses or increases in the ECN-CE counter. | |||
|
|
|||
| When entering recovery, a single packet MAY be sent even if bytes in flight | |||
There was a problem hiding this comment.
If it is possible to enter recovery before amplification mitigation is no longer needed, sending a packet upon entering recovery might contradict amp. rules.
There was a problem hiding this comment.
Agreed, but the amplification factor is a MUST and this is a MAY, so I think the MUST wins here?
There was a problem hiding this comment.
I'm not sure. It depends on what you read first. It's like that NATO test with two pages of questions and instructions, the first stating to read everything first, the last stating the all other questions need not be answered. Why gives those entries priority over other entries?
Similar to TCP as described in Section 5 of RFC 6675
Fixes #3335