From owner-freebsd-hackers Mon Mar 9 10:56:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA04065 for freebsd-hackers-outgoing; Mon, 9 Mar 1998 10:56:58 -0800 (PST) (envelope-from owner-freebsd-hackers@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 KAA03951 for ; Mon, 9 Mar 1998 10:56:32 -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 SAA07386; Mon, 9 Mar 1998 18:26:41 +0100 From: Luigi Rizzo Message-Id: <199803091726.SAA07386@labinfo.iet.unipi.it> Subject: Re: weird problem (lost packets) in iijppp To: brian@Awfulhak.org (Brian Somers) Date: Mon, 9 Mar 1998 18:26:41 +0100 (MET) Cc: brian@Awfulhak.org, hackers@FreeBSD.ORG In-Reply-To: <199803081756.RAA01605@awfulhak.org> from "Brian Somers" at Mar 8, 98 05:56:37 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I got your other mail that says it doesn't happen with the latest > version. Can you try the latest version with `deny deflate' and > `disable deflate' ? This will force pred1 compression again :-) tried the above and still seems to have no problem. > Currently, there are two output queue sets, one IP queue set and one > modem queue set. Each queue set consists of two queues, a fast one > (interactive traffic in the IP set, non-NCP traffic in the modem set) > and a slow one. Stuff is compressed just before moving from the IP > set into the slow modem queue. regarding the IP queues, keeping two static queues is not very nice. i think it would be much better to implement some sort of "fair queueing" since the code is already available (e.g. the ALTQ package) and could be easily integrated i believe. This would also allow better queueing policies, integration with filtering, aliasing, etc. etc. Compression is applied in the wrong place, since doing it before passing through the modem queues prevents from doing some reordering of packets later. One wouldn't care normally, except that transmission times on a modem line are non-negligible, thus the chance that one might want to push forward some interactive packet might be significant. Also, doing compression before the modem queue prevents you from doing smart things with multiple lines, such as splitting long packets into smaller fragments and sending them in parallel and reassembling at the other end... My approach would be: - at least replace the modem queues with a single, fair-queuing mechanism; - add, in parallel, a prioritary queue for link control traffic (the 'fast modem queue'); - add options to split in-progress packets; here a fragment is either a whole link-control-packet (from the fast modem queue) or a small block (say 64..256 bytes) from the IP queues. This would be used both to handle better interactive response, and to get improved performance from parallel lines (see below) - do compression only when a fragment has been selected for unconditional write to the modem line. Since pred1 compression is _very_ fast, it is reasonable to do it right before the write() of the fragment. - keep compression state per line. Since the pred1 status is only 64KB, i think one can really afford the additional memory. Basically the forwarding loop would be ... select on the set of outgoing modem lines ... S = set of modem lines returning ready for write ; for (; S not empty && have_packets_in_queue ; ) { for (i in S) { get a fragment from the queue ; compress fragment using per-line status; enqueue compressed fragment on line i if (enough data queued on line i) remove i from S } } for (i in S) send block on the line i; there would be some small overhead per fragment to mark boundaries among fragments of different packets, but probably nothing very relevant: e.g. add ESC to mark the first fragment of an incomplete packet, and ESC to mark subsequent fragments of the above. Imaybe one also has to add a few bits to mark the link where the previous fragment was... but then part of this info could be merged with the various header compression techniques. Although a bit tricky, I think this would be very effective to reduce delays. Of course, we'd need some new PPP option to enable this enhanced features. > Is this what you have in mind ? Wouldn't we be better off suffering > the overhead of a smaller MTU ? After all, with VJ compression, > there isn't that much overhead in sending out shorter packets. this is the simplest solution in the short term i agree, but since somebody was working on ppp i thought it was worth discussing the subject... cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message