Date: Mon, 09 Mar 1998 23:48:03 +0000 From: Brian Somers <brian@Awfulhak.org> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: brian@Awfulhak.org (Brian Somers), hackers@FreeBSD.ORG Subject: Re: weird problem (lost packets) in iijppp Message-ID: <199803092348.XAA27247@awfulhak.org> In-Reply-To: Your message of "Mon, 09 Mar 1998 18:26:41 %2B0100." <199803091726.SAA07386@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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 ;
> <add markers to identify fragments>
> 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 <x,0> to mark the first fragment of an incomplete packet, and
> ESC <x,i> 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 <brian@Awfulhak.org>, <brian@FreeBSD.org>, <brian@OpenBSD.org>
<http://www.Awfulhak.org>;
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803092348.XAA27247>