:Matt: make up your mind.
:
:Either:
:
:1) The server is sending too many packets
:
:OR
:
:2) The server is NOT sending too many packets
:
:The correct way to deal with #1 is to negotiate a smaller window size
:so that "too many packets are not sent".
:
:Actually, the PSC rate-halving algorithm would probably fix this
:right up...
:
:-- Terry
Terry, I don't think you quite understand the problem. From the server's
point of view NOTHING IS WRONG. Any non-USB-ethernet client would have
no problem whatsoever with the large number of small packets that the
server is sending, nor can the server just arbitrarily decide that 8
packets is too much, because doing so screws up bandwidth over long-haul
links. The server can not arbitrarily limit its window size because
the problem only occurs with small packets. So how is the server
supposed to figure out the difference between between normal packet
loss and packet loss due to the client having a USB adapter and not
being able to handle lots of tiny packets?
New-Reno might be able to help but it would have to be hacked up a bit
to send a double ack to the server to force the server to reduce its
congestion window. New-Reno is a mess and I am not volunteering to
hack it up more.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
