Re: Packet queueing / scheduling ?

From: Kasper Dupont (
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

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

Relevant Pages

  • alt.2600 FAQ Revision .014 (2/4)
    ... One type of firewall is the packet filtering firewall. ... Dropping packets instead of rejecting them greatly increases the time required to scan your network. ... Port scanning UDP ports is much slower than port scanning TCP ports. ... Chartreuse Use the electricity from your phone line Cheese Connect two phones to create a diverter Chrome Manipulate Traffic Signals by Remote Control ...
  • Re: TCP Blocking sockets
    ... a blocking socket does *not* block until the other side receives ... >> I guess if I don't want to flood a tcp link with data, ... With TCP/IP the receiving system will wait for the packet to ...
  • Re: C# Raw Socket Issues starting TCP Connections
    ... the TCP stack has no information about what you are doing ... of IP packet and send it along with the data, you can build a SYN packet ... and send it to the TCP server program which is actively listening. ... > read incomming data if I use IOControl and set the socket SIO_RCVALL. ...
  • Re: TCP/IP Services SSH and new router difficulties
    ... (TCP vs UDP, role of routers, significance of MTU, etc). ... the lost packet and what followed it is retransmitted. ... I'd start by looking to see whether you have a Path MTU Discovery ... VMS TCP/IP SSH ports budge? ...
  • Re: jailed "system" needs IPV4 access
    ... see if the ACK flag is set on a tcp packet. ... the keep-state option just ... 00500 deny log ip from to any in via dc1 ...