[crossbow-discuss] Traffic shaping in Solaris

[Roch - PAE]

Paul Durrant writes:
 > On 2/19/07, Thomas Rampelberg <rampelbergt at digitar.com> 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
 > crossbow-discuss at opensolaris.org
 > http://opensolaris.org/mailman/listinfo/crossbow-discuss