Subject: RE: [AVT] Re: Errors in draft-ietf-avt-rtcp-bw-05.txt

From: "Peter Barany" <[email-masked]>
Date: Wed, 4 Jun 2003 10:27:47 -0500

Hi,

I may have missed something, but was there any closure on this series of
e-mails? Thanks.

Regards,

Pete

-----Original Message-----
From: Stephen Casner [mailto:[email-masked]]
Sent: Wednesday, May 21, 2003 12:18 PM
To: Magnus Westerlund
Cc: IETF AVT WG
Subject: Re: [AVT] Re: Errors in draft-ietf-avt-rtcp-bw-05.txt

[Note to other WG participants: I'd like to hear more opinions about
what we should do here.]

Magnus,

> I like the idea that Senders get there share of the total bandwidth. I
> think that work fine with the examples that I have. However I think I
> must actually ask the question: What happens the day one likes to turn
> of the senders and only have the receivers, i.e. RS=0 RR=5000?

If the senders are also receivers, then it is OK for them to still get
RTCP bandwidth.  It might be that this combination of parameters is
supposed to indicate that Sender Report information should not be
sent.  However, I don't think this makes sense.

> I don't need the functionality to turn of the senders. However I think
> the bw modifier draft should explicitly talk about this case and say
> that it is not supported by the underlying RTCP mechanism.

I agree that it would be reasonable to add a note about this.

> So your proposal is to change a section of draft-ietf-rtp-new-12 to the
> following:
...
> I think this change is for the better and at least clarify that part.
> However what do you intend with the other relevant sections of the RTP
> draft?
>
> I think there are two changes in the RTP draft that also needs to be made:
>
> 1. Update Section 6.3.1. Bullet 1.
> 2. Update the algorithm in A.7

I see two possibilities.  If this is considered a technical change
that is not allowed at this stage, we could finesse this problem by
adding a note in both places to say that the algorithm as stated is
for the normal RTCP bandwidth allocation and must be modified if
explicit RTCP bandwidth parameters are implemented.  The justification
for this would be that the RTP spec does not define the parameters
itself, it just says profiles MAY do so.

If there is not an objection to making a more-than-editorial change,
we can remove the senders > 0 condition in both places and fix the
"senders and receivers are treated together" phrase in 6.3.1.  I don't
want to go as far as what you have proposed in modifications to A.7
because this changes the function signature which means it also needs
to be changed in other places; instead, I would leave the fraction
fixed 25%, and simply remove the senders > 0 condition.  I would add
to the comment that a check must be added to avoid division by zero if
the sender fraction is changed to 100% or parameterized.

> > I have to admit some concern here because we are also trying to get RFC
> > numbers on an accelerated basis at the request of the ITU.
>
> If we propose these changes so that the protocol is at least as
> restricted in BW behavior I can't see major problems with the IESG.

That is not the issue.  If the RFC Editor feels this change would
require discussion by the IESG, then that is already a problem for
delay.

> Sure it is not good that it has taken this long to find this
> problem.  I guess this is the result of that no one has tried to
> apply the RTCP SDP bw modifier draft before. Which shows that
> implementation helps finding a lot of bugs.

Yes, that is certainly true.

> However to continue the work, I have below provided a proposal for the
> A.7 code. I think that we should simply remove the senders=0 part. Then
> in cases the S/(R+S) rules kicks in the receivers will only get RR
> divided by the total nr. of participants. This will result in a
> underutilization of the total RTCP bandwidth.

Yes, but that is a straightforward consequence of the decision to
dedicate a portion of the bandwidth to senders, and I believe it is
acceptable.  Does it make sense to have an RTP session with no data
senders?  And when no data is sent, then there is not much for
receivers to say in RTCP, either.  I suppose if RTCP were being used
on its own for a scalable-timer-based entity identification protocol,
perhaps with some other RTCP packet types defined, then this could
make some sense.  But in that case, the RS=0 and RR=n parameters can
be used to control the RTCP bandwidth at the desired level.  In fact,
if there is no data, then the concept of RTP session bandwidth is not
defined, so you'd have to be explicit about the RTCP bandwidth.

                                                        -- Steve

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt