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: <1283839769.2585.572.camel@edumazet-laptop>
Date:	Tue, 07 Sep 2010 08:09:29 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	ツ Leandro Melo de Sales <leandroal@...il.com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: TCP packet size and delivery packet decisions

Le mardi 07 septembre 2010 à 03:02 -0300, ツ Leandro Melo de Sales a
écrit :
> >
> 
> 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.
> 

Is it a critical problem for you ?

If you give us at least some minutes or hours or even days to think
about this corner case, I am sure we can find a solution :)

They are two factors here : MSS=78 and WIN=78

Thanks


--
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