search

tsvwg / careful-resume

Careful Resume
1 stars 6 forks source link

Section 3.2 Editor note: Reconnaissance Phase (Is there a need for a minimum required number of RTT samples to confirm a path?) #22

Closed joergdeutschmann-i7 closed 2 months ago

joergdeutschmann-i7 commented 7 months ago

A few thoughts on what could happen considering IW=10 packets

gorryfair commented 7 months ago

All true - I'm not sure the draft can add much clarity around this topic across the range of practical paths, patterns of transmission and receiver ACK policy : I wonder whether we should resolve this with no additional text?

joergdeutschmann-i7 commented 7 months ago

Regarding my example: If the cwnd is given in bytes and the packets are very small, it could be even more RTT samples.

Not sure if something like this could be helpful: Reconnaissance Phase (RTT samples): The number of RTT samples available in this phase varies depending on the implementation. and maybe ..., at least one RTT sample MUST be available. But both is kind of obvious.

So yes, probably best to resolve this without additional text.

gorryfair commented 7 months ago

I agree with the peposal to close with a minor edit.

BTW: "Regarding my example: If the cwnd is given in bytes and the packets are very small, it could be even more RTT samples."

joergdeutschmann-i7 commented 7 months ago

Is that so? TCP would have ACK'ed every other MSS (or ACK_Del).

Yes, RFC9293 says An ACK SHOULD be generated for at least every second full-sized segment or 2*RMSS bytes of new data Accordingly, RFC9000 says A receiver SHOULD send an ACK frame after receiving at least two ack-eliciting packets.

My (rather hypothetical) thought was more "how many RTT measurements could I get out if the IW"

TheEnbyperor commented 7 months ago

To chime in with my experience from testing this on real-world connections;

In 1-RTT connections this isn't an issue, there's more than enough back and forth chatter (initial packets, crypto frames, HTTP/3 settings exchange, etc) before the app-limited stage is entered to get a good idea of the RTT.

In 0-RTT not much of this really happens, since the whole HTTP/3 setup (or whatever other protocol you're using) can be sent in one big chunk. I think therefore the spec should include a SHOULD (BCP14) on how many samples should be taken before proceeding with CR.

gorryfair commented 7 months ago

It still seems akwards to have a "SHOULD" for how many samples, to me, it seems the usefulness of a set of RTT samples rather depends on the independence of their measurements. At the moment, I don't know how to express that as a requirement that is meaningful, I'd like to be able to tell how representative that RTT samples will be of the path when I use it, is that something we can know?

TheEnbyperor commented 7 months ago

Off the top of my head I think the best measure for independence of RTT samples is the times between when the data that is being acked was sent out.

So, a run of RTT samples based on paced out data is more representative than RTT samples based on a load of data sent in very quick succession.

gorryfair commented 7 months ago

I's agree pacing the data is likely to find a better minRTT (which is what is needed in this case). Although pacing across an RTT (or a fraction of an RTT) also costs time, and whether that is great, or not, might depend on the usage. I expect the form of pacing of IW is an implementation/policy decision.

TheEnbyperor commented 7 months ago

If I were more of a statistician I'd come up with some function that relates variance between RTT samples and time between data being sent, and use that. This is a poorly disguised invitation for someone who is better as statistics to try.

joergdeutschmann-i7 commented 7 months ago

But please let's not use complex stochastic calculations in the draft 😅

TheEnbyperor commented 7 months ago

Agreed, but it'd be useful to have some idea if adding this note would even point towards something achievable/useful.

gorryfair commented 2 months ago

Let's look at the text about how minRTT is calculated from the ACKs received in the Recon. Phase to see if we can find a way to close this.

gorryfair commented 2 months ago

The current text says: During this (the recon) phase, a sender MUST record the minimum RTT for the current connection as the current_rtt.

And then: Reconnaissance Phase (Path confirmed): When a sender has confirmed the RTT and also has received an acknowledgement for the initial data without reported congestion, it MAY then enter the Unvalidated Phase. This transition occurs when a sender has more data than permitted by the current CWND.

... To me this clearly allows a sender to combine multiple RTT samples when calculating the Min RTT, and since the IW is typically 10 packets, and it is common to receive ACKs for every second packet, this would suggest this is often 5 RTT measurements.

I suspect this is sufficient for most cases.

joergdeutschmann-i7 commented 2 months ago

Yes. The text in the current draft is clear and appropriate.