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

[hiren panchasara <[e-mail]>]

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