Re: [tcpm] new version of 2988bis

["Per Hurtig (work)" <[e-mail]>]

Hi and thanks for all the comments,

all of you are, of course, correct in that a single variable isn't
enough. I don't understand why I put it like that in the ID, and why I
felt that it would work =)

I've implemented this approach a long time ago in FreeBSD (for SCTP),
and there I had the sending time of each message stored in the
internal packet structure (just like Jerry pointed out for linux TCP).

An alternative approach could be to set RTO = RTO-RTT upon each
restart of the timer. This is not equally exact as the delayed ack
timer of the receiver will impact the rtt.

I also agree in that there are a number of things that could affect
this approach, including the de facto minRTOs and the rtt sampling
rules. I'll, however, carry out some experiments fairly soon to
investigate this further.


Happy new year,

Per

On Thu, Dec 30, 2010 at 14:28, Scheffenegger, Richard <[e-mail]> wrote:
>
>
> Thank you Jerry!
>
>
>
> Per,
>
>
>
> The sender cannot know which segment will eventually be covered in a
> cumulative ACK (it could be any segment in the current window), thus a
> singular variable in tcpcb doesn’t appear to be able to hold enough
> information.
>
>
>
> Of course, if you have additional side information for each segment (ie.
> Linux TCP stack) or carried back for each segment (such as timestamps
> reflecting the TCP sender clock perfectly), you can get away with much less
> state in the sender. (I think the TS option would be the only viable way for
> BSD-derived TCP stacks).
>
>
>
>
>
> Also, I am very interested in learning your results on the slow-link – if
> the variability inducted by the serialization delay would be enough to
> prevent undue spurious RTOs. Note that RFC1323 rules out the usability of
> timestamps for RTT calculation during a window containing loss…
>
> Thus I strongly suspect, that if you are sending a burst of data, and loose
> one early segment (where serialization delay is still low), the sender will
> not be able to adjust the RTTM (and varability) properly – resulting exactly
> in the scenario described by Jerry (much higher spurious RTOs).
>
>
>
> Also, even though the RFCs have minRTO at 1 sec, all available stacks
> violate this today per default, afaik. Typical minRTO is between 100 and 400
> msec, and there are stacks with a default minRTO is in the low 10s of msec…
>
>
>
> Thus it might be more prudent to verify if the timeliness of latency
> feedback to the sender is enough, to work with the current RTTM / RTO
> tunables (sRTT + 4* varRTT), or if that formula needs to be adjusted…
>
>
>
> Or, if the RFC1323 guidance of *not* using RTT feedback during loss events
> need to be reviewed to allow a more tight estimation of RTT and varRTT under
> all circumstances, in turn allowing more tight RTO values…
>
>
>
> Happy new year,
>
>    Richard
>
>
>
>
>
> From: Jerry Chu [mailto:[e-mail]]
> Sent: Mittwoch, 29. Dezember 2010 20:13
> To: Per Hurtig (work)
> Cc: Scheffenegger, Richard; [e-mail]; [e-mail]
>
> Subject: Re: [tcpm] new version of 2988bis
>
>
>
> On Wed, Dec 29, 2010 at 1:54 AM, Per Hurtig (work) <[e-mail]>
> wrote:
>
> I don't see why it should be necessary to track all unacked segments
> (or maybe I'm just not seeing it...). The only difference between this
> proposal and the original approach is that you account for the sending
> time of the earliest outstanding segment. The restart only happens
>
>
>
> But doesn't that require one to record the sending time of each segment?
>
>
>
> BTW, Linux already does this (i.e., timestamping each skb before sending,
> regardless
>
> of the timestamp option). Dunno about other OSes.
>
>
>
> Jerry
>
>
>
> when a pure cumulative acknowledgment arrives. Can you exemplify when
> the approach would fail?
>
> // Per
>
> On Wed, Dec 22, 2010 at 12:41, Scheffenegger, Richard <[e-mail]> wrote:
>>
>> Hmm...
>>
>> How do you deal with multiple lost segments in the same window? Your draft
>> says
>>
>>  2.  Proposed Modifications
>>
>>   The document proposes an update of step 5.3 in Section 5 of [RFC2988]
>>   to (and a similar update of step R3 in section 6.3.2 of [RFC4960]):
>>
>>      When an ACK is received that acknowledges new data, restart the
>>      retransmission timer so that it will expire RTO seconds after the
>>      earliest outstanding segment was transmitted (for the current
>>      value of RTO).
>>
>>   The update requires TCP implementations to track the time elapsed
>>   since sending the last unacknowledged segment.  In practice, this
>>   could be achieved by adding one variable to the transmission control
>>   block.
>>
>> But wouldn't you really need to track the sending time of *each* segment,
>> to always be able to calculate the true T_earliest? I can not see how a
>> singular, global TCPCB variable addresses this - perhaps I'm missing
>> something?
>>
>> Wouldn't there be an opportunity to use this feature synergistically with
>> RFC1323 Timestamps also? (The ACK with new data should reflect the sender's
>> TCP clock (or a well derived value thereof) at the time the segment was
>> sent. Perhaps that information can help reducing additional per-segment
>> state in the sender?)
>>
>> Best regards,
>>   Richard Scheffenegger
>>
>>
>>> -----Original Message-----
>>> From: Per Hurtig (work) [mailto:[e-mail]]
>>> Sent: Mittwoch, 22. Dezember 2010 10:16
>>> To: [e-mail]
>>> Cc: [e-mail]
>>> Subject: Re: [tcpm] new version of 2988bis
>>>
>>> Hi all,
>>>
>>> we have submitted an I-D that summarizes an alternate way to restart
>>> the TCP/SCTP RTO timer:
>>>
>>> http://www.ietf.org/id/draft-hurtig-tcpm-rtorestart-00.txt
>>>
>>> The difference between this approach and RFC2988(bis)'s approach is
>>> the way outstanding segments are
>>> considered. We're happy to receive any comments on the draft.
>>>
>>>
>>> Regards, Per H
>>>
>>>
>>>
>>>
>>> On Tue, Dec 7, 2010 at 04:33, Mark Allman <[e-mail]> wrote:
>>> >
>>> > Folks-
>>> >
>>> > We posted a new version of the 2988bis I-D today.  It is:
>>> >
>>> >  draft-paxson-tcpm-rfc2988bis-01.txt
>>> >
>>> > The big change is a new set of empirical results that pertain to
>>> > dropping the initial RTO from 3sec to 1sec is now given (along with
>>> the
>>> > previous results from Google) in the appendix.  Generally speaking,
>>> > these results show it is pretty safe to drop the initial RTO.
>>> >
>>> > Have a look.  I believe the authors are pretty happy with this
>>> document
>>> > at this point.
>>> >
>>> > allman
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > tcpm mailing list
>>> > [e-mail]
>>> > https://www.ietf.org/mailman/listinfo/tcpm
>>> >
>>> _______________________________________________
>>> tcpm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>
>