Re: [AVT] CORRECTION W/ RFC EDITOR NOTE: Protocol Action: RTP Payload Format for SMPTE 292M Video to Proposed Standard

[Magnus Westerlund <[e-mail]>]

Hi,

Okay, I understand. My main concern was that it is kind of step 
backwards in the goal to have reasonable reporting intervals for RTCP 
traffic. But I guess that this problem is solved as soon as AVPF is 
finished and published.

Best Regards

Magnus

Ladan Gharai wrote:

>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 [phone]
> > Torshamsgatan 23           | Fax   [phone]
> > S-164 80 Stockholm, Sweden | mailto: [e-mail]
> > 
> > 
> > 
> > _______________________________________________
> > Audio/Video Transport Working Group
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/avt
>
>_______________________________________________
>Audio/Video Transport Working Group
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/avt
>
>  
>

-- 

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]



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