Subject: [tcpm] new version of 2988bis

From: Mark Allman <[email-masked]>
Date: Mon, 06 Dec 2010 22:33:56 -0500

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

---

From: "Per Hurtig (work)" <[email-masked]>
Date: Wed, 22 Dec 2010 10:16:09 +0100

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 <[email-masked]> wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 22 Dec 2010 11:41:03 -0000

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:[email-masked]]
> Sent: Mittwoch, 22. Dezember 2010 10:16
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [tcpm] new version of 2988bis
> 
> Hi all,
>

---

From: Jerry Chu <[email-masked]>
Date: Tue, 28 Dec 2010 14:21:16 -0800

Hi,

Have you tried your proposed change on slow links (e.g., 56Kbps dialup)?

Your proposal assumes RTTs for pkts in a burst are statistically independent
of each other's existence. This may be true for fast links but not for
slower links
when the serialization delay dominates the round trip time for transmitting
a
packet. E.g., when you have a micro burst of n packets, the RTT for the m'th
packet will include the serialization delay of itself and all the preceding
packets.
Your proposed change may cause a lot of spurious RTOs for later packets in a
burst, including the ones in a large IW.

The current paragraph in RFC2988 of restarting the RTO timer afresh upon
each
ack, although more conservative, limits the additive effect of serialization
delay
to the RTT to at most 2 packets (due to delayed acks).

Best,

Jerry

---

From: "Per Hurtig (work)" <[email-masked]>
Date: Wed, 29 Dec 2010 10:54:00 +0100

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
when a pure cumulative acknowledgment arrives. Can you exemplify when
the approach would fail?

// Per

---

From: "Per Hurtig (work)" <[email-masked]>
Date: Wed, 29 Dec 2010 11:13:56 +0100

Hi,

we have not yet experimented with slow links, but we will. Maybe there
will be an
increased amount of unnecessary RTOs due to serialization delay, but
that will also
depend on:

* the RTOmin -- if set to 1s it will surely protect a subset of the
slow connections,
* and # of RTT samples per window -- if more than one sample, the RTT
variation could
  compensate for the serialization delay

Regards,

Per

---

From: Jerry Chu <[email-masked]>
Date: Wed, 29 Dec 2010 11:13:27 -0800

> 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

> > 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
> >
> >

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 30 Dec 2010 13:28:17 -0000

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:[email-masked]] 
Sent: Mittwoch, 29. Dezember 2010 20:13
To: Per Hurtig (work)
Cc: Scheffenegger, Richard; [email-masked]; [email-masked]
Subject: Re: [tcpm] new version of 2988bis

On Wed, Dec 29, 2010 at 1:54 AM, Per Hurtig (work) <[email-masked]>
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

BTW, Linux already does this (i.e., timestamping each skb before
sending, regardless

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
<[email-masked]> wrote:
	> 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?)
	>> > dropping the initial RTO from 3sec to 1sec is now given
(along with
	>> the
	>> > Have a look.  I believe the authors are pretty happy with
this
	>> document

---

From: "Per Hurtig (work)" <[email-masked]>
Date: Thu, 30 Dec 2010 16:38:31 +0100

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 <[email-masked]> wrote:
> singular variable in tcpcb doesn’t appear to be able to hold enough
> information.
>
>
>
> 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).
>
>
>
> 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…
>
>
>
> 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
>
>
>
>
>