Date:	Wed, 8 Sep 2010 11:01:50 -0300
From:	ツ Leandro Melo de Sales <leandroal@...il.com>
To:	Eric Dumazet <eric.dumazet@...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

On Tue, Sep 7, 2010 at 4:32 AM, Eric Dumazet <eric.dumazet@...il.com> wrote:
>
> 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 ?
>
>
>

Very nice... piggybacking... ;) But this is not the case, I need to
send more packets, it is not just one...

Kernel version: 2.6.32, but I have run this in the later versions too...

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

Powered by blists - more mailing lists