<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Am 19.05.2014 18:59, schrieb Vint Cerf:<br>
</div>
<blockquote
cite="mid:CAHxHggfBv=2diONun1RaEQ5Bn-DEHZrQeO4sT5yaqhdBUoOt5Q@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
<div dir="ltr">one RTO per connection makes sense: </div>
</blockquote>
<br>
Sorry, I think you got me wrong there.<br>
<br>
One _value_ for the retransmission time out makes sense, that goes
without discussion.<br>
<br>
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.<br>
<br>
<blockquote
cite="mid:CAHxHggfBv=2diONun1RaEQ5Bn-DEHZrQeO4sT5yaqhdBUoOt5Q@mail.gmail.com"
type="cite">
<div dir="ltr">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..</div>
</blockquote>
<br>
The interesting point is, that my understanding of RFC 2988 is to
maintain only one retransmission timer,<br>
<br>
When I refer to section 5, it says:<br>
<br>
<blockquote type="cite">
<pre class="newpage"><span class="h2"><h2><a class="selflink" name="section-5" href="http://tools.ietf.org/html/rfc2988#section-5">5</a> Managing the RTO Timer</h2></span>
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).
<span class="grey">Paxson & Allman Standards Track [Page 4]</span>
</pre>
<pre class="newpage"><a name="page-5" id="page-5" href="http://tools.ietf.org/html/rfc2988#page-5" class="invisible"> </a>
<span class="grey"><a href="http://tools.ietf.org/html/rfc2988">RFC 2988</a> Computing TCP's Retransmission Timer November 2000</span>
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 <a href="http://tools.ietf.org/html/rfc2988#section-2">section 2</a> 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).</pre>
</blockquote>
<br>
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. <br>
<br>
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.<br>
<br>
<pre class="moz-signature" cols="72">--
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30
70565 Stuttgart Tel.: +49 711 5208031
mobile: +49 172 6819937
skype: detlef.bosau
ICQ: 566129673
<a class="moz-txt-link-abbreviated" href="mailto:detlef.bosau@web.de">detlef.bosau@web.de</a> <a class="moz-txt-link-freetext" href="http://www.detlef-bosau.de">http://www.detlef-bosau.de</a>
</pre>
</body>
</html>