From owner-freebsd-hackers Mon Mar 9 19:05:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA17980 for freebsd-hackers-outgoing; Mon, 9 Mar 1998 19:05:22 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from awfulhak.org (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA17672 for ; Mon, 9 Mar 1998 19:04:05 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.org (8.8.7/8.8.7) with ESMTP id XAA27247; Mon, 9 Mar 1998 23:48:03 GMT (envelope-from brian@gate.lan.awfulhak.org) Message-Id: <199803092348.XAA27247@awfulhak.org> X-Mailer: exmh version 2.0.1 12/23/97 To: Luigi Rizzo cc: brian@Awfulhak.org (Brian Somers), hackers@FreeBSD.ORG Subject: Re: weird problem (lost packets) in iijppp In-reply-to: Your message of "Mon, 09 Mar 1998 18:26:41 +0100." <199803091726.SAA07386@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 09 Mar 1998 23:48:03 +0000 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 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. The queueing is pretty simple at the moment - I agree it could be fairer. > 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. Ppp compression is done per packet according to the rfc. There's no facility for splitting packets when compression is involved - not without changing the rfc. The objective here should be to keep the modem queue(s) as small as possible - there should be zero to one packets in the slow queue, and the slow queue is the only thing that can be compressed. This isn't actually true in the MP branch (for now), and the -current and -stable code is hideous and almost definitely wrong. When this queue shifting stuff is corrected, changing the MTU should make more of a difference. Compression is applied in the only place it can be applied - just before the packet gets HDLC'd and enters the modem queue (and is therefore a candidate for transmission). Once something makes it into that modem queue, it's as good as sent and cannot be skipped by another packet. This becomes even more true in the multilink case as everything is sequenced too (there is room to re-sequence to a certain extent, but not much if the modem queues are kept as small as possible). The two IP queues facilitate (crude) packet skipping now. This is where the complication should be built - not at the modem level. > 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... This should only be done at the IP queue level. > My approach would be: > - at least replace the modem queues with a single, fair-queuing > mechanism; We can replace the IP queues - not the modem queues (see above). > - 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) I don't get what you're trying to say here. We can't start sending fragments to the other side. It won't know what we're talking about.... it's not in the rfc.... > - 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. There are two levels of compression in the multilink case. One at the link level and one at the bundle level. > > 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... Maybe, but I have no idea how to go about writing an rfc and getting it added by internic.... > cheers > luigi -- Brian , , Don't _EVER_ lose your sense of humour.... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message