Re: [AVT] RTP: Note regarding SSM

[Marshall Eubanks <tme@multicasttech.com>]

Dear Mark;

On Wednesday, January 8, 2003, at 12:22 PM, Mark Baugher wrote:

> At 06:10 AM 1/8/2003 -0500, Marshall Eubanks wrote:
> > Dear Stephen;
> >
> > On Tuesday, January 7, 2003, at 06:20  PM, Stephen Casner wrote:
> >
> > > One of the IESG comments (this one from Harald Alvestrand) was a
> > > request to add the following "non-normative note" at the end of
> > > Section 6 where RTCP is introduced (i.e., just before 6.1).  Does
> > > anyone object?
> > >
> > > Non-normative note:  In the multicast routing approach
> > > called Source-Specific Multicast (SSM), only one or a few
> >
> > I do not like "a few" here. There is one sender per channel. True, there
> > can be multiple channels, but then it is not limited to "a few", and, of course,
> > there is nothing stopping the receivers from sending on their own channel.
> >
> > I would change this sentence to
> >
> > In the multicast routing approach called Source-Specific Multicast (SSM), there is only
> > one sender per "channel" (source - group pair), and receivers cannot use multicast
> > to communicate directly with other channel members.
>
> I think this sentence is a good replacement.  It might be more clear to write "source address, group address pair" in 

I agree

> place of "source - group pair" and replace "other channel members" with "members of a channel having a source address other than its own."

This does not sound too clear, and is not quite correct - a receiver can have more than IP address - 

How about 

In the multicast routing approach called Source-Specific Multicast (SSM), there is only
one sender per "channel" (a source address, group address pair), and receivers 
(except for the channel source) cannot use multicast
to communicate directly with other channel members.

Marshall

> Mark
>
>
> > > senders send multicast data, and receivers may not send
> > > multicast.  The recommendations here accommodate SSM only
> > > through Section 6.2's option of turning off receivers' RTCP
> > > entirely.  Future work will specify adaptation of RTCP for
> > > SSM so that feedback from receivers can be maintained.
> > >
> > > -- Steve
> > >
> > > _______________________________________________
> > > Audio/Video Transport Working Group
> > > avt@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/avt
> >                                  Regards
> > Marshall Eubanks
> >
> > T.M. Eubanks
> > Multicast Technologies, Inc.
> > 10301 Democracy Lane, Suite 410
> > Fairfax, Virginia 22030
> > Phone : 703-293-9624       Fax     : 703-293-9609
> > e-mail : tme@multicasttech.com
> > http://www.multicasttech.com
> >
> > Test your network for multicast :
> > http://www.multicasttech.com/mt/
> > Status of Multicast on the Web  :
> > http://www.multicasttech.com/status/index.html
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > avt@ietf.org
> > https://www1.ietf.org/mailman/listinfo/avt
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
                                 Regards
Marshall Eubanks

This e-mail may contain confidential and proprietary information of 
Multicast Technologies, Inc, subject to Non-Disclosure Agreements


T.M. Eubanks
Multicast Technologies, Inc
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624       Fax     : 703-293-9609
e-mail : tme@multicasttech.com
http://www.multicasttech.com

Test your network for multicast : 
http://www.multicasttech.com/mt/
Status of Multicast on the Web  :
http://www.multicasttech.com/status/index.html