On 2/19/07, Thomas Rampelberg <[EMAIL PROTECTED]> wrote:
Pure packet dropping or queuing wouldn't work in this instance, I believe, because the bandwidth would get reclaimed to some level but you'd loose a lot still and in the case of a false positive, the service would be completely unusable based on how many dropped packets would be occurring. Therefore, after looking through my networking books again here, I believe the solution to this problem is fixed by reaching down into the guts of TCP itself. Because TCP has to handle limited connections all the time, the protocol has some allowances for finding the optimal bandwidth of a connection a reshaping the incoming packets so that it's filled correctly. It does this through the TCP window, the MSS header option and TCP congestion avoidance. From everything I've been able to find about the network stack in S10, there aren't any hooks for me to be able to edit these settings on the fly at a per-connection level. So, the first obvious question, is this possible at all? And/or has someone already done something like this?
But that's the entire point of packet dropping. If you drop packets from a TCP connection, preferably not using tail-drop then the sender should start to close down the window due to the re-transmissions that start to occur. The window will close down until the re-transmission rate drops (i.e. the receiver stops dropping packets because the b/w has fallen sufficiently low). Paul -- Paul Durrant http://www.linkedin.com/in/pdurrant _______________________________________________ networking-discuss mailing list [email protected]
