<div dir="ltr">I thinkl Vint's right - the Internet is very complex. it's very difficult to draw conclusions about its behavior.<div><br></div><div>In addition to the variance in delay on those "wires", there's other unpredictable influences on the behavior of the algorithms. </div>
<div><br></div><div>For example, random events that happen may effect A and B differently, even though they are implemented identically.</div><div><br></div><div>I saw an example of this in the Oracle internal internet-clone back in the 90s. Users had been complaining about performance instability. So we instrumented the paths along the network (like A,B to S and C, but somewhat more complex. A and B were in our building near San Francisco, and C was somewhere far away, I think in Asia. Lots of SNMP gathering lots of data from the equipment along the path.</div>
<div><br></div><div>We had two identical A and B computers, who were presumably therefore using identical TCP implementations (the TCPs were not ours, so we couldn't "look inside"). When two simultaneous jobs were fired up, they started A-C and B-C interactions, which were essentially the same, i.e., it was "fair". They each got similar throughput and delay behavior, as seen by the users.</div>
<div><br></div><div>However, eventually something somewhere would drop a packet, e.g., caused by a noise burst on a satellite circuit. That would of course trigger retransmission and other error recovery mechanisms.</div>
<div><br></div><div>What we observed was that, after the dust settled, the two virtual circuits would return to a stable flow. The TCP connections remained intact. </div><div><br></div><div>But one flow was about twice the delay and half the throughput of the other. Very unfair.</div>
<div><br></div><div>Investigating further, we determined that, after the disruption cleared, one of the TCPs had settled into a new stable pattern where every packet was being sent twice. I.E., it was retransmitting everything.</div>
<div><br></div><div>This was rather annoying since not only was the user seeing less throughput and higher delay, the network was using twice as much resource to deliver that poor service. Intercontinental circuits are expensive!</div>
<div><br></div><div>Presumably one of the TCPs was the one which had a packet destroyed, and the other one didn't. But they both experienced a disruption as the satellite circuit reset, so they both may have decided to retransmit. Obviously one of them didn't handle the situation as well as the other, even though they were identical. Since the TCP involved was out of our control, we passed the problem to the computer vendor. Whether or not they ever fixed it is anybody's guess.</div>
<div><br></div><div>It might be tempting to characterize this as a "bug", either in the code or in the algorithm. But it illustrates that, even with identical implementations of the same algorithm, "fairness" is an elusive goal.</div>
<div><br></div><div><br></div><div><br></div><div>/Jack Haverty</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, May 18, 2014 at 3:26 PM, Vint Cerf <span dir="ltr"><<a href="mailto:vint@google.com" target="_blank">vint@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">i think this is not an adequate analysis. Delay variations between A, S, B and C might produce different timeouts even if the RTT measurement algorithms are the same. "fair"is not a simple notion in the dynamic and variable world of the Internet.<span class="HOEnZb"><font color="#888888"><div>
<br></div><div>v</div><div><br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, May 18, 2014 at 5:49 PM, Detlef Bosau <span dir="ltr"><<a href="mailto:detlef.bosau@web.de" target="_blank">detlef.bosau@web.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Just to make my thoughts more clear.<br>
<br>
Let A,B,C end nodes, S some switch.<br>
<br>
A<br>
\<br>
S---------------------------------C<br>
/<br>
B<br>
<br>
Assume one data flow from a to C, a competing one from B to C.<br>
<br>
I expect that it makes a difference, whether both TCPs employ the same<br>
RTO scheme or, e.g. A, uses a more aggressive one that does earlier<br>
retransmissions than its competitor. At least when we expect both TCPs<br>
to use a fair share of resources, both TCPs should employ the same scheme.<br>
<br>
Do you agree?<br>
<div><div><br>
Detlef<br>
<br>
--<br>
------------------------------------------------------------------<br>
Detlef Bosau<br>
Galileistraße 30<br>
70565 Stuttgart Tel.: <a href="tel:%2B49%20711%205208031" value="+497115208031" target="_blank">+49 711 5208031</a><br>
mobile: <a href="tel:%2B49%20172%206819937" value="+491726819937" target="_blank">+49 172 6819937</a><br>
skype: detlef.bosau<br>
ICQ: 566129673<br>
<a href="mailto:detlef.bosau@web.de" target="_blank">detlef.bosau@web.de</a> <a href="http://www.detlef-bosau.de" target="_blank">http://www.detlef-bosau.de</a><br>
<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>