[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "real" ingres implementation



> There's one crucial difference, and that's lack of a natural and easily
> accessible backpressure mechanism at ingress. At egress, we have two
> cases:
> 
>  - the bottleneck is right at the interface, enforced by hardware
>    (this includes bastard cases like ATM)
>  - the bottleneck is somewhere else, and we have to rate limit by
>    software
> 
> Only rate limiting can be easily applied to ingress. The "local

I agree. I is also ONLY case I wanted to implement ingres queuing.

> Furthermore, for rate limiting, you have basically two choices: to
> drop or to delay. You can drop also at ingress. Now why would you
> want to delay ? If it's something local, you may as well put the

Why to delay ? See later in your X-Y-Z example.

> are some valid considerations for shaping at ingress:
>  - cases where classification does not allow to identify the "right"
>    object (e.g. you want to shape a flow coming via interface X and
>    leaving via interfaces Y and Z based on the rate at X)

Bingo. All cases I found are variation on this scheme. Ingres
queuing IS IMHO nonsence (as I said earlier) but it is currently
simplest way how to implement scenario above.

> What they usually have in common is that traffic control really
> should have been applied at some other point in the network, e.g. in
> the first case, the upstream node on X should have done the shaping.

Yes but it is not case always due to administrative boundaries.
I have such case in my company - the X's upstream node is not in
my administrative domain (it is another company) and they are
not smart enough to do it.
 
> 2) is difficult. Maybe a combination of a TAT algorithm at ingress and
> an EDF scheduler at egress could help. (TAT = Theoretical Arrival Time,
> i.e. the time when the packet should have arrived (or, in this case,
> will have been sent); EDF = Earliest Deadline First.)

I'm afraid that implementing non-work-conserving behaviour with
EDF would need high precise timers.

> That's why
>  - shaping is best avoided (for TCP, drop/ECN instead)

There is one problem. When you drop only you can't assure fairness
between flows. With queuing with shallow queue in SFQ you can do it.

> I think a "multipoint" meter should be fairly straightforward to
> implement. EDF is harder. I have some code for a reasonably efficient

What about this idea. Qdisc will not be attached to particular
iface but rather all qdisc are in global namespace.
When packet is recieved (from local or input iface) and routed
then it is queued into all qdisc which wants it (filter decision).
Each qdisc can during its initialization subscribe itself to
some output interfaces (so that its dequeue will be called by
those interfaces when tx is done).
Benefits:
- no need for specific ingres: every qdisc acts like both
  ingres & egres because it gets all packets just after routing
  (which is probably fast) and can output to whatever iface
  it wants
- elegant solution for X-Y-Z problem: CBQ can attach each class
  to different output interface - it is exactly what is missing
  in current cbq in compare with Floyd's paper
- elegant solution for TEQL - no need for "special" net devices,
  it can all packets destined either for eth0,1,2,3 distribute
  among them.
- simple to incorporate to current sources
- simple to understand
Problems:
- compatibility

What do you think ? It is only idea I got just
now and I probably missed something but ...
devik