[e2e] What's wrong with this picture?

[Stjepan Gros]

On Sun, 2009-09-06 at 21:00 -0400, David P. Reed wrote:
> For those who have some idea of how TCP does congestion control, I ask
> "what's wrong with this picture?"  And perhaps those who know someone
> responsible at the Internet Access Provider involved, perhaps we could
> organize some consulting help...
> 
> (Hint: the problem relates to a question, "why are there no lost IP
> datagrams?", and a second hint is that the ping time this morning was
> about 193 milliseconds.)
> 
> Van Jacobsen, Scott Shenker, and Sally Floyd are not allowed to answer
> the question.  (they used to get funding from the IAP involved, but
> apparently that company does not listen to them).
> 
> $ ping lcs.mit.edu
> PING lcs.mit.edu (128.30.2.121) 56(84) bytes of data.
> 64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=1 ttl=44
> time=6330 ms
> 64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=2 ttl=44
> time=6005 ms
> 64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=3 ttl=44
> time=8509 ms
> 64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=4 ttl=44
> time=9310 ms
> 64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=5 ttl=44
> time=8586 ms
> 64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=6 ttl=44
> time=7765 ms
> 64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=7 ttl=44
> time=7168 ms
> 64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=8 ttl=44
> time=10261 ms
> 64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=9 ttl=44
> time=10624 ms
> 64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=10 ttl=44
> time=9625 ms
> 64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=11 ttl=44
> time=9725 ms
> 64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=12 ttl=44
> time=8725 ms
> 64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=13 ttl=44
> time=9306 ms
> 64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=14 ttl=44
> time=8306 ms
> ^C
> --- lcs.mit.edu ping statistics ---
> 24 packets transmitted, 14 received, 41% packet loss, time 33174ms
> rtt min/avg/max/mdev = 6005.237/8589.365/10624.776/1334.140 ms, pipe
> 11
> $ traceroute lcs.mit.edu
> traceroute to lcs.mit.edu (128.30.2.121), 30 hops max, 60 byte packets
>  1  * * *
>  2  172.26.248.2 (172.26.248.2)  693.585 ms  693.415 ms  712.282 ms
>  3  * * *
>  4  172.16.192.18 (172.16.192.18)  712.700 ms  1356.680 ms  1359.469
> ms
>  5  12.88.7.205 (12.88.7.205)  1361.306 ms  673.642 ms  673.541 ms
>  6  cr84.cgcil.ip.att.net (12.122.152.134)  673.442 ms  673.371 ms
> 673.742 ms
>  7  cr2.cgcil.ip.att.net (12.123.7.250)  655.126 ms  654.186 ms
> 554.690 ms
>  8  * * ggr2.cgcil.ip.att.net (12.122.132.133)  912.385 ms
>  9  192.205.33.210 (192.205.33.210)  909.925 ms  911.335 ms  911.204
> ms
> 10  ae-31-53.ebr1.Chicago1.Level3.net (4.68.101.94)  569.740 ms
> 569.605 ms  907.409 ms
> 11  ae-1-5.bar1.Boston1.Level3.net (4.69.140.93)  369.680 ms  344.495
> ms  345.252 ms
> 12  ae-7-7.car1.Boston1.Level3.net (4.69.132.241)  355.645 ms  641.866
> ms  641.367 ms
> 13  MASSACHUSET.car1.Boston1.Level3.net (4.53.48.98)  636.598 ms
> 636.797 ms  635.755 ms
> 14  B24-RTR-2-BACKBONE-2.MIT.EDU (18.168.1.23)  635.766 ms  634.794 ms
> 866.430 ms
> 15  MITNET.TRANTOR.CSAIL.MIT.EDU (18.4.7.65)  758.305 ms  822.244 ms
> 821.202 ms
> 16  trantor.kalgan.csail.mit.edu (128.30.0.246)  833.699 ms  1055.548
> ms  1116.813 ms
> 17  zermatt.csail.mit.edu (128.30.2.121)  1114.838 ms  539.951 ms
> 620.681 ms
> [david at whimsy ~]$ ping 172.26.248.2
> PING 172.26.248.2 (172.26.248.2) 56(84) bytes of data.
> 64 bytes from 172.26.248.2: icmp_seq=1 ttl=254 time=1859 ms
> 64 bytes from 172.26.248.2: icmp_seq=2 ttl=254 time=1363 ms
> 64 bytes from 172.26.248.2: icmp_seq=3 ttl=254 time=1322 ms
> 64 bytes from 172.26.248.2: icmp_seq=4 ttl=254 time=1657 ms
> 64 bytes from 172.26.248.2: icmp_seq=5 ttl=254 time=1725 ms
> 64 bytes from 172.26.248.2: icmp_seq=6 ttl=254 time=1740 ms
> 64 bytes from 172.26.248.2: icmp_seq=7 ttl=254 time=1838 ms
> 64 bytes from 172.26.248.2: icmp_seq=8 ttl=254 time=1738 ms
> 64 bytes from 172.26.248.2: icmp_seq=9 ttl=254 time=1517 ms
> 64 bytes from 172.26.248.2: icmp_seq=10 ttl=254 time=978 ms
> 64 bytes from 172.26.248.2: icmp_seq=11 ttl=254 time=715 ms
> 64 bytes from 172.26.248.2: icmp_seq=12 ttl=254 time=678 ms
> 64 bytes from 172.26.248.2: icmp_seq=13 ttl=254 time=638 ms
> 64 bytes from 172.26.248.2: icmp_seq=14 ttl=254 time=761 ms
> ^C
> --- 172.26.248.2 ping statistics ---
> 15 packets transmitted, 14 received, 6% packet loss, time 14322ms
> rtt min/avg/max/mdev = 638.651/1324.002/1859.725/455.200 ms, pipe 2
> $

My guess: the large RTT values cause the network path to have large
bandwidth delay product. TCP, in the absence of the packet loss, tries
to fill it, causing even more congestion?

SG