> If you do have a blackout type line, careful tuning of TCP will allow you to
> automate recovery more efficiently than a user sitting there banging
> reconnect. The problem with this approach is right now TCP doesn't get any
> hints about the type of connection you may have. In the case discussed here, I
> believe the situation is as follows:
>
> User has a network connection that occasionally "blacks out", dropping all
> traffic to the adapter.
>
> So the entire device is blacked out. In that case, a flag in the device to
> indicate "I'm flaky and like to disappear every once in a while" could hint to
> TCP to change it's retransmission strategy.
Sort of. The setup is:
peer1 (2.2.13)
---10 MBit/s half-duplex(stable)---> router (Pentium 120/Linux 2.0.38 AFAIR)
---768 kBit/s(flaky)--> some cisco
---4-fast-and-stable-hops--> Ascend Max
---64 kBit/s(stable)--> peer2 (2.2.13).
flaky is: burst blackouts. I. e. some packets in a row are missing, then
the link is stable for like 15 seconds, than blacks out for 4 seconds
and so on.
Loss analysis by mtr (combined ping/traceroute). Network exhibits same
blackouts if I address my pings to the router rather than peer1.
This is for ping router from peer2:
94 packets transmitted, 67 packets received, 28% packet loss
round-trip min/avg/max = 70.184/127.923/460.765 ms
The "some cisco" has these stats:
16 packets transmitted, 16 packets received, 0% packet loss
round-trip min/avg/max = 59.225/80.703/140.998 ms
> If you have a single connection that is dying somewhere beyond your local
> device,
This is the setup.
> this approach doesn't work, unless you allow routes to specify hints
> as well. However, in this case, you can't be guaranteed that you
> aren't suffering from congestion somewhere before your "blackout"
> point, so congestion avoidance would be quite complicated.
Yup. Still, the net we're talking about IS egoistic (people move CDs
through the net rather than carry them over a couple of 10 metres), and
it has about 70 Win95, Win98, WinNT, Linux hosts on the 768 kBit/s
link.
I'm not quite sure (haven't digged that deep), it might be that the 768
kBit/s actually is an asymmetric DSL (assumedly Deutsche Telekom 768/128
kBit/s) which MIGHT confuse the congestion avoidance as well.
-- Matthias AndreeHi! I'm the infamous .signature virus! Copy me into your ~/.signature to help me spread!
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/