Re: [tcpm] A question about PTO/RTO rescheduling in RACK draft

[Matt Olson <[e-mail]>]

Previously, you'd start the RTO timer on the first packet, and the timer would run until an ACK was received. Now, the timer is reset on each new packet. So the concern is that there exist cases where previously TCP would reduce the CWnd and retransmit, but not anymore.

If all such cases are app-limited cases, then I like Hiren's point about this being a "keep CWnd in check while app-limited" problem. 

-----Original Message-----
From: hiren panchasara <[e-mail]> 
Sent: Wednesday, April 17, 2019 11:14 AM
To: Yi Huang <huanyi=[e-mail]>
Cc: [e-mail]; Matt Olson <[e-mail]>
Subject: Re: [tcpm] A question about PTO/RTO rescheduling in RACK draft

On 04/17/19 at 01:48P, Yi Huang wrote:
> Hi,

Hi!
I don't see anything inherently wrong in how this works or I am missing something.
> 
> I have a question about PTO/RTO rescheduling logic in RACK draft. The draft states, in Section 6.5.1, "If there was a previously scheduled PTO or RTO pending, then that pending PTO or RTO should first be cancelled, and then the new PTO should be scheduled". So if an app keeps posting data in an interval less than PTO and RTO (say one byte each time and Cwnd is large enough) and no acks are coming back due to network failures or a receiver that just does not send anything back, the app will never fires RTO since the timer is pushed out each time we send this one byte data. Is this a problem?
By growing CWND, TCP has decided that it is okay to send that much without needing an ACK.
I think something along the lines of detecting that connection is app-limited OR doing newcwv like validation may help to keep CWND in check?

> What is the intention of pushing out the timer for each send?
6.5.1 (Step 1) indicated a few conditions for scheduling PTO (i.e.
pushing out the timer) so its not blindly doing for each send. But it would do that for the case you described as app *is* handing new data to be sent to TCP.

>I think in this case the sender should disconnect the connection because, without TLP, the sender would have had several RTOs and closed the connection.
I am probably not understanding something. I think you are saying TLP is causing RTO to be pushed out unnecessarily.

One cannot schedule PTO when a TLP is out. So, on first timeout i.e. PTO as we prefer that over RTO, you send a TLP out. And if you don't get an ACK back for that, next timeout would be an RTO as 6.5.1.  Phase 1 condition 1 suggests.

But if there is new data to be sent, RTO would also gets pushed out, no?
> 
> Also, RFC 6298 Section 5 (5.1) states "Every time a packet containing data is sent (including a retransmission), if the timer is not running, start it running so that it will expire after RTO seconds (for the current value of RTO).", which says TCP should schedule timer only when it is not schedule yet and this kind of conflicts with (or is overridden by) what is in RACK/TLP draft.

I am not sure I follow. For the connection, you need a timeout mechanism. And RACK draft suggests keeping PTO aligned with RTO as the former is less expensive. Try PTO and if it doesn't work, do RTO.

I believe the wordings around "first cancel the pending one and then only schedule new one" are for clarity around implementation details.
Gist is to not keep 2 sets of timers running for the same timeout mechanism. 

Someone with more clue on the list would probably correct me. :-) Cheers, Hiren