ijppp for isdn, ppp compression, and netgraph (also: load balancing)
Brian Somers
> Currently i'm using ppp instead of mppd mostly just because it supports
> deflate compression. I had a look at both mppd and ppp to see how the
> mentioned free stac compression would be integrateable and found them
> both similar, given they both come from iijppp. It looks like if it were
> a good idea if Brian and Archie would merge both to get the best features
> from each one into a common product ;-)
The reason we haven't done this yet is my fault. I've been too busy
with other things :-/ I hope this'll change soon.
> hellmuth
> --
> Hellmuth Michaelis Tel +49 40 55 97 47-70
> HCS Hanseatischer Computerservice GmbH Fax +49 40 55 97 47-77
> Oldesloer Strasse 97-99 Mail hm [at] hcs.de
> D-22457 Hamburg WWW http://www.hcs.de
--
Brian <br...@Awfulhak.org> <brian@[uk.]FreeBSD.org>
<http://www.Awfulhak.org> <brian@[uk.]OpenBSD.org>
Don't _EVER_ lose your sense of humour !
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Hellmuth Michaelis
> > > today... impressive stuff.) and is someone working on linking i4b
> > > and netgraph?
> >
> > There will be a netgraph node interface which will link an i4b B-channel
> > to netgraph. There are no plans from my side to netgraphify the D-channel
> > part of i4b.
>
> to add a negraph interface to the B channels should be quite easy.
> If you need help I can prbably almost do most of it..
Its already in the development sources (Archie had a look at it already)
and it works with mppd. It was really quite easy, although if Archies
daemonnews article had been available at that time i wrote it, it would
have been even easier :-)
> when this is done the netgraph PPP nodes (which can support
> these compression types will be usable.
In the mppd i worked with (looking ... mpd3.0b1/mpd3.0b2) deflate was not
present, predictor was not usable, bsd was not present. There were just
hooks for M$ and stac (which you can not release obviously).
Currently i'm using ppp instead of mppd mostly just because it supports
deflate compression. I had a look at both mppd and ppp to see how the
mentioned free stac compression would be integrateable and found them
both similar, given they both come from iijppp. It looks like if it were
a good idea if Brian and Archie would merge both to get the best features
from each one into a common product ;-)
hellmuth
--
Hellmuth Michaelis Tel +49 40 55 97 47-70
HCS Hanseatischer Computerservice GmbH Fax +49 40 55 97 47-77
Oldesloer Strasse 97-99 Mail hm [at] hcs.de
D-22457 Hamburg WWW http://www.hcs.de
Juergen Lock
>Don't know whether it is the right term but what would be
>desirable is a way to raise priority of certain protocols, and
>lower e.g. ftp, http and such.
>
>You know what I mean? You are fetching a big file, but wanna do
>an rlogin at the same time. I'm doing so right now and
>it's no fun to type while 7.2Kb/s are running over your head
>at the same time :-)
I was just looking (finally :) at ijppp again now that it knows i4b,
and it already does something like this, look for `set urgent' in its
manpage (man ppp). (if you still want to stick with isppp or raw hdlc
you could probably also use altq but thats not in the base system.)
Of course to really help for the fetching-a-big-file case the same
thing would have to be done at the other end of the link as well...
And the other reason i'm looking at ijppp is ppp compression. It
currently supports deflate (rfc1979) and predictor1 (rfc1978), which
should at least help if the other end is running bsd or linux,
but if your other end is something like an ascend or an external
router (zyxel, cisco(?), there are probably more that speak this
protocol), you'd want stac lzs (rfc1974), or if its a wintendo box
even you'd want M$' special version of that (yes of course they
invented their own `standard' again.) So my question is, is
anyone working on this? There is (alpha) code that does this on
linux,
http://www.ibh-dd.de/~beck/stuff/lzs4i4l/
apparently the only thing it doesn't do is ascend's original
predecessor of rfc1974 but it seems at least the later ascends can
also be configured to do `proper' rfc1974, they only (well...) do the
older thing by default. (ok there also seem to be patent issues with
this type of compression and that linux source is GPL'd too so it
probably at best could become a port, but that shouldn't stop it from
being useful.)
And the last thing, is anyone working on moving more of ppp back
into the kernel, like, by using netgraph? (i hadn't really looked
at this netgraph thing yet until i read the daemonnews article
today... impressive stuff.) and is someone working on linking i4b
and netgraph? that seems to be the logical way to do more complex
stuff like this aodi thing that e.g. the german Telekom wants to use
for their low-bandwidth 10 DEM/month isdn `flatrate' which they plan to
introduce around the end of the year. (and _if_ this really works it
sure will become pretty popular over here as long as all the other `real'
flatrates are still in the 100 DEM or more range... :/ ) this seems to
be the current draft:
http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-pppext-aodi-02.txt
Regards,
--
Juergen Lock <nox...@jelal.kn-bremen.de>
(remove dot foo from address to reply)
Brian Somers
> into the kernel, like, by using netgraph? (i hadn't really looked
> at this netgraph thing yet until i read the daemonnews article
> today... impressive stuff.) and is someone working on linking i4b
> and netgraph? that seems to be the logical way to do more complex
> stuff like this aodi thing that e.g. the german Telekom wants to use
> for their low-bandwidth 10 DEM/month isdn `flatrate' which they plan to
> introduce around the end of the year. (and _if_ this really works it
> sure will become pretty popular over here as long as all the other `real'
> flatrates are still in the 100 DEM or more range... :/ ) this seems to
> be the current draft:
>
> http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-pppext-aodi-02.txt
I'm looking at pushing more stuff into the kernel using netgraph, but
I haven't had much of a chance recently to work on it. Hellmuth has
also created an i4b netgraph node, but again, I haven't had a chance
to do much with it.
Now that I've got a free-in-the-evenings ISDN connection, I have no
excuses left though.... (except that it's showing up busy at the
moment). Once the freeze is over, I'll be looking at getting things
under way.
> Regards,
> --
> Juergen Lock <nox...@jelal.kn-bremen.de>
> (remove dot foo from address to reply)
--
Brian <br...@Awfulhak.org> <brian@[uk.]FreeBSD.org>
<http://www.Awfulhak.org> <brian@[uk.]OpenBSD.org>
Don't _EVER_ lose your sense of humour !
Juergen Lock
> >From the keyboard of Juergen Lock:
>
> > And the other reason i'm looking at ijppp is ppp compression. It
> > currently supports deflate (rfc1979) and predictor1 (rfc1978), which
> > should at least help if the other end is running bsd or linux,
> > but if your other end is something like an ascend or an external
> > router (zyxel, cisco(?), there are probably more that speak this
> > protocol), you'd want stac lzs (rfc1974), or if its a wintendo box
> > even you'd want M$' special version of that (yes of course they
> > invented their own `standard' again.) So my question is, is
> > anyone working on this? There is (alpha) code that does this on
> > linux,
> >
> > http://www.ibh-dd.de/~beck/stuff/lzs4i4l/
>
> when i realized how much work it would be to port it.
>
> Brian's ppp over i4b does support deflate compression and i get very
> good results out of it - too good to put more work into the above URL.
>
I don't see anything wrong with deflate itself either, its just that
when you don't have control over whats at the other end of the link
its most of the time useless, most equipment thats out there _if_
it does compression at all still only knows the other protocols. :(
> > that seems to be the logical way to do more complex
> > stuff like this aodi thing that e.g. the german Telekom wants to use
> > for their low-bandwidth 10 DEM/month isdn `flatrate' which they plan to
> > introduce around the end of the year. (and _if_ this really works it
> > sure will become pretty popular over here as long as all the other `real'
> > flatrates are still in the 100 DEM or more range... :/ ) this seems to
> > be the current draft:
>
> - this "flatrate" will only be available to T-Online customers. Since i'm
> not such a beast and will probably never become one its of not much use
> for me.
>
well for someone who _could_ use it the 8 DEM more (is it still
8?) for the t-offline account may still be worth it, and i don't
think they would even be allowed to force you to do _all_ your ip
over their system... (yes that may need some routing tweaks but
so be it. :) at least the proposed aodi protocol shouldn't be in
the way and i've already had two connections open with i4b at the
same time over a single card and it worked as expected. the only
problem would be you couldn't dynamically up the bandwith of
connections that are already open over the slow link without routing
that additional B channel over t-offline too. well unless you
start playing with tunnels...)
> - my usage of the internet is not much compatible with what this "flatrate"
> offers.
>
hmm imho there's a lot of things a low-bandwidth link can be useful
for when all your other links are still metered... :/ think of
always getting mail delivered near-immediately at no extra cost
as soon as the box is up, or that you'd no longer have to close and
re-open things like ssh sessions all the time, or that you could
just talk(1) to someone instead of having to pay for a phonecall...
(in case anyone wonders: yes those are also still _always_ metered
here) and that even while both B channels may be busy with other
things.
Oh and you could then also get at the box from `anywhere' if you
need to, whithout having to make (and pay for) a direct isdn
connection or other special precautions cause you'd no longer have
to worry about portscanning/flood-pinging script kiddies or other
kinds of `accidents' causing insane phone bills when you leave the
box online while you can't watch it. (well, assuming you made a
decent firewall.)
(of course when i look at _my_ usage of the net a 100 DEM 64kbit
flatrate will probably still be more economical (*sigh*), but i
suspect there are lots of people where this wouldn't be so.)
> - the Telecom does not give away anything for free. Check when, why and
> most important how you are using the internet: the savings you get using
> this "flatrate" does not pay even a fraction of the time and work needed
> to implement this - in my eyes.
>
Well yes someone would have to do the work and it probably won't
exactly make him rich either, thats true. :) (but it could make
bsd more popular if it gets this before linux...)
Regards,
--
Juergen Lock <nox...@jelal.kn-bremen.de>
(remove dot foo from address to reply)
Hellmuth Michaelis
> And the other reason i'm looking at ijppp is ppp compression. It
> currently supports deflate (rfc1979) and predictor1 (rfc1978), which
> should at least help if the other end is running bsd or linux,
> but if your other end is something like an ascend or an external
> router (zyxel, cisco(?), there are probably more that speak this
> protocol), you'd want stac lzs (rfc1974), or if its a wintendo box
> even you'd want M$' special version of that (yes of course they
> invented their own `standard' again.) So my question is, is
> anyone working on this? There is (alpha) code that does this on
> linux,
>
> http://www.ibh-dd.de/~beck/stuff/lzs4i4l/
I've looked at that. Its very Linux-centric and i gave up for the moment
when i realized how much work it would be to port it.
Brian's ppp over i4b does support deflate compression and i get very
good results out of it - too good to put more work into the above URL.
> today... impressive stuff.) and is someone working on linking i4b
> and netgraph?
There will be a netgraph node interface which will link an i4b B-channel
to netgraph. There are no plans from my side to netgraphify the D-channel
part of i4b.
> that seems to be the logical way to do more complex
> stuff like this aodi thing that e.g. the german Telekom wants to use
> for their low-bandwidth 10 DEM/month isdn `flatrate' which they plan to
> introduce around the end of the year. (and _if_ this really works it
> sure will become pretty popular over here as long as all the other `real'
> flatrates are still in the 100 DEM or more range... :/ ) this seems to
> be the current draft:
- this "flatrate" will only be available to T-Online customers. Since i'm
not such a beast and will probably never become one its of not much use
for me.
- my usage of the internet is not much compatible with what this "flatrate"
offers.
- the Telecom does not give away anything for free. Check when, why and
most important how you are using the internet: the savings you get using
this "flatrate" does not pay even a fraction of the time and work needed
to implement this - in my eyes.
Anyway, i will happily accepting (clean) code which implements it :-)
hellmuth
--
Hellmuth Michaelis Tel +49 40 55 97 47-70
HCS Hanseatischer Computerservice GmbH Fax +49 40 55 97 47-77
Oldesloer Strasse 97-99 Mail hm [at] hcs.de
D-22457 Hamburg WWW http://www.hcs.de