All of lore.kernel.org
 help / color / mirror / Atom feed
From: "ツ Leandro Melo de Sales" <leandroal@gmail.com>
To: David Miller <davem@davemloft.net>
Cc: eric.dumazet@gmail.com, netdev@vger.kernel.org
Subject: Re: TCP packet size and delivery packet decisions
Date: Tue, 7 Sep 2010 03:02:22 -0300	[thread overview]
Message-ID: <AANLkTi=x4+YqyuOvpnUXd2PjMHifMPXEgEA=0=+wfPk7@mail.gmail.com> (raw)
In-Reply-To: <20100906.223010.173858342.davem@davemloft.net>

2010/9/7 David Miller <davem@davemloft.net>:
> From: ツ Leandro Melo de Sales <leandroal@gmail.com>
> Date: Tue, 7 Sep 2010 02:21:42 -0300
>
>> This is a embedded system implemented in a proprietary hardware that I
>> can send TCP commands to turn on/off relays. It will be very difficult
>> to find the reason for this behaviour. Since it needs to receive very
>> small data, probably it is not necessary to scaling window.
>
> The small 78 byte window is why the sending system is splitting up the
> writes into smaller pieces.
>
> I presume that the system advertises exactly a 78 byte window because
> this is how large the commands are.  But this is an extremely foolish
> and baroque thing to do, and it's why you are having problems.
>

David,
   Yes, 78 bytes is the size of each command. I have concluded the
same as you. In this case, to deal with this type of situation, how
about changing TCP implementation on Linux to send the whole packet
when it is too small such in this case or when TCP notice that there
is no change in the advertised rcwd or when advertised win is equal to
advertised MSS, since the receiver is saying "I can receive packets in
the same size of my cwd"?

  I'm sorry if I'm suggesting something that does not make sense, but
since receiver advertises that are able to receive packets in that
size which is equal to the congwin size, splitting the packet in this
case only [unnecessarily] increased the flow completion time or avoid
data to be delivered to the application as soon as possible since it
arrived splitted. As we could notice from the tcpdump report, TCP
implementation under Linux does not wait for any ACK of the first 48
bytes sent out, it just sent the other 30 bytes in a consecutive
delivery, which is the same as sending 78 bytes at once, since no
decision is taken to send or not the other last 30 bytes.

   Regardless this discussion, can you at least suggest any workaround
that I can do in the application layer to make TCP send the whole
packet at once? As I said, I tried to use TCP_CORK suggested by
Arnaldo (acme), but it does not work for me in this case.

Leandro.

  reply	other threads:[~2010-09-07  6:02 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <AANLkTi=_heUejVf-wmEcKd910gVtpD7Hr=cZ_cs2Q8n9@mail.gmail.com>
2010-09-07  4:20 ` TCP packet size and delivery packet decisions ツ Leandro Melo de Sales
2010-09-07  4:36   ` Eric Dumazet
2010-09-07  5:13     ` ツ Leandro Melo de Sales
2010-09-07  5:16       ` David Miller
2010-09-07  5:21         ` ツ Leandro Melo de Sales
2010-09-07  5:30           ` David Miller
2010-09-07  6:02             ` ツ Leandro Melo de Sales [this message]
2010-09-07  6:09               ` Eric Dumazet
2010-09-07  7:16                 ` ツ Leandro Melo de Sales
2010-09-07  7:32                   ` Eric Dumazet
2010-09-08 14:01                     ` ツ Leandro Melo de Sales
2010-09-07 11:39             ` Eric Dumazet
2010-09-07 12:15               ` Ilpo Järvinen
2010-09-08  3:18                 ` David Miller
2010-09-08 12:14                   ` Alexey Kuznetsov
2010-09-13  1:23                     ` David Miller
2010-09-14  9:37                       ` Alexey Kuznetsov
2010-09-15 17:29                         ` David Miller
2010-09-07 16:35               ` David Miller
2010-09-07 16:57               ` Rick Jones
2010-09-08 14:06               ` ツ Leandro Melo de Sales
2010-09-08 15:24                 ` David Miller
2010-09-08 16:03                   ` ツ Leandro Melo de Sales

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='AANLkTi=x4+YqyuOvpnUXd2PjMHifMPXEgEA=0=+wfPk7@mail.gmail.com' \
    --to=leandroal@gmail.com \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=netdev@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.