From mboxrd@z Thu Jan 1 00:00:00 1970 From: jamal Date: Mon, 10 Dec 2001 13:29:32 +0000 Subject: Re: [LARTC] Re: further CBQ/tc documentation ds9a.nl/lartc/manpages Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org 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/