Re: Simulating smaller MTU? ie sending small packets.
- From: "Tassilo v. Parseval" <tassilo.von.parseval@xxxxxxxxxxxxxx>
- Date: Wed, 17 Aug 2005 12:05:15 +0200
Also sprach Ed W:
>> This is probably a moot venture. The smaller the packets are, the lower
>> the overall throughput is going to be. This is due to the fact that TCP
>> packet have to be acknowledged.
>
> Be careful with your generalisation. The point of my experiment is to
> test an unreliable (and very slow) satellite network to determine
> whether faster speed would be achieved using smaller MTU due to less
> retranmissions. 1500 bytes represents up to 7 seconds of transmission
> time...
Ah, there we are! TCP design was heavily based on the assumption of
using wires on the physical layer (which means: the medium is fairly
reliable). I made the same assumption. :-)
TCP over a wireless link is a completely different story. The current
design still works but it can be horrendously inefficient, especially
congestion control.
>> In order to do your measurements, you should probably adjust parameters
>> on the receiving side. If you want smaller packets, try to set the
>> window size (TCP_WINDOW_CLAMP, I think). TCP_MAX_SEG also needs to be
>> set there as the MSS is announced by the receiver during the
>> three-way-handshake when the connection is established.
>
> I'm not sure I can see how window size affects things, but it's
> interesting to see that I can influence it on a per connection basis?
Yes, per connection. The window size is a parameter sent with each ACK
message and it refers to the currently remaining size of the receiving
buffer. This is normally handled by the TCP stack. It is not a global
parameter you set once and then it remains there. But from the
description in tcp(7) I assume that TCP_WINDOW_CLAMP is an upper bound
and no sent packet may ever exceed it.
> I'm trying to change TCP_MAX_SEG and the docs imply it can be changed
> once the connection is established, but at least using perl this doesn't
> appear to work.
TCP_MAXSEG actually. To what value did you set it? If it exceeds the MTU
of your interface, the value is ignored. Also, the minimum size is, I
think, 556 which is a TCP requirement.
> If I change it on a listening socket then I observe that the subsequent
> tcp handshake uses the original max values, but that TCP then uses the
> smaller values for sending data (ie it does what I expect). It would
> just be useful to be able to change the MSS while the connection is
> operating
As far as I know this is not in the specifications of TCP. The segment
size is agreed on during connection establishment (actually, both sides
may use different values for the MSS).
> It might for example be useful to change the MSS if we observe more
> corrupted tcp packets arriving, or other similar algorithm.
The only way to do that is to shutdown the connection and establish a
new one with the updated values for the MSS.
> Also, is it possible to observe how full the network buffers are?
> getsockopt(xxx)? Again, it might be useful to observe this value in the
> situation above and slow down sending when the buffers are filling up
> (for example with these huge latencies I might want to have more control
> over the amount of outstanding data)
With a packet-sniffer, you certainly can. You find it in the window size
field of the TCP header that is sent back as acknowledgement from the
receiver. But as I said earlier, this is a dynamic value so I don't
think you can find that value on a per-socket basis. There is TCP_INFO
that returns some values. But the structure returned seems to have no
information on the last state of the receiver's window.
Since you are trying to optimize a TCP connection over a wireless link,
are you sure at all that reducing the packet size is a good idea? The
problem with wireless links is their lack of reliability (and latency).
When data get through corrupted (or not at all) a approach is to send
again immediately in the hope that it gets through this time. Also,
making packages smaller does not necessarily make the transmission more
reliable. Wireless is really just send-and-pray.
However, if you have problems with the buffer of the receiver filling up
too quickly, wouldn't that mean that the data got through beautifully?
If the receiver constantly has full buffers, it means the link is in
fact quite reliable and thus making it look similar to a wired link. In
this case you can just rely on the default behaviour of your TCP stacks
as they work well for reliable links.
Tassilo
--
use bigint;
$n=71423350343770280161397026330337371139054411854220053437565440;
$m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200);
.
- Follow-Ups:
- References:
- Simulating smaller MTU? ie sending small packets.
- From: Ed W
- Re: Simulating smaller MTU? ie sending small packets.
- From: Tassilo v. Parseval
- Re: Simulating smaller MTU? ie sending small packets.
- From: Ed W
- Simulating smaller MTU? ie sending small packets.
- Prev by Date: How to write at specific loaction in a file
- Next by Date: Extraction of bits using unpack
- Previous by thread: Re: Simulating smaller MTU? ie sending small packets.
- Next by thread: Re: Simulating smaller MTU? ie sending small packets.
- Index(es):
Relevant Pages
|
