<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><br>
I presume that I'm allowed to forward some mail by DPR here to the
list (if not, DPR may kill me...), however the original mail was
sent to the Internet History list and therefore actually intended
to reach the public.<br>
<br>
A quick summary at the beginning: Yes, TCP doesn't manage for sent
packets a retransmission queue with copies of the sent packets but
maintains an unacknowledged data queue and does GBN basically.
This seems to be in contrast to RFC 793, but that's life.<br>
<br>
A much more important insight into the history of TCP is the
"workload discussion" as conducted by Raj Jain and Van Jacobson.<br>
Unfortunately, both talk completely at cross purposes and have
completely different goals......<br>
<br>
Having read the congavoid paper, I noticed that VJ refers to Jains
CUTE algorithm in the context of how a flow shall reach
equilibrium.<br>
<br>
Unfortunately, this doesn't really make sense, because slow start
and CUTE pursue different goals.<br>
<br>
- Van Jacobson asks how a flow should reach equlibrium,<br>
- Raj Jain assumes a flow to be in equilibrium and asks which
workload makes the flow work with an optimum performance.<br>
<br>
We often mix up "stationary" and "stable". To my understanding,
for a queueing system "being stable" means "being stationary",
i.e.<br>
the queueing system is positively recurrent, i.e., roughly, in
human speech: None of the queue lengths will stay beyond all
limits for all times but there is a probability > 0 for a queue
to reach a finite length at any time.<br>
<br>
A queueing system is stationary when its arrival rate doesn't
permanently exceed its service rate, this is actually nothing else
than the "self clocking mechanism" and the equilibrium VJ is
talking about. <br>
<br>
From RJ's papers I see a focus on the workload and the perfomance
of queueing systems. A possible performance metric is the quotient<br>
p = average throughput / average sojourn time.<br>
<br>
If the workload is too little, operators will have idle times, the
system is not fully loaded. (=> sojourn time acceptable,
throughput to small.)<br>
If the workload is too large, too much jobs are not being serviced
but reside in queues. (=> throughput fine, sojourn time too
large.)<br>
<br>
From Jain's work we conclude that a queueing system has an optimum
workload - which can be assessed by probing. <br>
=> Set a workload, assess the system's performance, adjust the
workload.<br>
<br>
Van Jacobson will reach the equilibrium.<br>
=> Set a workload, if we see drops, the workload is too large.<br>
<br>
As a consequence, a system may stay perfectly in equilibrium state
while seeing buffer bloat in the sense of "a packet's queueing
time is more than a half of the packet's sojourne time.<br>
<br>
I don't know yet, perhaps someone can comment on this one, whether
buffer bloat will affect a system's performance. (My gut feeling
is: "Yes it will". Because the sojourn time grows inadequately
large.)<br>
<br>
The other, more important, consequence is that probing for
"dropfreeness" of a system does not necessarily mean the same as
"probing for optimum performance". <br>
<br>
Detlef <br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Am 20.05.2014 16:49, schrieb David P. Reed:<br>
</div>
<blockquote
cite="mid:f0194819-662e-4bb9-9bbb-c0e2b05a3a42@katmail.1gravity.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=utf-8">
I really appreciate the work being done to reconstruct the diverse
set of implementations of the end to end TCP flow, congestion, and
measurement specs.<br>
<br>
This work might be a new approach to creating a history of the
Internet... meaning a new way to do what history of technology
does best.<br>
<br>
I'd argue that one could award a PhD for that contribution when it
reaches a stage of completion such that others can use it to study
the past. As a work of historical impact it needs citation and
commentary. Worth thinking about how to add citation and
commentary to a simulation - something like knuth's literate
programming but for protocol systems.<br>
<br>
Far better than a list of who did what when, or a set of battles.
It's a contribution to history of the ideas...<br>
<br>
<div class="gmail_quote">On May 20, 2014, Detlef Bosau
<a class="moz-txt-link-rfc2396E" href="mailto:detlef.bosau@web.de"><detlef.bosau@web.de></a> wrote:
<blockquote class="gmail_quote">
<pre class="k10mail">Am 19.05.2014 17:02, schrieb Craig Partridge:
<blockquote class="gmail_quote">Hi Detlef:
I don't keep the 4.3bsd code around anymore, but here's my recollection
of what the code did.
4.3BSD had one round-trip timeout (RTO) counter per TCP connection.</blockquote>
That's the way I find it in the NS2.
<blockquote class="gmail_quote">On round-trip timeout, send 1MSS of data starting at the lowest outstanding
sequence number.</blockquote>
Which is not yet GBN in its "pure" form, but actually it is, because
CWND is increased with every new ack. And when you call "send_much" when
a new ack arrives (I had a glance at the BSD code myself some years ago,
the routines are named equally there, as far as I've seen, the ns2 cod
e
and the BSD code are extremely similar) the behaviour resembles GBN very
much.
<blockquote class="gmail_quote">Set the RTO counter to the next increment.
Once an ack is received, update the sequence numbers and begin slow start
again.
What I don't remember is whether 4.3bsd kept track of multiple outstanding
losses and fixed all of them before slow start or not.</blockquote>
OMG. ;-) Who else should remember this, if not Van himself our you?
However, first of all I have to thank for all the answers here.
Detlef
</pre>
</blockquote>
</div>
<br>
-- Sent from my Android device with <b><a moz-do-not-send="true"
href="https://play.google.com/store/apps/details?id=com.onegravity.k10.pro2">K-@
Mail</a></b>. Please excuse my brevity.
</blockquote>
<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>