Re: TCP packet size and delivery packet decisions

[Eric Dumazet <eric.dumazet@gmail.com>]

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