[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ssm] Re: draft-chesterfield-avt-rtcpssm



On Thu, Jul 07, 2005 at 05:57:00PM -0400, Julian Chesterfield wrote:
> Toerless,
> 
> On 7 Jul 2005, at 11:49, Toerless Eckert wrote:
> 
> >On Thu, Jul 07, 2005 at 10:21:15AM +0200, Joerg Ott wrote:
> >>>Sure, I understand that. But from my reading, this draft *does* refer
> >>>explicitly to SSM rather than just "multicast" -- what needs to be
> >>>changed?
> >>
> >>To add to this, draft-ietf-avt-rtcpssm also discusses how
> >>non-aggregatable RTCP messages shall be treated.  Thus, it is 
> >>explicitly
> >>designed to also support RTCP feedback in SSM environments--obviously
> >>at some loss of damping efficiency but what would you expect if you
> >>double propagation delay.
> >
> >I was saying:
> >>Thanks, Colin,
> >>
> >>Just as a general critique: I don't think that a draft like
> >>draft-ietf-avt-rtcp-feedback should go forward without specifically
> >>detailing whether or how it supports ASM and/or SSM multicast. This 
> >>draft
> >>only refers to multicast, and that is just not sufficient anymore.
> >
> >eg: different draft! But one which i think relates quite a bit to the
> >issue at hand as well and should not become an RFC without explicitly
> >mentioning ASM and SSM (which it does not).
> 
> Please read the latest version of the draft. The introduction goes into 
> great detail about the ASM and SSM communication models, and associated 
> protocols.

% grep SSM draft-ietf-avt-rtcp-feedback-11.txt
<nothing>

% grep ASM draft-ietf-avt-rtcp-feedback-11.txt
<nothing>

hmmm...


> >I for once fail to easily determine from the claims of support whether
> >one could use the mechanisms described therein with SSM (i think not),
> 
> again, the introduction discusses three scenarios where the mechanism 
> would be appropriate. The first scenario is an SSM group. The scheme is 
> designed towards SSM groups in particular on the basis that an SSM 
> group can support multicast downstream, and unicast back to the source.

> >nor do i understand easily whether it would be possible to use them 
> >with
> >SSM if combined with draft-ietf-avt-rtcpssm without further extensions.
> 
> What extensions would be required to make this work over an SSM 
> architecture?

re-read my email ? ;-)) I am concerned about any other draft extending
the use of RTCP (and that happens quite a bit via for example 
as i mentioned "draft-ietf-avt-rtcp-feedback" and other relying on
that draft, like RTP retransmissions) - All those folks i think are
aboslutely NOT considerin whether and/or how their stuff would work
with multicast SSM, and i am saying that each draft that extends RTP
needs to explicitly mention it's aplicability claim to ASM and SSM
(claims to support ASM and/or SSM), and NOT claim anymore simply
"does also support multicast").

Cheers
	Toerless

_______________________________________________
ssm mailing list
ssm@ietf.org
https://www1.ietf.org/mailman/listinfo/ssm