All of lore.kernel.org
 help / color / mirror / Atom feed
From: Neil Spring <nspring@cs.washington.edu>
To: Jamie Lokier <lk@tantalophile.demon.co.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Excessive TCP retransmits over lossless, high latency link
Date: Sat, 1 Sep 2001 12:07:02 -0700	[thread overview]
Message-ID: <20010901120702.A30845@cs.washington.edu> (raw)
In-Reply-To: <20010901181729.A2204@thefinal.cern.ch> <20010901194141.44617@colin.muc.de> <20010901192242.A2714@thefinal.cern.ch>
In-Reply-To: <20010901192242.A2714@thefinal.cern.ch>

> I don't see what is broken about the remote end in this case.

The remote end is probably not broken, at least in this
case.  This looks like an artifact of a disgustingly
large queue, and a very slow link.  When the time to
transmit tiny packets in the initial handshake is much
smaller than the time to transmit a full size frame,
retransmission timers can get confused.  A complete trace
would settle this.

I strongly recommend setting the mtu of your ppp0 interface
down to 576 (or smaller) to reduce the time it takes to
transfer a full size frame, decrease the likelihood that
frames suffer corruption, and allow acknowledgements more
often than every 5 seconds.  This is a setting in your ppp
configuration, don't do this using ifconfig. 

Don't take my word for it, see RFC1144, section 5.2: a
good MTU is chosen so that a full size frame is transferred
in 200ms.

RFC1144, written by Van Jacobson:

   To illustrate, note that for a 9600 bps line with
   header compression there is essentially no benefit
   in increasing the MTU beyond 200 bytes: If the MTU is
   increased to 576, the average delay increases by 188%
   while throughput only improves by 3% (from 96 to 99%).

Besides, if you do what you propose (not ack old data with the 
next byte expected) you risk stalling the connection entirely.

-neil


  reply	other threads:[~2001-09-01 19:07 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-01 17:17 Excessive TCP retransmits over lossless, high latency link Jamie Lokier
2001-09-01 17:41 ` Andi Kleen
2001-09-01 18:12   ` kuznet
2001-09-01 18:22   ` Jamie Lokier
2001-09-01 19:07     ` Neil Spring [this message]
2001-09-01 18:08 ` kuznet
2001-09-01 18:55   ` Jamie Lokier
2001-09-01 19:20     ` kuznet
2001-09-01 20:02       ` Jamie Lokier
2001-09-01 20:39         ` Lukas Beeler
2001-09-03 17:14         ` kuznet
2001-09-03 17:57           ` Jamie Lokier
2001-09-03 18:07             ` kuznet
2001-09-01 19:59 ` Alan Cox
     [not found] <20010901195532.B2714@thefinal.cern.ch.suse.lists.linux.kernel>
     [not found] ` <200109011920.XAA20031@ms2.inr.ac.ru.suse.lists.linux.kernel>
     [not found]   ` <20010901210212.A3361@thefinal.cern.ch.suse.lists.linux.kernel>
     [not found]     ` <20010901223918.A4053@mail.projectdream.org.suse.lists.linux.kernel>
2001-09-01 21:45       ` Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010901120702.A30845@cs.washington.edu \
    --to=nspring@cs.washington.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lk@tantalophile.demon.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.