[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] CORRECTION W/ RFC EDITOR NOTE: Protocol Action: RTP Payload Format for SMPTE 292M Video to Proposed Standard
Hello Magnus: Please see notes inline.
Ladan
> Hi,
>
> I reacted on the below in the RFC editors note that the IESG wrote.
>
>
> The IESG wrote:
>
> >**PLEASE NOTE RFC EDITOR NOTE.**
> >RFC Editor: please make the following changes before publishing this ID
> >
> > Section 6, 1st paragraph
> > OLD:
> >
> > RFC1889 recommends transmission of RTCP packets every 5 seconds or at a
> > reduced minimum in seconds of 360 divided by the session bandwidth in
> > kilobits/second. At 1.485 Gbps the reduced minimum interval computes to
> > 0.2ms or 4028 packets per second.
> >
> > NEW:
> >
> > RTCP SHOULD be used as specified in RFC1889[3], which specifies two
> > limits on the RTCP packet rate: RTCP bandwidth should be limited to 5%
> > of the data rate, and the minimum for the average of the randomized
> > intervals between RTCP packets should be 5 seconds. Considering the
> > high data rate of this payload format, the minimum interval is the
> > governing factor in this case.
> >
> > Section 13, 3rd and 4th paragraphs:
> > OLD:
> >
> > [3] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, "RTP: A
> > Transport Protocol for Real-Time Applications", IETF, Work in
> > Progress (draft-ietf-avt-rtp-new-11.txt)
> >
> > [4] H. Schulzrinee and S. Casner, "RTP Profile for Audio and Video
> > Conferences with Minimal Control", IETF, Work in progress,
> > (draft-ietf-avt-profile-new-12.txt).
> >
> > NEW:
> >
> > [3] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, "RTP: A
> > Transport Protocol for Real-Time Applications", IETF, January 1996,
> > RFC1889.
> >
> > [4] H. Schulzrinne and S. Casner, "RTP Profile for Audio and
> > Video Conferences with Minimal Control", IETF, January 1996,
> > RFC1890.
> >
> >
>
> I know that the referenced rule in the old text relies on one of the
> updates in the RTP spec about alternative minimal packet distances. So
> if it needs to be published now it can't have the old text. However I
> think that using the standard 5 seconds rule is rather useless from a
> RTCP usage point of view. In a payload format for sending 1.5 Gbit video
> data per second, a lot of packets will be sent during 5 seconds. So the
> intention of the SHOULD in the new text seems to me, to be not followed
> at all. In fact it seems that is should be actually be followed by
> recommendation to use a shorter minimal interval. But that interval
> shall not be shorter than what 360*1000/bitrate would give.
>
> So I question if this really is a good edit. Would it not be better to
> clearly point out that another minimal interval than 5 seconds is
> recommended to be used. Either through a new text not relying on the
> updated RTP spec or actually refer to the new spec and let the
> publication hang until RTP as draft standard is published.
>
> I guess that people actually going to use this format should give their
> opinion. From a RTP usage perspective I think this format is a case that
> really needs another minimal packet interval than 5 seconds and should
> not be published with the proposed new text.
The average five second interval is sufficient for the purposes of
keeping track of the cumulative number of packets lost and the sender's
octet count, from the draft:
"It should be noted that the sender's octet count in SR packets wraps
around in 23 seconds, and that the cumulative number of packets lost
wraps around in 93 seconds. This means these two fields cannot accurately
represent octet count and number of packets lost since the beginning of
transmission, as defined in RFC1889. Therefore for network monitoring
purposes or any other application which requires the sender's octet count
and the cumulative number of packets lost since the beginning of
transmission, the application itself must keep track of the number of
rollovers of these fields via a counter."
However, should an application require a finer interval for the RTCP
reports, it can do so as specified in the new RTP profile, (as would any
other RTP application).
>
> 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: magnus.westerlund@era.ericsson.se
>
>
>
> _______________________________________________
> 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