Paul Durrant writes: > 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 >
While drops are a necessity where hard resources are contended, I think we can open the debate when the said resources are managed/controlled. Peer's behavior will transmit as much as can fit in the smallest of the congestion window and received socket buffer size. In the absence of drops, the cwnd just grows but it would seems to me that, by tweaking the advertised receive window and assuming the round trip time is stable (?), we can control the incoming bandwidth. That BW should never exceed (advertised socket buffer / rtt). -r > -- > Paul Durrant > http://www.linkedin.com/in/pdurrant > _______________________________________________ > crossbow-discuss mailing list > [EMAIL PROTECTED] > http://opensolaris.org/mailman/listinfo/crossbow-discuss _______________________________________________ networking-discuss mailing list [email protected]
