Date: Mon, 9 Mar 1998 18:26:41 +0100 (MET) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: brian@Awfulhak.org (Brian Somers) Cc: brian@Awfulhak.org, hackers@FreeBSD.ORG Subject: Re: weird problem (lost packets) in iijppp Message-ID: <199803091726.SAA07386@labinfo.iet.unipi.it> In-Reply-To: <199803081756.RAA01605@awfulhak.org> from "Brian Somers" at Mar 8, 98 05:56:37 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 ;
<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...
cheers
luigi
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?199803091726.SAA07386>