netdev - Re: TCP packet size and delivery packet decisions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTi=x4+YqyuOvpnUXd2PjMHifMPXEgEA=0=+wfPk7@mail.gmail.com>
Date:	Tue, 7 Sep 2010 03:02:22 -0300
From:	ツ Leandro Melo de Sales <leandroal@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	eric.dumazet@...il.com, netdev@...r.kernel.org
Subject: Re: TCP packet size and delivery packet decisions

2010/9/7 David Miller <davem@...emloft.net>:
> From: ツ Leandro Melo de Sales <leandroal@...il.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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html