Subject: [AVT] Comments on draft-ietf-avt-rtcpssm-01.txt

From: Magnus Westerlund <[email-masked]>
Date: Mon, 08 Jul 2002 17:37:58 +0200

Hi,

Here is a couple of comments on the draft:

Section 6.3
Should reference that the b=RR (draft-ietf-avt-rtcp-bw-05.txt which is 
approved for publication) attribute can be used for specifying the 
receiver RTCP bandwidth.

Section 7.1.1. Timestamp
This is a 32 bit field which does not specify how the NPT time should be 
represented. Is it seconds only or rather the lowest 16 bit seconds and 
the highest 16 bit fraction numbers as in RTCP receiver reports?

Receiver bandwidth:
Is that field really necessary? To my knowledge it can be calculated as 
1/(group_size-senders). The number of senders is evident from the data 
traffic.

Section 7.1.2 First paragraph.
It would be clearer it the first sentence specify that the number of 
report blocks is zero to 31 instead of zero or more.

Section 7.1.3
All the four types of report blocks are lacking clear definitions on 
what should go into the buckets. My assumption is that each bucket 
contains the number of receiver which has reported a value within the 
buckets value range. Also a better language could be used to clearly 
explain that a bucket contains a unsigned positive integer of 
((length*4)-12)*8/NDB bits. That the buckets are uniformly distributed 
over the range min to max distribution values should be made explicit. 
Also rules for rounding and use of the multiplicative factor should be 
expressed for each report block.

Also is the SSRC distribution block of any use at all?

Section 10.1
- The attributes must use another name as this would conflict with the 
a=rtcp:<port> specified by draft-ietf-mmusic-sdp4nat-02.txt.
- A BNF definition may not be necessary due to the simple characteristic 
of the attributes but could help clarify.
- Is the attributes really session level only? Shouldn't the RTCP 
traffic be specified for RTP/RTCP session and by virtue of that having 
the attributes as media level ones also?

Section 12.
The IANA section must clearly specify how the GSR packet type IANA 
registry should work. Which requirements is there one a registration, 
IETF specification, other specification, etc.? You would not register 
four attributes rather a single one with a number of parameters.

Regards

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

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

---

From: Julian Chesterfield <[email-masked]>
Date: Tue, 09 Jul 2002 16:19:39 -0700

Magnus,

Thanks for the comments, some text included inline...

> the highest 16 bit fraction numbers as in RTCP receiver reports?

We'll clarify this in the text, it is intended to be 32-bit NTP timestamp
format with the low 16 bits of the integer part and high 16 bits of the
fractional part.

> 1/(group_size-senders). The number of senders is evident from the data

The reason for this additional field was from a request to provide a
facility for a data streaming client to mask the actual size of the group,
e.g. for commercial purposes, the number of listeners may be sensitive
info. A second reason was that for well-connected data sources that can
handle higher levels of feedback traffic, it provides a facility to
increase the data rate at which each member can report.

I think that we definitely need to include more information about how it
should be used, and what the rules are for deciding which field has
precedence over the reporting interval calculation.

> Also is the SSRC distribution block of any use at all?

That's an issue that we've been discussing also. The original reasons for
including it were:

    for a management application or feedback identifier that may wish to
use an alternative group management strategy based on SSRC values.
Receivers in the group might be required to set their own SSRC for the
purposes of controlling the division of the receiver set into sub
management groups, e.g. electing a sub-group leader, or joining a specific
sub-group, the receiver set may need to have access to the SSRC
distribution knowledge.
    for applications that do not use a totally random SSRC generator value,
the effects of sampling techniques on group size estimation and RTCP data
parsing could be compromised causing incorrect values and the potential for
implosion problems as groups grow very large. Knowledge of the distribution
might provide useful input to such algorithms to avoid problems.

The SSRC distribution was included therefore in the draft as a potentially
useful value to report, although we're undecided about whether this
warrants inclusion.

> four attributes rather a single one with a number of parameters.

I'll get back to you about 10.1 and section 12.

Thanks,
Julian Chesterfield