<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
span.EstiloDeEmail17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:612.0pt 792.0pt;
margin:70.85pt 3.0cm 70.85pt 3.0cm;}
div.Section1
{page:Section1;}
/* List Definitions */
@list l0
{mso-list-id:1666783625;
mso-list-type:hybrid;
mso-list-template-ids:-296211188 -1484375416 68550659 68550661 68550657 68550659 68550661 68550657 68550659 68550661;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:\F06E;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor=white lang=PT-BR link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Hi,<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Looking at the first ping command, it seems that the first
packet was lost (icmp_seq=0), as well as a series of packets after the 15th,
before David decided to ^C the ping execution. The 14 packets that went through
experienced a huge delay, really hard to explain.<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>So, my first guess on a “wrong thing” – no network
should hold a packet for long 8 or 9 seconds, and yet deliver it to somewhere.
No buffer should be big enough to hold packets so long . But I still
cannot imagine where the packets where sitting for such a long time.<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Looking at the traceroute: the measured times do not grow monotonously,
and show hi variance. I would say that the delay came from the first hop (172.26.248.2?).<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>A new ping, now targeted at 172.26.248.2, shows a decreasing
round trip delay – a buffer getting empty? – and still shows 1
packet loss.<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>It seems also that David is behind a NAT, since 172.26.248.2 is
a RFC1918 reserved address.<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>In any case, such long delays cannot be good for stable
functioning of TCP congestion control.<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>--a.l.g.<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:windowtext'>De:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:windowtext'> end2end-interest-bounces@postel.org
[mailto:end2end-interest-bounces@postel.org] <b>Em nome de </b>David P. Reed<br>
<b>Enviada em:</b> domingo, 6 de setembro de 2009 22:00<br>
<b>Para:</b> end2end-interest list<br>
<b>Assunto:</b> [e2e] What's wrong with this picture?<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-family:"Helvetica","sans-serif"'>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...<br>
<br>
(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.)<br>
<br>
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).<br>
<br>
$ ping lcs.mit.edu<br>
PING lcs.mit.edu (128.30.2.121) 56(84) bytes of data.<br>
64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=1 ttl=44 time=6330
ms<br>
64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=2 ttl=44 time=6005
ms<br>
64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=3 ttl=44 time=8509
ms<br>
64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=4 ttl=44 time=9310
ms<br>
64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=5 ttl=44 time=8586
ms<br>
64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=6 ttl=44 time=7765
ms<br>
64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=7 ttl=44 time=7168
ms<br>
64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=8 ttl=44
time=10261 ms<br>
64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=9 ttl=44 time=10624
ms<br>
64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=10 ttl=44
time=9625 ms<br>
64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=11 ttl=44
time=9725 ms<br>
64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=12 ttl=44
time=8725 ms<br>
64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=13 ttl=44
time=9306 ms<br>
64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=14 ttl=44
time=8306 ms<br>
^C<br>
--- lcs.mit.edu ping statistics ---<br>
24 packets transmitted, 14 received, 41% packet loss, time 33174ms<br>
rtt min/avg/max/mdev = 6005.237/8589.365/10624.776/1334.140 ms, pipe 11<br>
$ traceroute lcs.mit.edu<br>
traceroute to lcs.mit.edu (128.30.2.121), 30 hops max, 60 byte packets<br>
1 * * *<br>
2 172.26.248.2 (172.26.248.2) 693.585 ms 693.415
ms 712.282 ms<br>
3 * * *<br>
4 172.16.192.18 (172.16.192.18) 712.700 ms 1356.680
ms 1359.469 ms<br>
5 12.88.7.205 (12.88.7.205) 1361.306 ms 673.642
ms 673.541 ms<br>
6 cr84.cgcil.ip.att.net (12.122.152.134) 673.442 ms
673.371 ms 673.742 ms<br>
7 cr2.cgcil.ip.att.net (12.123.7.250) 655.126 ms
654.186 ms 554.690 ms<br>
8 * * ggr2.cgcil.ip.att.net (12.122.132.133) 912.385 ms<br>
9 192.205.33.210 (192.205.33.210) 909.925 ms 911.335
ms 911.204 ms<br>
10 ae-31-53.ebr1.Chicago1.Level3.net (4.68.101.94) 569.740 ms
569.605 ms 907.409 ms<br>
11 ae-1-5.bar1.Boston1.Level3.net (4.69.140.93) 369.680 ms
344.495 ms 345.252 ms<br>
12 ae-7-7.car1.Boston1.Level3.net (4.69.132.241) 355.645 ms
641.866 ms 641.367 ms<br>
13 MASSACHUSET.car1.Boston1.Level3.net (4.53.48.98) 636.598 ms
636.797 ms 635.755 ms<br>
14 B24-RTR-2-BACKBONE-2.MIT.EDU (18.168.1.23) 635.766 ms
634.794 ms 866.430 ms<br>
15 MITNET.TRANTOR.CSAIL.MIT.EDU (18.4.7.65) 758.305 ms
822.244 ms 821.202 ms<br>
16 trantor.kalgan.csail.mit.edu (128.30.0.246) 833.699 ms
1055.548 ms 1116.813 ms<br>
17 zermatt.csail.mit.edu (128.30.2.121) 1114.838 ms 539.951
ms 620.681 ms<br>
[david@whimsy ~]$ ping 172.26.248.2<br>
PING 172.26.248.2 (172.26.248.2) 56(84) bytes of data.<br>
64 bytes from 172.26.248.2: icmp_seq=1 ttl=254 time=1859 ms<br>
64 bytes from 172.26.248.2: icmp_seq=2 ttl=254 time=1363 ms<br>
64 bytes from 172.26.248.2: icmp_seq=3 ttl=254 time=1322 ms<br>
64 bytes from 172.26.248.2: icmp_seq=4 ttl=254 time=1657 ms<br>
64 bytes from 172.26.248.2: icmp_seq=5 ttl=254 time=1725 ms<br>
64 bytes from 172.26.248.2: icmp_seq=6 ttl=254 time=1740 ms<br>
64 bytes from 172.26.248.2: icmp_seq=7 ttl=254 time=1838 ms<br>
64 bytes from 172.26.248.2: icmp_seq=8 ttl=254 time=1738 ms<br>
64 bytes from 172.26.248.2: icmp_seq=9 ttl=254 time=1517 ms<br>
64 bytes from 172.26.248.2: icmp_seq=10 ttl=254 time=978 ms<br>
64 bytes from 172.26.248.2: icmp_seq=11 ttl=254 time=715 ms<br>
64 bytes from 172.26.248.2: icmp_seq=12 ttl=254 time=678 ms<br>
64 bytes from 172.26.248.2: icmp_seq=13 ttl=254 time=638 ms<br>
64 bytes from 172.26.248.2: icmp_seq=14 ttl=254 time=761 ms<br>
^C<br>
--- 172.26.248.2 ping statistics ---<br>
15 packets transmitted, 14 received, 6% packet loss, time 14322ms<br>
rtt min/avg/max/mdev = 638.651/1324.002/1859.725/455.200 ms, pipe 2<br>
$</span><o:p></o:p></p>
</div>
</body>
</html>