Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 07 Sep 1999 12:29:10 +0100
From:      Brian Somers <brian@Awfulhak.org>
To:        "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>
Cc:        brian@FreeBSD.org (Brian Somers), cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/usr.sbin/ppp command.c ip.c ipcp.c ipcp.h ppp.8 
Message-ID:  <199909071129.MAA87364@keep.lan.Awfulhak.org>
In-Reply-To: Your message of "Tue, 07 Sep 1999 01:21:44 PDT." <199909070821.BAA05060@gndrsh.dnsmgr.net> 

next in thread | previous in thread | raw e-mail | index | archive | help
> > brian       1999/09/07 00:51:12 PDT
> > 
> >   Modified files:
> >     usr.sbin/ppp         command.c ip.c ipcp.c ipcp.h ppp.8 
> >   Log:
> >   Introduce a forth IP packet queue.  Urgent packets with
> >   ip_tos == IPTOS_LOWDELAY now get precidence over urgent
> >   packets with ip_tos != IPTOS_LOWDELAY and non-urgent packets
> >   with ip_tos == IPTOS_LOWDELAY.
> 
> I'm getting a bit concerned here, what is the depth of these
> queues?  If it is the default of 50, then we now eat a lot
> of mbuf space should the ppp interface stall (and, trust me,
> they do stall).  I'm not really worried about the memory,
> thats cheap enough, I'm worried about the amount of time
> it will take for the higher priority queues to drain so that
> the low priority traffic goes out after a stall.  (Note, these
> stalls are usually cause on ISDN TA's with Additional Call Offering
> or Additional Outbound Call features running in ISDN Bonding mode.)
> 
> It may require me to retune some OSPF timing parameters...
> or mark the packets high priority (which, they really aren't)

Ppp will eat up to 30 packets from the tun device (if you're using 
MP, add (2 * links) to that).  These packets will sit in one of the 
four IP queues.

The highest priority queue is reserved for link level traffic.  
There's no such thing in terms of IP traffic, so I'm sure you'll now 
spot the deliberate mistake :-I

The second highest is reserved for ``urgent'' packets that have the 
ip_tos also set to LOWDELAY.

The third highest is reserved for both ``urgent'' traffic and traffic 
with the ip_tos set to LOWDELAY.

The lowest is reserved for everything else.

Once the total packets in these four (soon to become 3) queues 
reaches the above number, ppp stops reading stuff from the tun 
device.  If nothing can be sent within the ``choked'' time (default 2 
minutes), ppp dumps the packets and starts reading again.

If any of the link descriptors become writable (as reported by 
select()), ppp pushes a packet from the head of the highest priority 
IP queue, resets the choked timer and read()s more from the tun 
device.

There's no overhead (apart from the minor ``find which queue has 
data'' search) in these extra queues.  The extra one (added with this 
commit) is there so that (for example) telnet trafic that's marked as 
LOWDELAY will actually skip other telnet trafic.

I think the only point worth arguing over is the previous commit that 
changed the magic number of packets from 20 to 30.

> >   Enhance the ``set urgent'' syntax to allow for urgent UDP
> >   packets as well as urgent TCP packets.
> 
> And is there a knob to turn this all off and go back to 1 or
> 2 queues only?

No.  I don't think we need one.

> -- 
> Rod Grimes - KD7CAX - (RWG25)                    rgrimes@gndrsh.dnsmgr.net
> 

-- 
Brian <brian@Awfulhak.org>                        <brian@FreeBSD.org>
      <http://www.Awfulhak.org>;                   <brian@OpenBSD.org>
Don't _EVER_ lose your sense of humour !          <brian@FreeBSD.org.uk>




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909071129.MAA87364>