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

[Per Hurtig <[e-mail]>]

On Thu, Oct 09, 2014 at 09:49:13PM +0300, Pasi Sarolahti wrote:
>On 09 Oct 2014, at 20:32, Yuchung Cheng <[e-mail]> wrote:
>
>> On Thu, Oct 9, 2014 at 2:34 AM, Pasi Sarolahti <[e-mail]> 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?


Cheers,
Per