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
