All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Doug Graham" <dgraham@nortel.com>
To: linux-sctp@vger.kernel.org
Subject: Re: [PATCH] Fix piggybacked ACKs
Date: Tue, 04 Aug 2009 03:57:29 +0000	[thread overview]
Message-ID: <4A77B1A9.5060206@nortel.com> (raw)
In-Reply-To: <20090729160557.GC29475@nortel.com>


>>  
> Why can it never happen?  If I send a bunch of large messages with
> small last fragments, your modification will allow all messages
> to be sent, because it disables Nagle for large messages, right?
> If so, many small last fragments can be outstanding at any one
> time (one from each message).  Technically, this violates Nagle,
> which aims to prevent more than one small fragment from ever being
> outstanding, but I'm not sure that it really violates the spirit
> of what Nagle is trying to accomplish.
>
> Nagle is really meant to prevent the case of an application like
> telnet from sending a whole lot of small packets containing only 1
> or a few characters.  If the receive window is, say, 10000 bytes,
> Nagle would allow 10000 packets to be outstanding, all clogging
> up the network.

I meant to say that *without* Nagle, you'd be able to have 10000 packets
outstanding.  This is what Nagle is trying to prevent.

> But if the PMTU is, say, 1000 bytes and the user
> tries to send a bunch of 1001 byte messages, your method (if I
> understand it correctly) will allow 9 unacknowledged messages to
> be outstanding.  Those 9 messages will be split into 9 full-sized
> packets and 9 packets carrying only 1 byte of data.  18 outstanding
> packets isn't all that bad.  If the user were instead sending 1000
> byte messages, Nagle would have nothing to say about it, and you'd
> be able to have 10 packets outstanding.  The increase from 10 to
> 19 outstanding packets isn't likely to cause network collapse.
>
> --Doug
>
>

  parent reply	other threads:[~2009-08-04  3:57 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-29 16:05 [PATCH] Fix piggybacked ACKs Doug Graham
2009-07-30  6:48 ` Wei Yongjun
2009-07-30  9:51 ` Wei Yongjun
2009-07-30 16:49 ` Doug Graham
2009-07-30 17:05 ` Vlad Yasevich
2009-07-30 21:24 ` Vlad Yasevich
2009-07-30 23:40 ` Doug Graham
2009-07-31  0:53 ` Wei Yongjun
2009-07-31  1:17 ` Doug Graham
2009-07-31  1:43 ` Doug Graham
2009-07-31  4:21 ` Wei Yongjun
2009-07-31  7:30 ` Michael Tüxen
2009-07-31  7:34 ` Michael Tüxen
2009-07-31 12:59 ` Doug Graham
2009-07-31 13:11 ` Doug Graham
2009-07-31 13:39 ` Doug Graham
2009-07-31 14:18 ` Vlad Yasevich
2009-08-02  2:03 ` Doug Graham
2009-08-03  2:00 ` Wei Yongjun
2009-08-03  2:15 ` Wei Yongjun
2009-08-03  3:32 ` Wei Yongjun
2009-08-04  3:00 ` Doug Graham
2009-08-04  3:03 ` Wei Yongjun
2009-08-04  3:28 ` Doug Graham
2009-08-04  3:44 ` Doug Graham
2009-08-04  3:57 ` Doug Graham [this message]
2009-08-04 14:50 ` Vlad Yasevich
2009-08-04 17:05 ` Doug Graham
2009-08-04 17:14 ` Vlad Yasevich

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=4A77B1A9.5060206@nortel.com \
    --to=dgraham@nortel.com \
    --cc=linux-sctp@vger.kernel.org \
    /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.