netdev
[Top] [All Lists]

Re: Slow TCP connection between linux and wince

To: amlaukka@xxxxxxxxxxxxxx (Aki M Laukkanen)
Subject: Re: Slow TCP connection between linux and wince
From: kuznet@xxxxxxxxxxxxx
Date: Wed, 7 Jun 2000 20:08:27 +0400 (MSK DST)
Cc: netdev@xxxxxxxxxxx, iwtcp@xxxxxxxxxxxxxx
In-reply-to: <Pine.OSF.4.20.0006062321120.29607-100000@sirppi.helsinki.fi> from "Aki M Laukkanen" at Jun 7, 0 02:05:00 pm
Sender: owner-netdev@xxxxxxxxxxx
Hello!

> To me it seems this would be trying to fix the symptom rather than the
> cause. There seems to be a certain assumption in place here that the default
> socket buffer of 65536 is good for all connections regardless of MTU. This 
> is only true if we don't do meta-data accounting in {wmem|rmem}_alloc. 

It is really OK. 65535 is very big sndbuf, when you talk to
sane OSes (i.e. windows 8)). But we cannot talk to Linuxes 8),
because they used to advertise non realistic windows.

Also, the fact that truesize exceeds mss not more than twice
is really crucial. When it is not true, linux tcp used to fail
miserably. This phenomenon is visible only on high rtt networks
with small losses, though.

> I don't think this a highly non-standard situation. Even if we ignore
> slow wireless links (e.g. GSM data), to some extent every modem-link
> exhibits this behaviour. Have you read draft-ietf-pilc-slow-03.txt or
> rfc2757.txt? Good read for a little perspective to the problem space.

You missed the point. Network should have large _packet_ power_
i.e. (rtt*bandwidth)/mss to hit this problem.  This situation never occured
in real life earlier. I have no idea, how you reached cwnd of 192. 8)


> the point. I think I can argue that the receiver should never advertise a
> window bigger than it is prepared to receive.

Of course. The question is how to make this. I proposed one solution.


> Does this mean the changes described here?

Yes. It has been made in net-xxyyzz, but the heuristics
used there seems not to work very well in your situation.
Seems, it will not open enough of window. 
You may check this using net-000601.


>                                        Doing it the other way
> (not killing the whole ofo-queue) will still cause further packet loss.

I do not want to prune at all.

Alexey

<Prev in Thread] Current Thread [Next in Thread>