All things related to multicast

[Alan Crosswell <>]

>   I think yours is a name from the past - maybe BITNET or SHARE days of

Hi Marty, Yes it's me:-)  I just ran into Hank Nussbaum on the net recently
too;-)

>   We have a sister campus (UND) looking at doing an I2 Day demo with the
>CamVision2's for a music application (don't know all details but something
>about chorus being at UND and the composer in California.  It could
>probably be unicast for this.  But we're very concerned about the large
>bandwidth since right now we only have a DS3 connection to I2/Abilene and
>that is partially used for I1 traffic on part of the circuit.

We just did the same demo yesterday with Brian and the Oklahoma folks
and the Manhattan School of Music yesterday (MSM is our neighbor).
The encoder runs at speeds of 1.5 thru 15.4 Mbps with acceptable
quality when running as low as 5-7 Mbps.  The tradeoff is increased
latency due to the codec spending more time compressing the video.
When run at 15.4 Mbps the codec delay is around 150 ms.  For
highly-interactive conferencing such as the music instruction thing,
they want as little latency as possible.  Still, no matter how low the
codec latency, it's still a nanosecond per foot, guaranteed:-) At one
point, the instructor here got so caught up in the lesson that she
started snapping time with her fingers to get the remote student to
follow along.  When she was reminded of the delay, she asked the
student to turn on a metronome.  This is an instructor who has
previous experience using H.320 ISDN conferencing for this same type
of instruction.

Another issue with these Littons is they send a large UDP segment
(like 32 or 64K) which turns into lots of IP fragments and lots and
lots of ATM cells if that's your underlying infrastructure.  These all
come back to back and if even one ATM cell is dropped the whole
datagram is lost. 

I found by just taking one extra routing hop on campus here I was
losing 100% of my traffic going toward the remote site.  This is
because we are not distributing full routes into our IGP and default
was coming from our I1 router via a 100 Mbps link and was trying to do
one-armed routing of this extra 15 Mbps in and back out.  Looking at
interface stats, the traffic was going in but not coming out.  I fixed
this for the time being by putting in statics for a handful of other
sites.  Once we replace our MSMs with MSFCs we'll probably do
something like redistribute all I2 routes into the IGP and still use
default for I1 routes.

So any network loss is a real problem.  One thing I heard at the NLANR
meeting in Miami is that some ATM networks were setting the CLP bit on
all UBR or ABR traffic and had the ATM switches had a default maximum
burst length which was shorter than the 700 or so cells that result
from a single Litton PDU.  So some cells beyond the burst limit were
all getting tossed (even though there was bandwidth available).  I
know for example that Oklahoma had/has an unresolved problem with
their ATM connection to their gigapop such that they switched them
over to a gigE over dark fiber link.

Another important issue is you need good audio engineers to deal with
things like echo cancelation.  For our demo, I told the audio engineer
from MSM that I was giving him stereo line in and out and it was his
job to work with Brian to take it from there.  It was pretty cool
watching them work and I learned some new jargon:-) They did some
experiments with stereo mics on a viola played in NYC that the folks
in Oklahoma said sounded real good -- and these are people with a real
musical ear, not me:-) They also discovered that the echo canceler at
the OU end was seriously distorting ("coloring") the sound and it was
much better once removed.  Our end had no echo canceler and was in a
lousy room where you can hear a pin drop (and drop and drop and drop....).
A proper recording studio environment with dead sound would have
helped a lot.

/a