Re: [tcpm] new version of 2988bis

On Wed, Dec 29, 2010 at 1:54 AM, Per Hurtig (work) <per.hurtig@kau.se>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 <rs@netapp.com>
> 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:per.hurtig@kau.se]
> >> Sent: Mittwoch, 22. Dezember 2010 10:16
> >> To: tcpm@ietf.org
> >> Cc: mallman@icir.org
> >> 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 <mallman@icir.org> 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
> >> > tcpm@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/tcpm
> >> >
> >> _______________________________________________
> >> tcpm mailing list
> >> tcpm@ietf.org
> >> https://www.ietf.org/mailman/listinfo/tcpm
> >
> >
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>