[ih] When was Go Back N adopted by TCP

[Jack Haverty]

I thinkl Vint's right - the Internet is very complex.   it's very difficult
to draw conclusions about its behavior.

In addition to the variance in delay on those "wires", there's other
unpredictable influences on the behavior of the algorithms.

For example, random events that happen may effect A and B differently, even
though they are implemented identically.

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.

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.

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.

What we observed was that, after the dust settled, the two virtual circuits
would return to a stable flow.  The TCP connections remained intact.

But one flow was about twice the delay and half the throughput of the
other.   Very unfair.

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.

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!

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.

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.



/Jack Haverty



On Sun, May 18, 2014 at 3:26 PM, Vint Cerf <vint at google.com> wrote:

> 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.
>
> v
>
>
>
> On Sun, May 18, 2014 at 5:49 PM, Detlef Bosau <detlef.bosau at web.de> wrote:
>
>> Just to make my thoughts more clear.
>>
>> Let A,B,C end nodes, S some switch.
>>
>> A
>>    \
>>      S---------------------------------C
>>    /
>> B
>>
>> Assume one data flow from a to C, a competing one from B to C.
>>
>> I expect that it makes a difference, whether both TCPs employ the same
>> RTO scheme or, e.g. A, uses a more aggressive one that does earlier
>> retransmissions than its competitor. At least when we expect both TCPs
>> to use a fair share of resources, both TCPs should employ the same scheme.
>>
>> Do you agree?
>>
>> Detlef
>>
>> --
>> ------------------------------------------------------------------
>> 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/20140518/8ab51579/attachment.htm>