[ih] One clarification: Re: When was Go Back N adopted by TCP

[Detlef Bosau]

Am 19.05.2014 18:59, schrieb Vint Cerf:
> one RTO per connection makes sense:

Sorry, I think you got me wrong there.

One _value_ for the retransmission time out makes sense, that goes
without discussion.

The very point is that RFC 793 (and some off list discussions with Jon
and Dave) made clear, that a TCP implementations have one _timer_ per
packet. Both, Jon and David, pointed me to the concept of timer wheels,
as the number of timers may grow large here.

> calculate and monitor the RTT for the connection and use that value to
> timeout and retransmit the oldest, unacknowledged packet. This is NOT
> GBN. It makes no sense to do RTO per packet calculation especially if
> the packet had to be retransmitted since you then get into double
> delay affecting the RTT computation..

The interesting point is, that my understanding of RFC 2988 is to
maintain only one retransmission timer,

When I refer to section 5, it says:

>
>     5 <http://tools.ietf.org/html/rfc2988#section-5> Managing the RTO
>     Timer
>
>
>
>    An implementation MUST manage the retransmission timer(s) in such a
>    way that a segment is never retransmitted too early, i.e. less than
>    one RTO after the previous transmission of that segment.
>
>    The following is the RECOMMENDED algorithm for managing the
>    retransmission timer:
>
>    (5.1) Every time a packet containing data is sent (including a
>          retransmission), if the timer is not running, start it running
>          so that it will expire after RTO seconds (for the current value
>          of RTO).
>
>    (5.2) When all outstanding data has been acknowledged, turn off the
>          retransmission timer.
>
>    (5.3) When an ACK is received that acknowledges new data, restart the
>          retransmission timer so that it will expire after RTO seconds
>          (for the current value of RTO).
>
>
>
>
>
>
>
> Paxson & Allman             Standards Track                     [Page 4]
>   <http://tools.ietf.org/html/rfc2988#page-5>
> RFC 2988 <http://tools.ietf.org/html/rfc2988>          Computing TCP's Retransmission Timer     November 2000
>
>
>    When the retransmission timer expires, do the following:
>
>    (5.4) Retransmit the earliest segment that has not been acknowledged
>          by the TCP receiver.
>
>    (5.5) The host MUST set RTO <- RTO * 2 ("back off the timer").  The
>          maximum value discussed in (2.5) above may be used to provide an
>          upper bound to this doubling operation.
>
>    (5.6) Start the retransmission timer, such that it expires after RTO
>          seconds (for the value of RTO after the doubling operation
>          outlined in 5.5).
>
>    Note that after retransmitting, once a new RTT measurement is
>    obtained (which can only happen when new data has been sent and
>    acknowledged), the computations outlined in section 2 <http://tools.ietf.org/html/rfc2988#section-2> are performed,
>    including the computation of RTO, which may result in "collapsing"
>    RTO back down after it has been subject to exponential backoff
>    (rule 5.5).
>
>    Note that a TCP implementation MAY clear SRTT and RTTVAR after
>    backing off the timer multiple times as it is likely that the
>    current SRTT and RTTVAR are bogus in this situation.  Once SRTT and
>    RTTVAR are cleared they should be initialized with the next RTT
>    sample taken per (2.2) rather than using (2.3).

This may imply (and having looked at the NS2 source, I state that it is
so understood in the NS2) that there is only one timout up and running
per connection.

I repeat: There might be a severe misumderstanding on my side, when I
have questions and things are not clear to me, it's up to me to make
sure that I understand things correctly.

-- 
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30   
70565 Stuttgart                            Tel.:   +49 711 5208031
                                           mobile: +49 172 6819937
                                           skype:     detlef.bosau
                                           ICQ:          566129673
detlef.bosau at web.de                     http://www.detlef-bosau.de

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20140520/beca18d9/attachment.htm>