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: <1283844761.2338.32.camel@edumazet-laptop>
Date:	Tue, 07 Sep 2010 09:32:41 +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,
	Thiago Luiz <thiagolcpeixoto@...il.com>
Subject: Re: TCP packet size and delivery packet decisions

Le mardi 07 septembre 2010 à 04:16 -0300, ツ Leandro Melo de Sales a
écrit :

> My short answer is: this is not a critical problem for me, at all. I
> just thought that this could be easily fixed by finding the source of
> the problem, as David and I shared it is due to small and fixed cwd
> advertised by the receiver.
> 
> But...  This just make me think about why it works under windows, but
> not under linux. When I begin to think about the relation between Win
> and MSS, in my point of view it is feasible to think like I said: if
> the receiver is telling me that it is able to receive a packet that is
> in the same size of the cwd and cwd is sufficiently small in respect
> to congestion control mechanism and MTU size, why postpone the flow
> completion time if I can do this at once, ... avoid make two
> consecutive TCP-PSH without any sending decision between them? For our
> discussion MSS == Win, while they are very small if compared to MTU,
> almost 20 times, at least in ethernet. I know that "very", "small",
> "big", "tall", "short" etc are very vague works, and everything will
> depend on the point of view, but maybe we can consider Win a very
> small size (at lease when it is equal to MSS) when TCP is in the Slow
> Start phase until ssthresh, don't know...
> 
>     From one perspective I agree with David that the receiver device
> of my case provided a kind of foolish and/or baroque implementation,
> but in another perspective they where very smart to announce MSS ==
> cwd, this way they avoiding sender to send more than it (receiver) can
> handle, does not use too much resource since it does not increase the
> cwd, in addition to telling to the sender: "send me your complete
> 'sk_write_queue' at once (talking about Linux TCP implementation)".
> But Linux did not, instead it sent two consecutive packets without any
> decision taken between them, why? In this case, how much resource we
> spend when we allocate a new packet and add it in the double-linked
> queue? how much computation we wasting when we have to process one
> more packet (in this case for each tcp.send())? Well, if this is not
> the case here or if wasting resources is computational cheaper than
> make some checks and send the packet at once, let's try another
> approach...
> 
>    Well, I don't know if what I mentioned above are real arguments to
> promote a change in the TCP implementation, just want to solve my
> problem, at the same time I have decided to share with you guys my
> problem, since maybe it can be a problem faced by someone else when
> using Linux, or already occurred in the past.
> 
>    Finally, one other (at least for my project) consideration is that
> I wouldn't like to deploy my application only under windows (since
> there my app works) and tell to my customer: well, we have done a
> multi-platform solution, but due to **this** issue we won't be able to
> deploy the system under linux because it simply does not work (at
> least considering all tests using alternatives and workaround that I
> have mentioned in my previous e-mail).


Really this has nothing to do with congestion.

We send _one_ packet, and this packet has not the optimum size.

This can be fixed, with a 100% probability :)

Quite frankly, if your application depends on _one_ packet being sent
instead of two, you can do even better under linux, avoiding the third
packet (pure ACK) of the tcp session :=)

192.168.0.34    192.168.0.70    [SYN] Seq=0 Win=5840 Len=0 MSS=1460
192.168.0.70    192.168.0.34    [SYN, ACK] Seq=0 Ack=1 Win=78 Len=0 MSS=78
192.168.0.34    192.168.0.70    [PSH, ACK] Seq=1 Ack=1 Win=5840 Len=78

Nice isnt it ?

BTW, what is the version of linux kernel you use ?



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