On Sat, 8 Dec 2001, bert hubert wrote: > On Sat, Dec 08, 2001 at 03:43:05PM -0500, jamal wrote: > > > For starters, i think you need a defintions sections. Look at: > > http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-06.txt > > > > (eg what is a shaper etc and how trhings are placed together). At least > > that will ensure that you dont sday things like "Prio cant shape". > > I see that now :-) The right wording appears to be that a Prio is a > Work-conserving non-policing shaper. > work conserving is right. non-policing is wrong. Policing is related to filters. Shaping is related to schedulers. Prio is a scheduler. Shaping results in non-work conserving schemes. You can attacha TBF which shaping inside a Prio qdisc. That would add non-workconserving-ness to it. > > It is a good model but may be insufficient given Linux TCs > > capabilities. Email me when unsure. > > Will do. > Basically dont take it for the gospel. > > Some other things: > > - In your comment "Do not confuse this classless simple qdisc with the > > classful PRIO one!". This is misleading: > > the default 3 band FIFO queue is conceptually the same as the > > default prio qdisc (the priomaps are identical). 3 bands; same > > prioritization schemes. > > New wording: > Do not confuse this classless simple qdisc with the classful PRIO one! > Although they have a lot in common, the PRIO queue can contain different > classes, whereas pfifo_fast has hardcoded FIFO bands. I am not sure if i like the wording: A class is the result of a class-ification. Both pfifo_fast and PRIO have builtin class-ifiers. Essentially if you treated default prio qdisc and pfifo_fast as black boxes, there is _no_ difference. Dont look at the code, think larger picture. > > > > - You really need to fix ingress section: > > it works for both forwarding and packets coming in to local sockets. > > More importantly, It takes advantages of _all_ filter schemes > > available for TC as well as the policing functionality (which sadly seemed > > to have been replicated by someone in netfilter, wrongly if i may add ;->). > > Yeah, it's broken, it counts packets, not bytes. It does praise Alexey > though :-) > I think the main problem i found with it is that it used a single token bucket. > Ok, new ingress description: > > The ingress qdisc is a strange animal in that is not used to send packets > out to the network adaptor. Instead, it allows you to apply tc filters to > packets coming in over the interface, regardless of whether they have a > local destination or are to be forwarded. > > As the tc filters contain a full Token Bucket Filter implementation, and are > also able to match on the kernel flow estimator, there is a lot of > functionality available. This effectively allows you to police incoming > traffic, before it even enters the IP stack. > You can have two qdiscs per device, ingress and egress Please look at the router model i described earlier. The two hooks are very clearly described there. Ingress qdisc is work conserving only by design; whereas egress qdiscs could be non-work conserving. > Parameters & usage > > The ingress qdisc itself does not require any parameters. It differs from > other qdiscs in that it does not occupy the root of a device. Attach it like > this: > > # tc qdisc add dev eth0 ingress > > This allows you to have other, sending, qdiscs on your device besides the > ingress qdisc. > Again, look at the definitiions of eg/ingress. You need to have this diagram drawn: http://www.davin.ottawa.on.ca/ols/img9.htm in your document. > For a contrived example how the ingress qdisc could be used, see the > Cookbook. > > > - You keep saying "reodering" -- dont know what that means. Reordering is > > generally considered a Bad Thing(tm). > > Well. That is what it comes down to - it reorders packets. It does not > reorder them within the same tcp/ip session, or at least, we hope so. In > other words, it delays certain packets while it doesn't delay others. How > would you suggest wording this? Look at the model draft then lets talk again. > > > - your description of "MTU" > > Not very good description: > > This is just what it literally says; maximum transmit unit; > > A packet larger than this will be dropped. Default is 2K. For ethernet, > > MTUs of 1500 bytes, this is fine; however, you should put a cautionary > > statement here in regards to people having MTUs smaller than 2K (example > > the lo device); they might find that all their packets greater than 2K > > being dropped. > > Sure? 100% sure. Try a little experiment then look at the code again. cheers, jamal
