ietf
[Top] [All Lists]

Re: bandwidth (and other support) required for multicast

2001-03-29 16:00:03
On Thu, 29 Mar 2001, Keith Moore wrote:

1. poll WG chairs from the last IETF to see how many people contributed
things in real time from remote locations.

        Well, not relevant; most people listen, just as they
        do when they are present (and BTW, this is a completely
        legitimate reason to do the multicasts).

I think it's somewhat relevant, as folks who aren't providing
immediate feedback might prefer to time-shift anyway, and if
they're time-shifting they could download higher-quality video
than can feasibly be transmitted using multicast, use different
video formats, etc.

currently we encode and source in two formats. mpeg-1 video w layer 2
audio and h.261 video and audio... by infeasable do you mean the bitrate
is to high? for talking heads/slides/regular motion I think the 1Mb/s
mpeg-1 streeam is more than adequate.

for archiving, which  we are working on now, the files are available in
mpeg-1 and a low bit-rate realvideo format. They'll be available as soon a
we  finish... ideally they'd be up as soon as we get done recording but
it's a bit hecktic while we're there. rebroadcasting the mpeg-1 source
time-delayed is a priority for london...

2. if we have a list of email addresses of multicast participants from
the last IETF, ask those folks how well it worked for them.

        Surveys of this type are hard to do, but it would be
        interesting to understand what worked. Extrapolating
        from that to what the user problem is, however, is
        likely impossible (after the fact), and so the data
        will be less useful that one might like.

again, it would provide at least some indication about how much this
facility is being used.

we have data, rtcp data isn't in our opinion extremely reliable however.
some clients don't provide feedback at all, and various network
environments seem to have a detrimental effect on our ability to get rtcp
back from all the joiners.


3. for the next meeting, update the IETF web pages to describe how to
attend the meeting via multicast - where to get the tools for your
particular platform, how to determine whether your ISP supports
multicast, and so on.

        Much of this information is available on
        http://videolab.uoregon.edu

thanks for the pointer.  perhaps the IETF web pages regarding meetings
could be updated to include that pointer, or the information from that site?

The multicast webpage (which has come down with the rest of the meeting
webpages had a link I beilve. There are a number of changes I want to make
to that webpage for the next time.

        Finally, its our (IETF) technology. If its not good
        enough for us to use, then we might want to think about
        what we're doing and why.

quite true.  though multicast is hardly alone in this regard.

      Its also important to note that
        for the 1-to-many case of IETF broadcast,  the problems
        that we face in todays multicast world will be somewhat
        eased by SSM deployment.

Keith


-- 
--------------------------------------------------------------------------
Joel Jaeggli                                   
joelja(_at_)darkwing(_dot_)uoregon(_dot_)edu
Academic User Services                       
consult(_at_)gladstone(_dot_)uoregon(_dot_)edu
     PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E
--------------------------------------------------------------------------
It is clear that the arm of criticism cannot replace the criticism of
arms.  Karl Marx -- Introduction to the critique of Hegel's Philosophy of
the right, 1843.