Subject: via ppp, and yes, it worked.

From: "Dwight Spencer (TeleEducationNB)" <[email-masked]>
Date: Mon, 14 Apr 1997 11:28:58 -0300

I was successfully able to send GSM vat encoded audio and 10kbps h261
encoded video from my laptop with a connectix quickcam attached, at home
over my 33.6 dialin, in Fredericton, NB, Canada to a user in San Jose, CA. 
yesterday.   I seem to remember that when I had gotten this working, 
people had asked that I post how I got it working.

This was a unicast point to point transmission  (I was behind my linux host
using ipmasquerading, so he could not transmit back) using vic and vat.  We
were quite impressed.  Craig told me the audio came through with no loss
(once I had switched to GSM encoding) and the video was coming through
at .5 - 1.5 fps (10kbps, normal size window, quality of 10).  He was 
able to see the snow outside my apartment window :)

What I would like to try next, is mrouted running (with rate_limit if required)
on the linux host at home, to see if I can get session information over the
 link.  Does anyone on the list have a pointer to mrouted (preferably 
binary) for an intel linux system?  I did some searching yesterday, but
ended up with 404(not found)  errors when I eventually found links to 
binaries.  Will I get an immediate flood of session traffic until the mrouted
gets a chance to prune off unrequested sources, or will it only get session 
advertisments?  

One other problem I may have, is that I am dialing into 
a RAS (nt) server on my office lan, which already has mrouted running
on a sparc on the same lan.  Will I be able to configure a tunnel on
my sparc, to point to an ip address with the same class c address?
(my sparc is 198.164.125.5, the nt server is 125.6, and then my 
linux machine is assigned the ip address of 125.55 when connected)

any help or pointers here would be appreciated.  I could try to port the
mrouted source myself, but my c porting is not my strong point, and I 
had thought I saw someone on the list saying they had already built
an mrouted for linux .

thanks,
dwight s.
-------
dwight spencer          internet services manager       [email-masked]
work: 506 444 5389      home: 506 454 0006              fax: 506 444 4232

TeleEducation NB, 500 Beaverbrook Court,
Fredericton, NB, Canada, E3B 5H1

---

From: Bill Fenner <[email-masked]>
Date: Mon, 14 Apr 1997 12:36:49 PDT

"Dwight Spencer (TeleEducationNB)" <[email-masked]> wrote:
>Will I get an immediate flood of session traffic until the mrouted

You will get all traffic until mrouted gets a chance to prune.  This
will flood your line for a while on startup.  However, the prunes are
randomized so after startup, there is not too much broadcast overhead.
One thing that can help a lot is to tune the prune timer; use
"cache_lifetime N" where N is a number of seconds.  The DVMRP spec
recommends 7200 (2 hours).  I don't recommend turning it up that
high on an mrouted 3.8 because of a few bugs.

>Will I be able to configure a tunnel on

No.  If you remove the restriction from cfparse.y, though, it will work.
The problem is that it's not always clear when a tunnel is or is not
needed; the underlying topology is opaque to mrouted so it assumes that
you really are on the same network.

  Bill

---

From: Chris Shenton <[email-masked]>
Date: Mon, 14 Apr 1997 16:00:40 -0400

On Mon, 14 Apr 1997 11:28:58 -0300
"Dwight Spencer (TeleEducationNB)" <[email-masked]> wrote:

spencer> I was successfully able to send GSM vat encoded audio and
spencer> 10kbps h261 encoded video from my laptop with a connectix
spencer> quickcam attached, at home over my 33.6 dialin, in
spencer> Fredericton, NB, Canada to a user in San Jose, CA.
spencer> yesterday.  I seem to remember that when I had gotten this
spencer> working, people had asked that I post how I got it working.
spencer> 
spencer> This was a unicast point to point transmission

33.6? 33.6?? Back in my day, all we could get was 28.8 -- and we had
to walk 50 miles to school, in the snow... :-)

Try the whiteboard, too: I've found 28.8 GSM and whiteboard
surprisingly useable. Any video is a plus, but not really
necessary. If the streams could be prioritized (audio, whiteboard,
then video last) it might help.

Speaking of GSM, might it be a good idea to mcast more conferences
using this lower-bandwidth encoding?

spencer> What I would like to try next, is mrouted running (with
spencer> rate_limit if required) on the linux host at home, to see if
spencer> I can get session information over the link.  Does anyone on
spencer> the list have a pointer to mrouted (preferably binary) for an
spencer> intel linux system?  

I've done this on FreeBSD (mrouted ships built in). I *had* to set the
the rate_limit to 3Kbit/sec to prevent swamping my modem. Without
limiting, mrouting sucked down so much of the modem's capacity that
RIP packets didn't get through often enough, the route to my ISP
disappeared, and then so did everything else including the
tunnel. Guess it's kinda self-limiting :-)

I found that once an Mbone app like sdr started, the dialup line
flooded establishing mrouting info, but gradually the overhead traffic
diminished to a tolerable level.

---

From: "Mark L. Fausett" <[email-masked]>
Date: Mon, 14 Apr 1997 15:10:24 -0700

In my experience, GSM works very well as long as you aren't dropping
packets; drop just one and the speaker sounds like a science fiction
special effect.

Although dvi4 is about double the bandwidth, it seems much more robust
on a lossy net.

Mark Fausett
[email-masked]

Chris Shenton wrote:
...
> using this lower-bandwidth encoding?
...

---

From: Magnus Danielson <[email-masked]>
Date: Tue, 15 Apr 1997 14:59:54 +0200

>>>>> "DS(" == Dwight Spencer (TeleEducationNB) <[email-masked]> writes:

 DS(> I was successfully able to send GSM vat encoded audio and 10kbps h261
 DS(> encoded video from my laptop with a connectix quickcam attached, at home
 DS(> over my 33.6 dialin, in Fredericton, NB, Canada to a user in San Jose, CA. 
 DS(> yesterday.   I seem to remember that when I had gotten this working, 
 DS(> people had asked that I post how I got it working.

 DS(> This was a unicast point to point transmission  (I was behind my linux host
 DS(> using ipmasquerading, so he could not transmit back) using vic and vat.  We
 DS(> were quite impressed.  Craig told me the audio came through with no loss
 DS(> (once I had switched to GSM encoding) and the video was coming through
 DS(> at .5 - 1.5 fps (10kbps, normal size window, quality of 10).  He was 
 DS(> able to see the snow outside my apartment window :)

How nice... are you sure it was not snow from Xsnow? :)

 DS(> What I would like to try next, is mrouted running (with rate_limit if required)
 DS(> on the linux host at home, to see if I can get session information over the
 DS(>  link.  Does anyone on the list have a pointer to mrouted (preferably 
 DS(> binary) for an intel linux system?  I did some searching yesterday, but
 DS(> ended up with 404(not found)  errors when I eventually found links to 
 DS(> binaries.  Will I get an immediate flood of session traffic until the mrouted
 DS(> gets a chance to prune off unrequested sources, or will it only get session 
 DS(> advertisments?  

 DS(> One other problem I may have, is that I am dialing into 
 DS(> a RAS (nt) server on my office lan, which already has mrouted running
 DS(> on a sparc on the same lan.  Will I be able to configure a tunnel on
 DS(> my sparc, to point to an ip address with the same class c address?
 DS(> (my sparc is 198.164.125.5, the nt server is 125.6, and then my 
 DS(> linux machine is assigned the ip address of 125.55 when connected)

 DS(> any help or pointers here would be appreciated.  I could try to port the
 DS(> mrouted source myself, but my c porting is not my strong point, and I 
 DS(> had thought I saw someone on the list saying they had already built
 DS(> an mrouted for linux .

As I can see it, you will end up in a few problems with mrouted and
Bill have addressed a few of them but here is another:

When you run sessions over PPP and a callup line (or rather
non-constant) will your server's mrouted keep sending messages towards
your box even if you is not there. If you only have a line from which
you can call up from one end this is not a major problem, however, if
your office router may call up your box will mrouted now make
continous calls and if your machine is there it will also start
feeding routingtables etc. This behaiviour is good in the normal case,
but not on these lines and it requires a fairly small mod in mrouted
so that you can order mrouted to be quite on an tunnel until the other
end of the tunnel starts probing for connection. This modification
would make the user/home machine in control of the linkstatus and call
pattern without the need to login to the mrouted machine as root to
change the config to let the tunnel be quite that way. Just killing
the mrouted on the home machine will simply not be enougth.

What do you say Bill? I have had this problem for long but never got
around fixing it...

If one wants to port mrouted 3.8 to any new base I propose the
SNMP-mrouted 3.8.2 which has a lot of improvements on portabillity. It
will compile rigth out of the box on more machines than the mrouted
3.8 code itself. Dave Thaler and I spent quite some time in improving
it a lot but there is still some smaller quirks to fix.

There is some people doing multicast for Linux, they should have done
all the work.

Cheers,
Magnus

---

From: Bill Fenner <[email-masked]>
Date: Tue, 15 Apr 1997 15:52:09 PDT

Magnus Danielson <[email-masked]> wrote:
>What do you say Bill?

Ok.  Turns out it was a 15-line change, including the configuration
file option.  "tunnel ... passive" or "phyint ... passive" now doesn't
send probes unless there's someone to talk to.  If both ends of a
tunnel (or ppp link) set passive then the peering will never come up.

  Bill

---

From: D E PRICE <[email-masked]>
Date: Wed, 16 Apr 1997 10:05:28 +0100

Dear Bill,

	Have you already crafted and compiled an mrouted
that now has the concept of `passive' tunnels then?  
I thought myself of looking at this ages ago, but never
found the time to start.   We often find ourselves
using ISDN2 links to stage demos at remote sites
on an adhoc basis and being able to set tunnels
as passive at the base-office end would be very useful.
We also have several people (me included) with
ISDN links to home, similarly we would
like the passivce mechanism for these too.

	If you have a modified version of the code, do
you intend to release it?

Thanks,

Dave Price

---

From: Bill Fenner <[email-masked]>
Date: Wed, 16 Apr 1997 10:36:32 PDT

Dave,

  You're right to point out that I wasn't very clear in my message
yesterday.  mrouted 3.9 will have this feature.  mrouted 3.9 is currently
in limited alpha-test but appears very stable.  I hope to start a public
beta-test cycle very soon.

  Bill

---

From: D E PRICE <[email-masked]>
Date: Thu, 17 Apr 1997 10:41:02 +0100

Dear Bill and Friends,

	While on this issue, I presume the current
position is that if the `remote' mrouted is actually
not running, the tunnel therefore stays down (as the
`main' mrouted has the tunnel set as passive), but as
soon as the remote mrouted comes up, so does the tunnel.

	Another idea I had, was that one might also
be able to leave the `remote' mrouted running, but be able
to describe to it under ""what circumstances"" it actually caused
the tunnle to come `up'. 

My idea was that one
might set it so that it only brought the tunnel up
if it had detected locally connected machines which
had indicated membership of a certain set of multicast groups.

For instance, in the simple case, one might set it so
that only when the group used to receive sdp announcments
had members locally did the link come up. I guess one would
have a field in the config file where one was allowed to specify
sets of groups whose membership caused the tunnel to go live.

Dave Price

---

From: Bill Fenner <[email-masked]>
Date: Thu, 17 Apr 1997 10:01:56 PDT

>had indicated membership of a certain set of multicast groups.

Although a good idea, this one is significantly more complex to
implement.  I'll put it on the TODO list, but it probably won't be
in 3.9 .

  Bill