Re: [tcpm] New Version Notification for draft-ietf-tcpm-rtorestart-03.txt

On 2014-10-13 18:20, Yuchung Cheng wrote:
> On Mon, Oct 13, 2014 at 1:48 AM, Per Hurtig <per.hurtig@kau.se> wrote:
>> On Thu, Oct 09, 2014 at 09:49:13PM +0300, Pasi Sarolahti wrote:
>>> On 09 Oct 2014, at 20:32, Yuchung Cheng <ycheng@google.com> wrote:
>>>
>>>> On Thu, Oct 9, 2014 at 2:34 AM, Pasi Sarolahti <pasi.sarolahti@iki.fi>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> Thanks, Yuchung, for bringing this up. It reminds me of an old note I
>>>>> sent to the list quite a long while ago: I think it would be good if the
>>>>> algorithm was designed so that it cannot (even in theory) result in negative
>>>>> RTO values. The most straightforward way to fix this would be to include
>>>>> some kind of max(RTO - T_earliest, some_threshold) guard in the algorithm.
>>>>> It might not protect against spurious timeouts, but at least would keep the
>>>>> values in sensible range.
>>>>
>>>> This would work but it might reduce the benefit (and adding yet
>>>> another magic threshold). A negative value is a
>>>> strong signal that the first unacked packet is lost. The problem in my
>>>> case is the reaction is not appropriate (reset cwnd again) because we
>>>> have just make some forward progress.
>>>
>>> Right, magic numbers are not nice (but it could be 0, just to prevent
>>> negatives). Or then the draft should otherwise discuss handling of negative
>>> values, and make it clear if there might be such. Some implementations might
>>> define RTO as unsigned, in which case a negative value becomes very large
>>> value…
>>>
>>> - Pasi
>>>
>> Hi all,
>>
>> I agree that we should formalize what to do if the timeout becomes
>> negative due to RTOR. In our current implementation we don't invoke RTOR
>> at all if the resulting value (RTO - T_earliest) is <= 0. That is, it
>> has to be a positive number.
>>
>> I think this is a fair trade-off, and could be included in the coming
>> internet-draft. Do you think it's too conservative?
> It's not conservative. It's just awkward.
>
> If RTO - T_earliest is 1 ms, we retransmit almost right away. If it's
> past due (<= 0), we wait another RTO. The fix would work, it just
> sound like a hack. Sorry I try to be polite but I couldn't find a
> better word...
I agree it is not conservative, but I do not think it is so awkward.  
When you have a retransmission the ACK will arrive after RTO+RTT. And if 
you sent multiple packets to start with, then the calculated value of 
(RTO - T_earliest) will (most likely) be negative. This was the example 
that started this discussion and as pointed out, you do not want to use 
RTOR in this case as the segment will be immediately retransmitted 
anyway. Not invoking RTOR for negative values captures this case. From 
an algorithmic standpoint I cannot think of another scenario without 
retransmission where the value would be negative. (If we can come up 
with one, or one exists that we cannot think of, it may still be safe to 
not use RTOR.)

If you tweak the send pattern in the example with the retransmission you 
can also get a small value. In theory this should not matter as the RTO 
will be reset anyway when the segment is retransmitted in response to 
the ACK. You can however also get small values during normal 
transmission, where you want to use RTOR, and this is the reason to use 
RTOR for positive values.

So from an algorithmic standpoint I think not invoking RTOR when (RTO - 
T_earliest) is <= 0 captures the behavior we want. Maybe in practice 
there is some possibility to rearm and have the RTO fire before the 
retransmission in response to the ACK will happen though? If so, this 
retransmission would better be avoided.

A perhaps better alternative could be to state that RTOR is not used for 
ACKs that acknowledge retransmitted (and previously unacknowledged) 
segments. That is what we want to avoid anyway.

Cheers,
Anna

>
>>
>> Cheers,
>> Per
>>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm