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. > It is a good model but may be insufficient given Linux TCs > capabilities. Email me when unsure. Will do. > 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. > - 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 :-) 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. 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. 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? > - 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? From linux/net/sched/sch_tbf.c: toks = PSCHED_TDIFF_SAFE(now, q->t_c, q->buffer, 0); if (q->P_tab) { ptoks = toks + q->ptokens; if (ptoks > (long)q->mtu) ptoks = q->mtu; ptoks -= L2T_P(q, skb->len); } Sure looks like the mtu, measured in tokens, is the size of the second bucket? > More later if dont get distracted. Thanks. -- http://www.PowerDNS.com Versatile DNS Software & Services Trilab The Technology People Netherlabs BV / Rent-a-Nerd.nl - Nerd Available - 'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet
