Re: Packet queueing / scheduling ?

From: Kasper Dupont (kasperd_at_daimi.au.dk)
Date: 12/02/04


Date: Thu, 02 Dec 2004 11:46:46 +0100

Robert Redelmeier wrote:
>
> Actually, why drop the packet?

Of course whether that is good choice depends on the kind
of traffic. For some kinds of traffic low latency is more
important. In some cases you'd rather lose packets than
have them arrive late. For example if an ntp packet had
been delayed for 100ms you might as well drop it. Other
kinds of traffic is different. With TCP data packets a
FIFO queue is a good choice (as long as the packets are
from the same connection or at least have the same
priority). With acknowledges OTOH it is different. If
there are two acknowledges from the same connection, we
would rather discard the oldest to make sure the newest
get through a bit faster.

Of course we are in a position to make some of these
considerations, but it would be complicated, and such
decissions should really be made on the application
level.

As long as we are talking TCP the kernel can decide
reasonably well, but for UDP traffic the application
would be in a better position to tell the kernel if it
prefers a FIFO queue with resulting latency or just low
latency and more lost packets.

> Queue them all (send in prio
> order), but block returning from the socket send (userland,
> not TCP/IP stack. Or better yet, block that process on the
> next socket send unless it's a hi-prio until 1st low prio
> packet is sent, then wake-up.

You shouldn't always block the process. Of course if
the process performs a blocking write on a TCP socket,
it should be blocked. A non blocking write or a select
call should of course consider the descriptor not to
be ready for writing. Actually TCP sockets should work
like this already, we just need the TCP layer to take
whatever actions that are necesarry a bit faster than
it would do by waiting for an acknowledge for some
data which we have actually not send yet.

With UDP sockets it is a different matter. An appliction
wouldn't expect to block on sending a UDP packet. I'm
pretty sure blocking it would break a lot of stuff.
Unless we have very good reason to do otherwise, I think
the best way to handle congestion of UDP packets is by
dropping them.

>
> > How do we compute the required delay between sending two
> > packets? We have to look on the packet size, but they might
> > not have the same size, so which one is the right to look
> > at? I'd say the first packet. And I have two reasons why
> > I consider that the best idea.
>
> I don't understand. There are probably a few ways to dynamically
> detect congestion: variation in ACK delays, ping probes, others?

Yes, of course we can meassure roundtrip times. But we
won't see them until the queue have started building
up, and unless we ping a router very close to ourselves,
it is difficult to tell if the congestion is in the modem.
I'd rather avoid queueing in the modem. Meassuring ping
times would be useful for verifying if we have set the
upstream limit too high.

-- 
Kasper Dupont