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

[jamal <hadi@cyberus.ca>]

On Mon, 10 Dec 2001, Henrik Nordstrom wrote:

> On Monday 10 December 2001 12.59, Martin Devera wrote:
>
> > jamal would probably say here that it is nonsence to delay/queue packet
> > which already arived to your box :)
>
> In a station trying to shape the traffic sent to him it does by limiting the
> waste of retransmits. egress queues does not help then as there is no egress
> where to queue the packet.
>
> To argue that it is nonsense to have a ingress queue for your own received
> packets is the same as to argue that it is nonsense to have a egress queue
> for routed packets. The packet dynamics are the same, only the application is
> slightly different.

No,
I would strongly suggest you run tests with dropped vs delayed TCP
packets. What you'll see is that even when you delay TCP packets retransmits
will happen. So this is a weak reason.
At least Martin and I agreed that the only reason youd need ingress is to
maintain the same TC semantics across ingress and egress;

As for the ipqueue folks there is a certain limitation with netlink at the
moment (hence the per-protocol family issue); so we might have to help
them queue packets in the kernel; pass only the headers to user space; let
them make a decision on the fate of the packet and some qdisc will act on
that decision. Now that is the hardway of doing things; the easy way is to
fix netlink.

Going back to hiding under paying work

cheers,
jamal




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