[LARTC] Re: further CBQ/tc documentation ds9a.nl/lartc/manpages

[jamal <hadi@cyberus.ca>]

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


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/lartc/