Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)

[Ollivier Robert]

According to John Polstra:
> I have read in several places that only the name "RC4" is trademarked,
> and that the algorithm itself is not patented.  Is that not the case?

That's right. RC4 (aka arcfour in SSH) was a trade secret (so it was not
patentable) till someone posted code implementing it on USENET a few years
ago... They didn't do that mistake again with RC5/RC6/...
-- 
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED]
FreeBSD keltia.freenix.fr 4.0-CURRENT #78: Sun Feb 27 15:32:39 CET 2000



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)

[Brian Somers]

> Juergen Lock writes:
> > > when this is done the netgraph PPP nodes (which can support
> > >  these compression types will be usable.
> > 
> > They could, but they don't yet, right? :)
> > 
> >  Maybe it still should be added to ijppp first cause debugging user
> > processes is easier than the kernel...  and at the usual isdn bri
> > speeds a user process should still be pretty fast enough.
> 
> That makes perfect sense.. just be sure to write the code so that
> it's easily ported to the kernel.. the main issues being mbuf's..
> for that it's probably eassiest to just punt and copy each packet
> into a contiguous buffer.

I've done a small amount of work on making ppp(8)-style mbufs look 
more like real mbufs with this in mind.  If I can bring the whole 
interface in line, this problem will go away.  Of course this'll 
probably then introduce a compatibility problem with {Net,Open}BSD...

> -Archie
> 
> ___
> Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)

[Archie Cobbs]

Hellmuth Michaelis writes:
> >   2. We should come up with a 'standard' netgraph control message
> >  API for an ISDN basic rate interface, and have i4b implement
> >  this interface.  Then mpd/ppp/etc can "know" this interface
> >  and therefore work automatically with any ISDN BRI device.
> >  Here is the interface that we use at Whistle:
> >ftp://ftp.whistle.com/pub/archie/netgraph/ng_tn.h
> >  (note: the switch types are #defined in another file but include
> >  all of the usual suspects: ETSI, NI-1, AT&T, DMS100, etc.)
> 
> The problem here is, that the Whistle ISDN stack has a fundamentally
> different view of the world than i4b has :-) As far as i understood it,
> the Whistle ISDN stack is almost completely configurable by using 
> netgraph messages whereas i4b is configured by its isdnd config file.
> 
> I have made some experiments with mppd over the i4b netgraph b-channel
> interface and it works beautifully here without any additional 
> configuration messages necessary. But i have no idea, if the real world
> demands some control messages, such as dial, dial a number, hangup etc.

Yes, our way of doing things was of course designed for our particular
application.  It depends on what you want to do with an 'ISDN node'.

The /dev/i4b interface is actually pretty close to equivalent to
our netgraph control message API. The main differences seem to be:

  - Our API is strictly limited to ISDN operation, e.g., there
are no equivalents to I4B_TIMEOUT_UPD, I4B_UPDOWN_IND, or
MSG_IDLE_TIMEOUT_IND and no connection to sppp(8)

  - Our API allows more ISDN-related configuration, e.g., changing
switch type.

  - Our API is at a slightly higher level.. we don't have the
CDID_REQ or PROCEEDING_IND messages; when rejecting a call,
you don't get to specify the cause code, it's always
set to 21 for you, etc.

So the /dev/i4b and our netgraph API are actually quite similar.

Of course, a major difference is that with /dev/i4b you don't
get the B-channels exposed as netgraph node hooks, which is
very useful... but as you've shown already this is easy to add.
This gets you a "half netgraphified" ISDN node.

One thing that would be easy to do is to simply convert all of the
/dev/i4b ioctl's directly into netgraph control messages.  This
doesn't really buy you anything much though -- really just a
different interface for the same thing.

But if there were future plans to do all kinds of wacky things
with an ISDN device that would benefit by having it fully
netgraphified, maybe this would be worth doing.

-Archie

___
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)

[Hellmuth Michaelis]

(CC: stripped)

>From the keyboard of Archie Cobbs:

> Here is my list of things that 'should be done' at some point:
> 
>   1. Implement the various PPP compression types as netgraph nodes,
>  starting with Deflate, then maybe predictor-1, STAC (if we can
>  do it legally), and MPPC (same thing).

Sounds good. The link in the original mail points to a Linux (GPL)
implementation of the STAC compression. Since i was under the impression
that STAC is patented, i've contacted the author about this and it seems
that STAC either did not notice his implementation, does not care about
it, or that it is legal to reimplement it here in Germany or Europe.

Perhaps it might be possible to use this somehow, or at least provide
hooks to use it ...

>   2. We should come up with a 'standard' netgraph control message
>  API for an ISDN basic rate interface, and have i4b implement
>  this interface.  Then mpd/ppp/etc can "know" this interface
>  and therefore work automatically with any ISDN BRI device.
>  Here is the interface that we use at Whistle:
>ftp://ftp.whistle.com/pub/archie/netgraph/ng_tn.h
>  (note: the switch types are #defined in another file but include
>  all of the usual suspects: ETSI, NI-1, AT&T, DMS100, etc.)

The problem here is, that the Whistle ISDN stack has a fundamentally
different view of the world than i4b has :-) As far as i understood it,
the Whistle ISDN stack is almost completely configurable by using 
netgraph messages whereas i4b is configured by its isdnd config file.

I have made some experiments with mppd over the i4b netgraph b-channel
interface and it works beautifully here without any additional 
configuration messages necessary. But i have no idea, if the real world
demands some control messages, such as dial, dial a number, hangup etc.

Any ideas how to proceed with this ?

hellmuth
-- 
Hellmuth MichaelisTel   +49 40 55 97 47-70
HCS Hanseatischer Computerservice GmbHFax   +49 40 55 97 47-77
Oldesloer Strasse 97-99   Mail  hm [at] hcs.de
D-22457 Hamburg   WWW   http://www.hcs.de


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)

[Wes Peters]

John Polstra wrote:
> 
> In article <[EMAIL PROTECTED]>,
> Archie Cobbs  <[EMAIL PROTECTED]> wrote:
> 
> >  I already have code for MPPC/MPPE, minus the proprietary STAC
> >  code and the patented RC4 algorithm,
> 
> I have read in several places that only the name "RC4" is trademarked,
> and that the algorithm itself is not patented.  Is that not the case?

I thought RC4 was trademarked by Honda in the USA???

-- 
"Where am I, and what am I doing in this handbasket?"

Wes Peters Softweyr LLC
[EMAIL PROTECTED]   http://softweyr.com/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)

[Archie Cobbs]

John Polstra writes:
> >  I already have code for MPPC/MPPE, minus the proprietary STAC
> >  code and the patented RC4 algorithm,
> 
> I have read in several places that only the name "RC4" is trademarked,
> and that the algorithm itself is not patented.  Is that not the case?

Oops, my mistake.. you are correct as far as I know.

What I should have said was "the non-exportable RC4 algorithm"
because (also AFAIK) it's not exportable so we can't check it into
freefall.

We *can* check it in to the international repository but I don't know
if anyone has done that yet, or if so what the header file looks like.

-Archie

___
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)

[John Polstra]

In article <[EMAIL PROTECTED]>,
Archie Cobbs  <[EMAIL PROTECTED]> wrote:

>  I already have code for MPPC/MPPE, minus the proprietary STAC
>  code and the patented RC4 algorithm,

I have read in several places that only the name "RC4" is trademarked,
and that the algorithm itself is not patented.  Is that not the case?

John
-- 
  John Polstra   [EMAIL PROTECTED]
  John D. Polstra & Co., Inc.Seattle, Washington USA
  "Disappointment is a good sign of basic intelligence."  -- Chögyam Trungpa



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)

[Archie Cobbs]

Juergen Lock writes:
> > when this is done the netgraph PPP nodes (which can support
> >  these compression types will be usable.
> 
> They could, but they don't yet, right? :)
> 
>  Maybe it still should be added to ijppp first cause debugging user
> processes is easier than the kernel...  and at the usual isdn bri
> speeds a user process should still be pretty fast enough.

That makes perfect sense.. just be sure to write the code so that
it's easily ported to the kernel.. the main issues being mbuf's..
for that it's probably eassiest to just punt and copy each packet
into a contiguous buffer.

-Archie

___
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)

[Archie Cobbs]

Hellmuth Michaelis writes:
> > 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 ;-)

Here is my list of things that 'should be done' at some point:

  1. Implement the various PPP compression types as netgraph nodes,
 starting with Deflate, then maybe predictor-1, STAC (if we can
 do it legally), and MPPC (same thing).

 Once these exist, then mpd 'adapters' will have to be written
 for each one -- these are easy, they just decode the config-req's.

 I already have code for MPPC/MPPE, minus the proprietary STAC
 code and the patented RC4 algorithm, and am going to submit
 it after 4.0-REL as soon as somebody submits an RC4 implementation
 to /sys/crypto in the international repository. Mpd-3.x already
 has support for MPPC/MPPE. This is available on our ftp site..
   ftp://ftp.whistle.com/pub/archie/netgraph/mppc.tgz

  2. We should come up with a 'standard' netgraph control message
 API for an ISDN basic rate interface, and have i4b implement
 this interface.  Then mpd/ppp/etc can "know" this interface
 and therefore work automatically with any ISDN BRI device.
 Here is the interface that we use at Whistle:
   ftp://ftp.whistle.com/pub/archie/netgraph/ng_tn.h
 (note: the switch types are #defined in another file but include
 all of the usual suspects: ETSI, NI-1, AT&T, DMS100, etc.)

-Archie

___
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)

[Juergen Lock]

On Sun, Mar 05, 2000 at 12:31:30AM -0800, Julian Elischer wrote:
> Hellmuth Michaelis wrote:
> > 
> > >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/
> > 
> > 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.
> 
> 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..
> 
> (I did look at it already some time ago)
> 
> when this is done the netgraph PPP nodes (which can support
>  these compression types will be usable.

They could, but they don't yet, right? :)

 Maybe it still should be added to ijppp first cause debugging user
processes is easier than the kernel...  and at the usual isdn bri
speeds a user process should still be pretty fast enough.

 Regards,
-- 
Juergen Lock <[EMAIL PROTECTED]>
(remove dot foo from address to reply)


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)

[Juergen Lock]

On Sun, Mar 05, 2000 at 06:32:45AM +0100, Hellmuth Michaelis wrote:
> >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/
> 
> 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.
> 
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 <[EMAIL PROTECTED]>
(remove dot foo from address to reply)


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 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 MichaelisTel   +49 40 55 97 47-70
> HCS Hanseatischer Computerservice GmbHFax   +49 40 55 97 47-77
> Oldesloer Strasse 97-99   Mail  hm [at] hcs.de
> D-22457 Hamburg   WWW   http://www.hcs.de

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)

[Hellmuth Michaelis]

>From the keyboard of Julian Elischer:

> > > 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 MichaelisTel   +49 40 55 97 47-70
HCS Hanseatischer Computerservice GmbHFax   +49 40 55 97 47-77
Oldesloer Strasse 97-99   Mail  hm [at] hcs.de
D-22457 Hamburg   WWW   http://www.hcs.de


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)

[Julian Elischer]

Hellmuth Michaelis wrote:
> 
> >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/
> 
> 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.

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..

(I did look at it already some time ago)

when this is done the netgraph PPP nodes (which can support
 these compression types will be usable.



-- 
  __--_|\  Julian Elischer
 /   \ [EMAIL PROTECTED]
(   OZ) World tour 2000
---> X_.---._/  presently in:  Perth
v


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)

[Hellmuth Michaelis]

>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/

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 MichaelisTel   +49 40 55 97 47-70
HCS Hanseatischer Computerservice GmbHFax   +49 40 55 97 47-77
Oldesloer Strasse 97-99   Mail  hm [at] hcs.de
D-22457 Hamburg   WWW   http://www.hcs.de


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)

[Brian Somers]

>  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

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 <[EMAIL PROTECTED]>
> (remove dot foo from address to reply)

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

ijppp for isdn, ppp compression, and netgraph (also: load balancing)

[Juergen Lock]

In article <[EMAIL PROTECTED]> you write:
>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 <[EMAIL PROTECTED]>
(remove dot foo from address to reply)


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message