[e2e] What's wrong with this picture?

[Dominik Kaspar]

If there is a lot of congestion, ICMP packets should get dropped at
intermediate routers. Maybe some "smart" router takes the term "best
effort" too seriously and tries not to lose a single packet by
buffering everything on secondary storage...?

Dominik

On Tue, Sep 8, 2009 at 6:29 PM, Loki
Jorgenson<ljorgenson at apparentnetworks.com> wrote:
> Satellite link?  Probably geostationary from the looks of it (around
> 600ms RTT) - possibly more than one bounce in certain cases.  The
> buffers on satellite link modems can be quite large to boot.  Little to
> no loss is not surprising given their retransmit capabilities.
> Apparently part of a fail-over if it returned to terrestrial values in
> the morning.
>
> That accounts for anything up to about 2 seconds.  The really high 5-10
> second RTTs still seem pretty extreme even for satellites....
>
> Loki Jorgenson
> Apparent Networks
> t   604 433 2333 ext 105
> m   604 250-4642
>
> -----Original Message-----
>
> Message: 1
> Date: Sun, 06 Sep 2009 21:00:16 -0400
> From: "David P. Reed" <dpreed at reed.com>
> Subject: [e2e] What's wrong with this picture?
> To: end2end-interest list <end2end-interest at postel.org>
> Message-ID: <4AA45B20.6030705 at reed.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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.)
>
> $ 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
>
>
>