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

From: The IESG <[email-masked]>
Date: Mon, 20 Jan 2003 15:06:49 -0500

**PLEASE NOTE RFC EDITOR NOTE.**

The IESG has approved the Internet-Draft 'RTP Payload Format for SMPTE 
292M Video' <draft-ietf-avt-smpte292-video-08.txt> as a Proposed 
Standard. This document is the product of the Audio/Video Transport 
Working Group. The IESG contact persons are Scott Bradner and Allison 
Mankin.

Technical Summary
   
This document specifies a RTP payload format for encapsulating 
uncompressed High Definition Television (HDTV) as defined by the 
Society of Motion Picture and Television Engineers (SMPTE) standard, 
SMPTE 292M. SMPTE is the main standardizing body in the motion imaging 
industry and the SMPTE 292M standard defines a bit-serial digital 
interface for local area HDTV transport and defines a universal medium 
of interchange for uncompressed High Definition Television (HDTV) 
between various types of video equipment (cameras, encoders, VTRs, 
etc.). SMPTE 292M stipulates that the source data be in 10 bit words 
and the total data rate be either 1.485 Gbps or 1.485/1.001 Gbps.

The use of a dedicated serial interconnect is appropriate in a studio
environment, but it is desirable to leverage the widespread 
availability of high bandwidth IP connectivity to allow efficient wide 
area delivery of area delivery of SMPTE 292M format content. This memo 
defines a way to do so.
   
Working Group Summary
   
The AVT working group supported publication of this document on the
standards track.
   
Protocol Quality
  
This document was reviewed for the IESG by Scott Bradner.

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.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 21 Jan 2003 10:47:18 +0100

Hi,

I reacted on the below in the RFC editors note that the IESG wrote.

>         Video Conferences with Minimal Control", IETF, January 1996,

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.

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]

---

From: Ladan Gharai <[email-masked]>
Date: Wed, 22 Jan 2003 16:37:57 -0500

Hello Magnus: Please see notes inline.

Ladan

 > 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).

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 23 Jan 2003 09:15:39 +0100

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

-- 

Magnus Westerlund