On Mon, Jan 23, 2006 at 04:32:16PM +0200, Shachar Shemesh wrote: > No, this is plain wrong. TCP employs a very powerful congestion control. > When it notices that the connection exceeded its allocated bandwidth, it > will lower the transmission rate, thus eliminating the need to drop > further packets. This will also clear the ISP's buffers.
Allocated bandwidth implies that something or someone has set that allocation. Where is this allocation set and this mechanism occur? Is it present in all implementations? I assume you mean that Linux's implementation of TCP includes it. Where does it apply? If you apply it at the tunnel level then all packets, irrespective of what they are and where they go are effected. If you do it at the end of the tunnel, after PPTP or whatever tunneling mechanism you use, then the packets have to get here first. > Increasing latency is bad. Not only does it not solve the problem (TCP > has very good mechanisms for handling high latency connections without > losing bandwidth), but it also makes the user experience seem bad. That's my whole point, IMHO that's what you want to do, but be selective about it. No one really cares if the latency on a bittorrent packet is 100ms except if the download rate is high enough to matter. But slow down a VoIP or on demand video packet 100ms and it causes jitter and all sorts of bad things. > It MAY be possible to achieve this effect by manipulating the outgoing > packets window. This is not a trivial manipulation to perform, however. > The TCP window field's intepretation is dependent on a TCP option called > "Window Scale". This option is only attached to the session initiation > packets (the SYN and SYN+ACK), which means very stateful tracking of the > connection. Not impossible. I have implemented such a thing when I wrote > Check Point's "TCP sequence verifier" feature, but not pleasent either. Sounds like it could be more easily incoperated in a pptp client instead of in the kernel. At that level you still know what each packet is and where it is going. Another trick would be to lower the mtu for "bad" packets, but that might be a lot more difficult. > Sure they had reason to resend them. These packets were over the > available bandwidth. But that decision was made arbitrarily by you, after you had received them. You asked for them, they sent them and sent them again. > I don't think it causes any extra retransmission at all. The way TCP > detects the line's available bandwidth is by pushing the limit and > tracking lost packets. This means it will lose, approximately, the same > percentage of the packets no matter what the actual bandwidth is. I > don't see any difference between causing the drop at your end of the > connection and having the drop happen at the ISP's end due to buffer > full conditions, which is something that happens all the time anyways. You are confusing tunneled and non tunneled connections. A tunneled connection always sends the same type of packets to the same destination. You want to keep the queue at each end of the tunnel small and the tunnel congestion low. UDP connections will get dropped packets due to buffer full, TCP should not. In the end if the packets are dropped, then the receiver will wait for them and after a time out, ask for them to be retransmitted. That's the problem, the wait time needs to me a few miliseconds, not a TCP timeout. > > just > >to keep you stats looking good, without actually doing any good. > > > > > Have you tried? Yes, with disasterous results. Geoff. -- Geoffrey S. Mendelson, Jerusalem, Israel [EMAIL PROTECTED] N3OWJ/4X1GM IL Voice: (07)-7424-1667 IL Fax: 972-2-648-1443 U.S. Voice: 1-215-821-1838 The trouble with being a futurist is that when people get around to believing you, it's too late. We lost. Google 2,000,000:Hams 0. ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
