From owner-freebsd-current Tue Feb 17 17:26:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA11082 for freebsd-current-outgoing; Tue, 17 Feb 1998 17:26:45 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id RAA10993 for ; Tue, 17 Feb 1998 17:26:16 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id UAA01120; Tue, 17 Feb 1998 20:50:16 +0100 From: Luigi Rizzo Message-Id: <199802171950.UAA01120@labinfo.iet.unipi.it> Subject: Re: cvs commit: src/usr.sbin/ppp command.c datalink.c datalink.h defs.h vars.c vars.h To: eivind@yes.no (Eivind Eklund) Date: Tue, 17 Feb 1998 20:50:15 +0100 (MET) Cc: plm@xs4all.nl, freebsd-current@FreeBSD.ORG In-Reply-To: <19980217203309.39822@follo.net> from "Eivind Eklund" at Feb 17, 98 08:32:50 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > It looks like all development on ppp takes place on the "MP" branch. I ... > This is a major re-structuring, which will just replace the PPP in > -current when it is finished. The use of the MP-branch is just to let > people see what's happening, keep history,.and to make it possible for > Brian and me to coordinate (not necessarily in that order). since this appears to be the right forum... there are a few things I would like (eventually) to go into ppp, so i am just throwing a few ideas here... i don't have the time to work on these things now, although I might look at them in the summer. * Fair Queueing support (i don't think it is already there, just a priority for interactive packets ?) the code could be grabbed from the ALTQ package recently announced on this list. Not necessarily the full package, just the FQ stuff could help; * "preemption" . I don't think ppp allows this, but perhaps it could be possible to implement preemption of long packets (or transfer them in smaller 'cells') so that interactive traffic does not suffer exceedingly large delays... is there any work on this ? (the alternative -- lowering MTU -- is not that attractive i believe, since it causes some overhead even if the last hop has proper header compression) cheers luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message