Hi Darren, We're looking for TCP MSS and window size modification primarily. Window size for talkers gone bad, and both for re-connecting talkers known to be bad. We'd like to have the hooks to implement/control this from an application accepting the connections.
Introducing delays to SYNs and ACKs it would seem to me would need to be used intelligently (and gently) in conjunction with a TCP window method to not cause an ACK flood. Imposing a bandwidth limit would be a nice higher-level way to achieve the same effect, and let the OS decide how to resize the TCP window and introduce delays accordingly. Queue restrictions and random packet loss get back into the traditional method using QoS, and don't achieve what we're looking for necessarily. Best Regards, Jason On 2/20/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Jason J. W. Williams wrote: > Hi Guys, > > Just thought I'd inject my two cents. Pro-actively adjusting the TCP > window and MSS size are much better way of doing traffic shaping. The > ack-floods you can get from hard dropping packets (a la QoS) can be > just of much of a headache as the bandwidth surge you're trying to > quell. > > Doing a Packeteer-style traffic shaping in the Solaris network stack > would absolutely rock! Completely unbiased here...I wouldn't happen to > have an app that would benefit or anything... ;-) What sort of capabilities are you looking for in shaping packets? - introducing random packet loss? - introducing fixed/random delays? - imposing queue restrictions (n slots, n kB, n MB) - imposing a bandwidth limit (n kb/s, n Mb/s) - changing the TCP MSS (can only be changed when the connection *starts) - changing the TCP window size - others? Darren
_______________________________________________ networking-discuss mailing list [email protected]
