Original text:
If the sender wants to elicit a faster acknowledgement on PTO, it can skip a packet number to eliminate the ack delay. <del> When the PTO timer expires, and there is new or previously sent unacknowledged data, it MUST be sent.  A probe packet SHOULD carry new data when possible.  A probe packet MAY carry retransmitted unacknowledged data when new data is unavailable, when flow control does not permit new data to be sent, or to opportunistically reduce loss recovery delay.  Implementations MAY use alternative strategies for determining the content of probe packets, including sending new or retransmitted data based on the application's priorities. </del>  It is possible the sender has no new or previously-sent data to send. As an example, consider the following sequence of events: new

Reviewer comments:
I think this is clearer, but maybe there's a larger change people would like.
Currently "Sending Probe Packets" define the priority what to be in Probe packet as follows: A probe packet SHOULD carry new data when possible. A probe packet MAY carry retransmitted unacknowledged data when new data is unavailable. And also says "Implementations MAY use alternative strategies for determining the content of probe packets, including sending new or retransmitted data based on the application's priorities." When there is no new data (case 2), the implementation need to choose which one to retransmit when there is a multiple data loss in the sender. QUIC's Probe packet approach is a combined experience of TCP TLP and RTO and I believe Probe packet is more similar to TLP. RACK draft says (URL) "The probe data segment can either be new, previously unsent data, or a retransmission of previously sent data just below SND.NXT" so it's pretty clear which one to send among the lost data (newest one). Is there any reason that it's up to the implementers when it need to choose which one to send from lost data? It's better to clarify which one to send among retransmitted unacknowledged data, from oldest or newest when there is multiple data packet lost. I think it's better to send newest (unacked) one first if I follow the reasoning of TLP (new to the old), but there may be some reason why the current draft doesn't define it clearly. URL has some background and my comment.
A lot of the reasoning behind TLP comes from TCP counting bytes and not counting packets. In TCP, new data means a new sequence number, thus a higher chance to trigger ACKs or SACKS. failing that, it is best in TCP to repeat the last transmitted bytes, because that too will trigger ACK or dup ACK or SACK. But for Quic, any new packet will have a new sequence number, so from a transport engine point of view it does not matter very much what data is in that packet. Logically it should be the most urgent data among all the available streams. So first pick the most urgent stream with something to send; if that something is old data presumed lost, send it; if there is no data presumed lost on that stream and there is new data available, send that. If there is no data available at all on that stream, then pick the next most urgent stream, etc.
I think this is the right answer but need some clarification on the draft text. I think there is 2 different approach for the content of Probe packet depending on the role of Probe packet: 1) if the tail loss is most concerning (what's what I understand from TLP) then we would send a new data if available, or newest lost to move the right edge and update ACK ranges. 2) If HoL is most concerning then we would send oldest lost data (or highest priority data) to move the left edge (but it may be delivered already, because we may lost some acks) However the draft says we always try to send a new data first regardless of lost data, so I assume 1). But if the priority is simply on the urgent data, we don't need to send a new data first.
This is a great question and I incline towards sending the newest (tail) unacknowledged data first (same as TLP in TCP). Lets say we sent packets 1,2,3,4 & 5 at the same time and assume 1 & 5 were lost. Now, PTO fires. Lets say, on PTO expiry, we retransmit the oldest packet i.e. 1. When the PTO timer fires a second time, only then we would send pn=5. OTOH, if we retransmit the tail first, i.e. pn=5, it provides faster recovery, because an arriving ACK with largest pn=4 will mark pn=1 as lost and we will retransmit that immediately. The unacknowledged packets at the head have the advantage of subsequent packets allowing them to recover via ACKs marking them as lost. Not so much for the tail packets.
NAME I'm not sure I understand the argument here. Why would the content of the retransmission matter for declaring packets lost?
We declare packets lost when So, a tail packet (with no packets after it) wouldn't be marked lost until after some earlier packets were retransmitted.
I don't understand why people think that it is important to standardize this. Do we have research that points more clearly to one choice being better than another?
That's correct, but a retransmission always has a higher packet number than earlier sent packets, so the contents of the packet don't matter, right? Or am I misunderstanding your argument? I agree with NAME We already have some advice about retransmitting packets in section 13.3:
This seems right to me; we're retransmitting frames, not packets. If folks get a chance to experiment with this and publish their results, that would be super cool! But it seems like that's somewhat orthogonal to getting this spec finished, since so far we've settled with "doing the default thing should get you functional QUIC". It seems like all options here work well enough that we don't need further text unless either we have some data or we have a principle of why one option is deterministically better?
NAME I am not saying that the contents matter. What I am saying is if we send a PTO probe for the tail packet, we would recover faster as it doesn't have to wait for ACKs for the retransmissions of earlier packets (1 as 6). With this approach we would be able to retransmit both tail (via PTO) and head (via ACK for pn 4) faster than the other approach. That being said, I am neutral towards making any change to the draft and leaving it to implementors is a fine option.
I also think that we do not need to standardize this. If I understand correctly, we do not define how data should be sent for the first time. I think the only point we make is that a QUIC implementation SHOULD provide ways in which an application can indicate the relative priority of streams (URL). I do not think that there is a baked-in assumption that the receiving application would be reading the stream from the beginning. Assuming that my understanding is correct (it could be wrong), I do not think we need to talk any more about what should be done to transmit data the second time.
Well... We retransmit information, not frames or packets. :) Those people who do retransmit frames are not strictly wrong, but they are also not going to get the best results either. Kazuho has provided what I think is the definitive response here.
My point is what to send in Probe packet, not a usual retransmission detected by loss detection algorithm. recovery 6.3.4 has the following sentences: While B) can be a research topic on which one is better to retransmit if there is multiple loss reported (oldest or newest), I wonder if A) and C) seems conflicting because "new data MUST be sent" limits C) to pick up a strategy to send which data to retransmit. I think there is some history why A) is in the first place and I believe it's from TLP definition. Initially my question was there is an ambiguity on what to retransmit from lost packet. As many people pointed out, I understand QUIC's monotonic packet number property will make better ACK ranges report coming back when we send a Probe packet. This makes less importance on sending a new data as MUST. If so, now I think we don't need to have a new data transmission as MUST.
I guess NAME has a point. There is probably a tad too much text in the recovery draft, and the MUST there would be better replaced by an RFC 6919 variant.
Having re-read these, the inconsistency isn't that inconsistent. But it could still be improved. The rules require that you send unacknowledged data, whether it was sent before or not. Then they recommend unsent data, and allow retransmissions (the latter of which is somewhat redundant). Then (C) is something about not really meaning the first MUST. If anything, this should be tuned down to a recommendation to send unacknowledged data and to steer clear of any proscription regarding new transmissions vs. retransmissions. However, we should try to seek consensus on a change because it would seem like any change here is a change to normative language.
I keep re-reading this, and I don't see any conflict of C with A, but I can create an editorial PR to reduce the likelihood of someone reading "new data MUST be sent" into A.
LGTM. Thanks!

Revised text:
If the sender wants to elicit a faster acknowledgement on PTO, it can skip a packet number to eliminate the ack delay.  <ins> When the PTO timer expires, an ack-eliciting packet MUST be sent.  An endpoint SHOULD include new data in this packet.  Previously sent data MAY be sent if no new data can be sent.  Implementations MAY use alternative strategies for determining the content of probe packets, including sending new or retransmitted data based on the application's priorities. </ins> It is possible the sender has no new or previously-sent data to send. As an example, consider the following sequence of events: new