2009/7/30 irix <[email protected]>: > Hello Misc, > > It was a great number of disputes about shaping the incoming flow. This function is a solution to this dispute, > she realizes that may be implemented according to RFC.
Well, sort of. Assuming for a second that this was magically implemented exactly as you see it, it would be a way to shape inbound TCP streams. Nothing more. All other protocols would be completely untouched, so this would only function as an easily bypassed administrative limit. > And need it for example if you have a single ftp server and you want it to one of the ip on it to fill the data did not say > faster than 2Mbit, and all the others at full speed. (without tunning > ftpd) I assume you mean that you have an FTP server that permits upload, and you want to restrict upload from a given client IP to 2Mbit? This magic option would do the trick - for a single stream. What if they establish multiple streams? Unless you intended this to be an option restricting bandwidth aggregate across all states created by a given rule? > Or you have a narrow channel, for example in 128Kbit, and you are one of the SMTP server attempts to transmit e-mail to 200 megabytes, > with all your feed traffic taken from smtp server, but this feature you can ask the remote server to send you e-mail is slower to have > been free of the canal and you can open a http page. Alternatively, you can assign traffic outbound from your firewall to your mail server to a 64kbps wide queue and let the endpoints do what they're supposed to do, rather than fucking with tcp proxying and congestion scaling on the router. > In doing so, no shaping, and queuing is organized and not over the coming traffic no action is performed. > This option is apply is only for tcp traffic, according to rfc. Which RFC are you referring to? I assume you're talking about modifying the congestion control options. This sounds simple. It's not. As one potential user, I don't see myself ever using this functionality since it is a) limited to TCP, b) trivial for a hostile user to work around, c) provides no functionality not already possible with altq. >From what I've seen, it's also very unlikely for the developers to bother implementing something that they don't see an immediate use for or isn't thoroughly interesting to them. So far, your feature accomplishes nothing new and would probably require a serious amount of work.Without providing at least a solid explanation of what this gives you that altq does not, as well as a proof-of-concept code implementation, you're probably never going to see this. -HKS > > >> Why? What's the use case? >> >> -HKS > > > -- > Best regards, > irix mailto:[email protected]
