Clarify In-flight #2200
Clarify In-flight #2200
Conversation
draft-ietf-quic-recovery.md
Outdated
| @@ -102,7 +102,8 @@ In-flight: | |||
|
|
|||
| : Packets are considered in-flight when they have been sent | |||
| and neither acknowledged nor declared lost, and they are not | |||
| ACK-only. | |||
| ACK-only. Packets are still considered in-flight even if | |||
| their payloads no longer need to be delivered. | |||
There was a problem hiding this comment.
| their payloads no longer need to be delivered. | |
| their payloads no longer need to be delivered in order to maintain the congestion window. |
There was a problem hiding this comment.
I'm confused about what you're trying to add here?
There was a problem hiding this comment.
Maybe I got the in-flight concept wrong, but in order to make the definition significant, there must be a reason for it, otherwise it is just semantics. I.e. why does it matter whether.
There was a problem hiding this comment.
In-flight packets count towards bytes in flight, which is defined in the pseudocode section, but we could move that definition up here if it's helpful.
ianswett
added
editorial
There was a problem hiding this comment.
I'm not sure that this is necessary or even helpful. If we accept that information is what is repaired, rather than packets or frames, then we don't need to concern ourselves with this clarification. To that end, packets are disposable, just as frames are. What matters here is that packets are neither lost nor acknowledged, which the existing text covers nicely.
|
I updated this to be a clarifying example, which I think is more helpful than re-iterating the previous sentence. PTAL. |
| @@ -102,7 +102,9 @@ In-flight: | |||
|
|
|||
| : Packets are considered in-flight when they have been sent | |||
| and neither acknowledged nor declared lost, and they are not | |||
| ACK-only. | |||
| ACK-only. For example, packets containing STREAM frames are | |||
There was a problem hiding this comment.
I think that the "for example" is missing context. Perhaps:
: Packets are considered in-flight when they have been sent and neither acknowledged nor declared lost. ACK-only packets are not considered in-flight, though all other packets are, including packets that contain data that would not otherwise be sent again, such as a packet containing only STREAM frames for a reset stream.
There was a problem hiding this comment.
That works for me. @janaiyengar what do you think?
There was a problem hiding this comment.
After starting to add this in, I don't think it reads as clearly as I'd like, so I didn't. However, I did fix an error in the pseudocode below involving ACK-only packets not being considered in-flight.
|
I fixed the pseudo-code issue in #2219 so I'm going to close this, since I think it's doing more harm than good. |
I'm not sure this is necessary, but I've had at least 2 people be unsure about whether a packet is still in flight if all the stream data in it is cancelled, so maybe it's worth stating this explicitly?