Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05

From: Magnus Westerlund <[email-masked]>
Date: Mon, 9 Sep 2013 16:07:50 +0200

WG,

As author I would really appreciate some reviews that the content are
appropriate. Thus I really appreciate responses even of the type. "Read
it, no issues spotted".

Don't assume that I am without flaws in my writing ;-).

Cheers

Magnus

On 2013-08-22 10:58, Ali C. Begen (abegen) wrote:
> (As a WG co-chair)
> 
> I am starting WGLC for the following draft (version 05). 
> https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-howto/
> 
> This is an important document as it outlines how someone is supposed to write the payload specs.
> 
> If there are sections you don't understand or that are not clear enough, etc. please post them to the list. We need to get this right to minimize further headaches for future documents in our WG.
> 
> The deadline for the WGLC is September 20th.
> 
> -acbegen
> _______________________________________________
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload
> 
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Qin Wu <[email-masked]>
Date: Tue, 10 Sep 2013 07:01:01 +0000

Hi, Magnus:
I have read this document and it looks good. 
Here are a few minor comments:
1. Section 7
Section 7 discusses four special consideration including
a. Media Format description
b. Security Considerations
c. Congestion Control
d. IANA Consideration
However it looks to me Media Format description or Congestion Control
Is not important or could be optional sections that need to be described 
comparing with Security and IANA Considerations Section 
Since  Section 7, 1st paragraph said:
"
These include the Security and IANA
 Considerations sections.
"
Also Section 7.1 seems just repeat what A.7 section said.

2.Section 7.2, 3rd paragraph:
Suggest the following change:
OLD TEXT:
"
That the decoding of the payload format or its media shows
substantial non-uniformity, either in output or in complexity to
perform the decoding operation.  
"
NEW TEXT:
"
The decoding of the payload format or its media shows
substantial non-uniformity, either in output or in complexity to
perform the decoding operation.  
"
3. Section 7.2, 3rd paragraph:
What does "goodput" mean? Good output? 

4.Section 7.4, 2nd paragraph, 2nd sentence
It looks this sentence is disconnected from the 1st sentence.
Suggest the following change:
OLD TEXT:
"
Independently the format of these should be such that they can be
   included in the SDP attribute "a=fmtp" string (See Section 6
   [RFC4566]) which is the common mapping.  
"
NEW TEXT:
"
These parameters are independent of the format of these should be
such that they can be included in the SDP attribute "a=fmtp" string (See Section 6
[RFC4566]) which is the common mapping.  
"

Regards!
-Qin
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: Monday, September 09, 2013 10:08 PM
To: [email-masked]
Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05

WG,

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 10 Sep 2013 10:51:25 +0200

Many Thanks for the review.

See inline for comments.

> These include the Security and IANA

So the Security and IANA are required for all drafts. The Media format
description I would recommend to ensure that people can understand the
important feature of the codec. Congestion control discussion is not
mandated by other procedures, but I at least thinks payload formats
really should include them. I would propose tweaking the section 7
introduction to say:

A number of sections in the payload format draft need special
consideration. These include the Security and IANA Considerations
sections that are required in all drafts. Payload formats are also
strongly recommended to have the media format description and congestion
control considerations.

Better?

> Also Section 7.1 seems just repeat what A.7 section said.

Ok, I think it is important to have the text that is present in A.7 as
it provides template instruction. What may need to consider is if the
text in 7.1 should contain anything additionally. Nothing springs to
mind immediately. I don't see the repetition as a major issue as it is
within the body vs within the template.

> perform the decoding operation.  

Maybe this works better:

Potential security issues with an RTP payload format and the media
encoding that needs to be considered if they are applicable:

1. The decoding of the payload format or its media results in
substantial non-uniformity, either in output or in complexity to perform
the decoding operation.

> What does "goodput" mean? Good output? 

Ahaa, goodput is how much actual usable (good) results that are produced.

See: http://en.wikipedia.org/wiki/Goodput

Maybe this is clearer:
Such inputs can cause some sort of disruption, i.e. a denial of service
attack on the receiver side by preventing that host from performing
usable work.

> [RFC4566]) which is the common mapping.  

Actually, independently are just confusing here. I think simplification to:

The format of these parameter should be such that they can be included
in the SDP attribute "a=fmtp" string ...

Is the right way to go.

Once more,

Thanks for the review.

Magnus Westerlund

---

From: Qin Wu <[email-masked]>
Date: Tue, 10 Sep 2013 09:01:43 +0000

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Tuesday, September 10, 2013 4:51 PM
To: Qin Wu
Cc: [email-masked]
Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05

See inline for comments.

Better?

[Qin]: That is the change I am looking for, thanks.

[Qin]: I can live with this, thanks for your clarification.

Maybe this works better:

[Qin]:Your proposed change addresses my comment, thanks.

Maybe this is clearer:

[Qin]: Looks good to me, thanks for taking my comment into account.

[Qin]: Make sense, thanks.

Is the right way to go.

Once more,

Thanks for the review.

Magnus Westerlund

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 12 Sep 2013 11:49:37 -0400

One point that's not mentioned in this document, but which might be worth bringing up, is the conventions on how you choose a payload format's clock rate.

I.e., the fact that clock rates are conventionally 90000 Hz for video (and we should give some background as to why), and they're conventionally the sampling rate for audio.

It might also be worth discussing the benefits of the Opus clock rate approach (always use the maximum supported clock rate, i.e., 48000 Hz), vs. the conventional one, in the context of the multiple-clock-rates draft.

--
Jonathan Lennox
[email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Thu, 12 Sep 2013 18:04:04 +0100

> The deadline for the WGLC is September 20th.

I think this is an important draft, and I'm glad to see it progressing. It seems to be generally well written and containing good advice. I have some number of comments, but these are generally all minor points:

- In Section 3.1.2 the discussion of RFC 6015 mentions RFC 2733, but RFC 2733 hasn’t been cited or discussed

- In Section 3.1.2 the discussion of RFC 3611 might usefully point to the IANA registry for XR blocks and the XRBLOCK working group

- Section 3.2: the introduction to this section could be clearer that this is an overview of RTP features that are available independent of the payload format, and not a list of things that the payload format needs to explicitly opt in to/out of.

- Section 3.2.2 expands SSRC as “Sender Source Identifier” but this should be “Synchronisation Source Identifier”.

- In Section 3.2.2 the statement “[RFC5285] specifies how to extend the RTP header to carry metadata relating to the payload” is potentially misleading, since the type of information that usually goes into an RTP payload header is also “metadata relating to the payload”. It might be useful to expand this discussion slightly, to make the distinction clear.

- In Section 3.2.2, it might be useful to explain that video payload formats are a common example of “payload formats with a timestamp definition which results in no or little correlation between the media time instance and its transmission time”; otherwise this sounds like such payload formats are something unusual.

- In Section 3.2.2, would it be helpful to explain typical RTP timestamp and sequence number behaviour when using discontinuous transmission?

- In Section 3.2.2, when talking about the RTP timestamp, it might be appropriate to reference to leap-seconds draft

- In Section 3.2.2, when talking about payload type numbers, it might be useful to be explicit that the binding is dynamic, and that other out-of-band configuration information in addition to the payload type to payload format binding is usually needed to understand a payload format. Reference Section 3.3.

- Should Section 3.2.3 reference the multiplex-guidelines or transport-multiplexing drafts?

- Section 3.2.4 says “SSRCs with the same CNAME in different RTP sessions can be synchronized”; this is also true of flows with different SSRC but the same CNAME within an RTP session. 

- Section 3.4: should this say anything about AQM and/or QoS support?

- Section 4 might be clearer titled “Standardisation Process for an RTP Payload Format”

- Section 4 “registration of the RTP payload format name” – how does this relate to the “media type” discussed in Section 3.3?

- The discussion of SST and MST in Section 5.1.5 seems to confuse sessions with SSRCs. Isn’t it more important whether the layers are sent within a single RTP media stream, or as separate RTP media streams with different SSRC values? Whether the different SSRCs are sent in one RTP session of many is then a separate issue, depending on how easily one wants to be able to separate the flows for QoS purposes.

- In Section 5.1.6, avoiding wrap-around within the RTCP reporting timeout interval is also important.

- The introduction to Section 7 could usefully reference the template payload format.

- Appendix A.10: mention that the RTP circuit breaker ought to be used and respected?

-- 
Colin Perkins
http://csperkins.org/

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 13 Sep 2013 10:07:05 +0200

Hi Jonathan,

Thanks for the review.

On 2013-09-12 17:49, Jonathan Lennox wrote:
> One point that's not mentioned in this document, but which might be
> worth bringing up, is the conventions on how you choose a payload
> format's clock rate.
> 
> I.e., the fact that clock rates are conventionally 90000 Hz for video
> (and we should give some background as to why), and they're
> conventionally the sampling rate for audio.
> 
> It might also be worth discussing the benefits of the Opus clock rate
> approach (always use the maximum supported clock rate, i.e., 48000
> Hz), vs. the conventional one, in the context of the
> multiple-clock-rates draft.

Agreed, this should be better covered. I propose to add a new
sub-section in Section 5 covering this subject. I have therefore been
able to shorten the timestamp text in Section 3.2.2 to:

   Timestamp:  The RTP timestamp indicates the time instance the media
      sample belongs to.  For discrete media like video, it normally
      indicates when the media (frame) was sampled.  For continuous
      media it normally indicates the first time instance the media
      present in the payload represents.  For audio this is the sampling
      time of the first sample.  All RTP payload formats must specify
      the meaning of the timestamp value and the clock rates allowed.
      Selecting Timestamp rate is an active design choice and is further
      discussed in Section 5.2.

and remove a whole paragraph in Section 6.1: Audio Payloads

5.2.  Selecting Timestamp Definition

   The RTP Timestamp is an important part and have two design choices
   associated with it.  The first is the definition that determines what
   the timestamp value in a particular RTP packet will be, the second is
   which timestamp rate should be used.

   The timestamp definition needs to explicitly define what the
   timestamp value in the RTP packet represent for a particular payload
   format.  Two common definitions are used; for discretely sampled
   media, like video frames, the sampling time of the earliest included
   video frame which the data represent (fully or partially) is used;
   for continuous media like audio, the sampling time of the earliest
   sample which the payload data represent.  There exist cases where
   more elaborate or other definitions are used.

   RTP payload formats with a timestamp definition which results in no
   or little correlation between the media time instance and its
   transmission time cause the RTCP jitter calculation to become
   unusable due to the errors introduced on the sender side.  Such
   examples are for example payload formats for video that requires
   multiple packets, where a set of packets will have the same
   timestamp, another are payloads that includes alternating set of
   redundant information, if the definition used are for the earliest
   data included, the the timestamp may jump back and forth.  It should
   be noted if the payload format has this property or not.

   A RTP payload format also needs to define what timestamp rates, or
   clock rates (as it is also called), that may be used.  Depending on
   the RTP payload format this may be a single rate or multiple ones or
   theoretically any rate.  So what needs to be considered when
   selecting rate?

   The rate needs be selected so that one can determine where in the
   timeline of the media a particular sample (e.g. individual audio
   sample, or video frame) or set of samples (e.g. audio frames) belong.
   To enable correct synchronization of this data with previous frames,
   including over periods of discontinuous transmission or
   irregularities.

   For audio it is common to require audio sample accuracy.  Thus one
   commonly selects the input sampling rate to the code.  This can
   however be challenging for for audio codecs that support multiple
   different sampling frequencies, either as codec input or being used
   internally but effecting output, for example frame duration.
   Depending on how one expects to use these different sampling rates
   one can allow multiple timestamp rates, each matching a particular
   codec input or sampling rate.  However, due to the issues with using
   multiple different RTP timestamp rates for the same source (SSRC)
   [I-D.ietf-avtext-multiple-clock-rates] this should be avoided if one
   expects to need to switch between modes.

   An alternatives then is to find a common denominator frequency
   between the different modes, e.g. OPUS [I-D.ietf-payload-rtp-opus]
   that uses 48 KHz.  If the different modes uses or can use a common
   input/output frequency then selecting this also needs to be
   considered.  However, it is important to consider all aspects as the
   case of AMR-WB+ [RFC4352] illustrates.  AMR-WB+'s RTP timestamp rate
   has the very unusual value of 72 kHz, despite the fact that output
   normally is at a sample rate of 48kHz.  The design is motivated by
   the media codec's production of a large range of different frame
   lengths in time perspective.  The 72 kHz timestamp rate is the
   smallest found value that would make all of the frames the codec
   could produce result in an integer frame length in RTP timestamp
   ticks.  This way, a receiver can always correctly place the frames in
   relation to any other frame, even when the frame length changes.  The
   downside is that the decoder outputs for certain frame lengths is in
   fact partial samples.  The result is that the output in samples from
   the codec will vary from frame to frame, potentially making
   implementation more difficult.

   Video codecs has commonly been using 90 kHz, the reason is this is a
   common denominator between the usually used frame rates such as 24,
   25, 30, 50 and 60, and NTSC's odd 29.97 Hz.  There does however exist
   at least one exception in the payload format for SMPTE 292M video
   [RFC3497] that uses a clock rate of 148.5 Mhz. The reason here is
   that the timestamp then identify the exact start sample within a
   video frame.

   Timestamp rates below 1000 Hz are not appropriate because it will
   cause a too low resolution in the RTCP measurements that are
   expressed in RTP timestamps.  This is the main reason that the text
   RTP payload formats, like T.140 [RFC4103] uses 1000 Hz.
>> If there are sections you don't understand or that are not clear
>> enough, etc. please post them to the list. We need to get this
>> right to minimize further headaches for future documents in our
>> WG.
>> 
>> -acbegen _______________________________________________ payload
>> mailing list [email-masked] 
> -- Jonathan Lennox [email-masked]
> 
> 
> _______________________________________________ payload mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/payload
> 
> 

-- 

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Sat, 21 Sep 2013 13:56:41 +0200

Hi,

Thanks for the review comments. I have tried addressing them. I am
submitting an updated draft including these edits. But, I do need
feedback on these edits.

See below.

On 2013-09-12 19:04, Colin Perkins wrote:
> I think this is an important draft, and I'm glad to see it
> progressing. It seems to be generally well written and containing
> good advice. I have some number of comments, but these are generally
> all minor points:
> 

Correct, I added a reference in RFC 5109 text to state that this
replaced RFC 2733, and added as references in both places.

   RFC 5109:  The "RTP Payload Format for Generic Forward Error
      Correction (FEC)" [RFC5109] provides an XOR based FEC of the whole
      or parts of a number of RTP packets.  This specification replaced
      the previous specification for XOR based FEC [RFC2733].  These FEC
      packets are sent in a separate stream or as a redundant encoding
      using RFC 2198.  This FEC scheme has certain restrictions in the
      number of packets it can protect.  It is suitable for low-to-
      medium delay tolerant applications with limited amount of RTP
      packets.

   RFC 6015:  The "RTP Payload Format for 1-D Interleaved Parity Forward
      Error Correction (FEC)" [RFC6015] provides a variant of the XOR
      based Generic protection defined in [RFC2733].  The main
      difference is to use interleaving scheme on which packets gets
      included as source packets for a particular protection packet.
      The interleaving is defined by using every L packets as source
      data.  And then produce protection data over D number of packets.
      Thus each block of D x L source packets will result in L number of
      Repair packets, each capable of repairing one loss.  The goal is
      to provide better burst error robustness when the packet rate is
      higher.

> 
> - In Section 3.1.2 the discussion of RFC 3611 might usefully point to
> the IANA registry for XR blocks and the XRBLOCK working group

   RFC 3611:  The RTCP Extended Reports (RTCP XR) [RFC3611] consists of
      a framework for reports sent within RTCP.  It can easily be
      extended by defining new report formats, which has occurred.  The
      list of specified formats are available in IANA's RTCP XR Block
      Type registry (http://www.iana.org/assignments/rtcp-xr-block-types
      /rtcp-xr-block-types.xhtml).  The report formats that are defined
      in RFC3611 provide report information on packet loss, packet
      duplication, packet reception times, RTCP statistics summary and
      VoIP Quality.  [RFC3611] also defines a mechanism that allows
      receivers to calculate the RTT to other session participants when
      used.

> 
> - Section 3.2: the introduction to this section could be clearer that
> this is an overview of RTP features that are available independent of
> the payload format, and not a list of things that the payload format
> needs to explicitly opt in to/out of.

This section reviews a number of RTP features and concepts that are
available in RTP independent of the payload format. The RTP payload
format can make use of these when appropriate, and in some cases even
effect the behavior (RTP Timestamp and marker bit). This section does
not remove the necessity to read up on RTP. However it does point out a
few important details to remember when designing a payload format.

> 
> - Section 3.2.2 expands SSRC as “Sender Source Identifier” but this
> should be “Synchronisation Source Identifier”.

Note that I also change the fourth line to say "of multiple media
sources" rather than "from multiple senders.

   SSRC:  The Synchronisation Source Identifier (SSRC) is normally not
      used by a payload format other than to identify the RTP timestamp
      and sequence number space a packet belongs to, allowing
      simultaneously reception of multiple media sources.  However, some
      of the RTP mechanisms for improving resilience to packet loss uses
      multiple SSRCs to separate original data and repair or redundant
      data.

> 
> - In Section 3.2.2 the statement “[RFC5285] specifies how to extend
> the RTP header to carry metadata relating to the payload” is
> potentially misleading, since the type of information that usually
> goes into an RTP payload header is also “metadata relating to the
> payload”. It might be useful to expand this discussion slightly, to
> make the distinction clear.

Is this better?

   Header extensions:  Payload formats normally specifies the carrying
      of meta data related to the media payload in the payload header.
      In some cases the meta data may be more generic, e.g. relevant
      more to the media type (e.g. audio or video), or RTP packets in
      general.  In those cases the carrying of this additional meta data
      can be specified in a header extension.  One example is the
      transport of SMPTE time-codes in the RTP header [RFC5484].  As
      [RFC5285] specifies, header extensions must not contain
      information required in order to decode the payload successfully.

> 
> - In Section 3.2.2, it might be useful to explain that video payload
> formats are a common example of “payload formats with a timestamp
> definition which results in no or little correlation between the
> media time instance and its transmission time”; otherwise this sounds
> like such payload formats are something unusual.

This discussion got moved into the new section 5.2, where the related
text says:

Good enough?

> 
> - In Section 3.2.2, would it be helpful to explain typical RTP
> timestamp and sequence number behaviour when using discontinuous
> transmission?

      Discontinuous transmissions (DTX) that is common among speech
      codecs, typically results in gaps or jumps in the timestamp values
      due that there are no media payload to transmit and the next used
      timestamp value represent the actual sampling time of the data
      transmitted.

   Sequence number:  The sequence number is monotonically increasing and
      is set as the packet is sent.  This property is used in many
      payload formats to recover the order of everything from the whole
      stream down to fragments of application data units (ADUs) and the
      order they need to be decoded.  Discontinuous transmissions does
      not result in gaps in the sequence number, as it is monotonically
      increasing for each sent RTP packet.

> 
> - In Section 3.2.2, when talking about the RTP timestamp, it might be
> appropriate to reference to leap-seconds draft

I chose to add a paragraph on this in Section 3.2.4

   Leap Seconds are extra seconds added or seconds removed to keep our
   clocks in sync with earths rotation.  Adding or removing seconds can
   impact first of all the reference clock as discussed in "RTP and Leap
   Seconds" [I-D.ietf-avtcore-leap-second].  But also in cases where the
   RTP timestamp value are derived using the wall clock during the leap
   second event errors can occur.  Implementations needs to consider
   leap seconds and should consider the recommendations in
   [I-D.ietf-avtcore-leap-second].

> 
> - In Section 3.2.2, when talking about payload type numbers, it might
> be useful to be explicit that the binding is dynamic, and that other
> out-of-band configuration information in addition to the payload type
> to payload format binding is usually needed to understand a payload
> format. Reference Section 3.3.

   Payload Type:  The payload type is used to indicate on a per packet
      basis which format is used.  The binding between a payload type
      number and a payload format and its configuration are dynamically
      bound and RTP session specific.  The configuration information can
      be bound to a payload type value by out-of-band signalling
      (Section 3.3).  An example of this would be video decoder
      configuration information.  Commonly the same payload type is used
      for a media stream for the whole duration of a session.  However
      in some cases it may be necessary to change the payload format or
      its configuration during the session.

> transport-multiplexing drafts?

I think the multiplexing guidelines makes sense. The transport
multiplexing being focused on providing a specific solution to one
combination of RTP sessions to transport mapping appears to specific.

I added the following last in the section.

   For more discussion and consideration of how and when to use the
   different RTP multiplexing points see
   [I-D.ietf-avtcore-multiplex-guidelines].

> 
> - Section 3.2.4 says “SSRCs with the same CNAME in different RTP
> sessions can be synchronized”; this is also true of flows with
> different SSRC but the same CNAME within an RTP session.

Correct, I changed this to:

SSRCs with the same CNAME sent in any of multiple RTP sessions can be
synchronized.

> - Section 3.4: should this say anything about AQM and/or QoS

I tried writing something about this. I don't know how useful this is.
Feedback much appreciated.

3.4.2.  Different Queuing Algorithms

   Routers and Switches on the network path between an IP sender and a
   particular receiver can exhibit different behaviors affecting the end
   to end characteristics.  One of the more important aspects of this is
   queuing behavior.  Routers and Switches has some amount of queuing to
   handle temporary bursts of data that designated to leave the switch
   or router on the same egress link.  A queue when not empty results in
   an increased path delay.

   The implementation of the queuing effects the delay and also how
   congestion signals (Explicint Congestion Marking (ECN) or packet
   drops) are provided to the flow.  The other aspects are if the flow
   shares the queue with other flows and how the implementation affects
   the flow interaction.  This becomes important for example when real-
   time flows interacts with long lived TCP flows.  TCP have a built in
   behavior in its congestion control that strive to fill the buffer,
   thus all flows sharing the buffer experienced the delay build up.

   A common but quite poor queue handling mechanism is tail-drop, i.e.
   only drop packets when the incoming packet doesn't fit in the queue.
   Active Queue Management (AQM) is a term covering mechanism that tries
   to do something smarter buy actively managing the queue, for example
   by sending congestion signals earlier by droping packets earlier in
   the queue.  The behavior also affects the flow interactions.  For
   example Random Early Drop (RED) selects which packet to drop
   randomly.  This to give flows that have more packets in the queue a
   higher probability to experience the packet loss (congestion signal).
   There is ongoing work to find suitable mechanisms to recommend for
   implementation and reduce the use of tail-drop.

3.4.3.  Quality of Service

   Using best effort Internet one have no guaratees for the paths
   properties.  Quality of Service (QoS) mechanism are intended to
   provide the possility to bound the path properties.  Where Diffserv
   [RFC2475] markings effects the queing and forwarding behaviors of
   routers, the mechanism provides only statistical guarantees and care
   in how much marked packets of different types that are entering the
   network.  Flow based QoS like IntServ [RFC1663] has the potential for
   stricter guarantees as the properties are agreed on by each hop on
   the path.

> - Section 4 might be clearer titled “Standardisation Process for an

Agreed

> 
> - Section 4 “registration of the RTP payload format name” – how does
> this relate to the “media type” discussed in Section 3.3?

It really should be referencing the Media Type as this is the registry
which matters. Thus changed sentence to:

For specifications that are defined by standards bodies other than the
IETF the primary milestone is registration of the Media Type for the RTP
payload format.

> 
> - The discussion of SST and MST in Section 5.1.5 seems to confuse
> sessions with SSRCs. Isn’t it more important whether the layers are
> sent within a single RTP media stream, or as separate RTP media
> streams with different SSRC values? Whether the different SSRCs are
> sent in one RTP session of many is then a separate issue, depending
> on how easily one wants to be able to separate the flows for QoS
> purposes.

The issue is that the SVC payload RFC is a bit confused on this matter.
I agree that there are two separate important distinctions here. First
if the layers are sent in one RTP packet stream or used multiple ones.
In the second case one gets the question of how one distributes that
over RTP sessions and underlying transports. Especially as some that
implements SVC MST clearly uses a single RTP session and are after the
possibility on a SSRC level to control transmission of layers in RTP
middleboxes.

I have tried to address this in the text, please review.

5.1.5.  Media Scalability

   Some codecs support various types of media scalability, i.e. some
   data of a media stream may be removed to adapt the media's
   properties, such as bitrate and quality.  The adaptation may be
   applied in the following dimensions of the media:

   Temporal:  For video codecs it is possible to adapt the frame rate,
      e.g. for H.264 [RFC6184].

   Spatial:  Video codecs supporting scalability may adapt the
      resolution, e.g. in SVC [RFC6190].

   Quality:  The quality of the media stream may be scaled by adapting
      the accuracy of the coding process, as, e.g.  possible with Signal
      to Noise Ratio (SNR) fidelity scalability of SVC [RFC6190].

   At the time of writing this document, codecs that support scalability
   have a bit of revival.  It has been realized that getting the
   required functionality for supporting the features of the media
   stream into the RTP framework is quite challenging.  One of the
   recent examples for layered and scalable codecs is Scalable Video
   Coding [RFC6190] (SVC).

   SVC is a good example for a payload format supporting media
   scalability features, which have been in its basic form already
   included in RTP.  A layered codec supports the dropping of data parts
   of a media stream, i.e. RTP packets may be not transmitted or
   forwarded to a client in order to adapt the media stream rate as well
   as the media stream quality, while still providing a decodable subset
   of the media stream to a client.  One example for using the
   scalability feature may be an RTP Mixer (Multipoint Control Unit)
   which controls the rate and quality sent out to participants in a
   communication based on dropping RTP packets or removing part of the
   payload.  Another example may be an transport channel which allows
   for differentiation in Quality of Service (QoS) parameters based on
   RTP sessions in a multicast session.  In such a case, the more
   important packets of the scalable media stream (base layer) may get
   better QoS parameters, then the less important packets (enhancement
   layer) in order to provide some kind of graceful degradation.  The
   scalability features required for allowing an adaptive transport as
   described in the two examples above are based on RTP multiplexing in
   order to identify the packets to be dropped or transmitted/forwarded.
   The multiplexing features defined for Scalable Video Coding [RFC6190]
   are:

      single session transmission (SST), where all media layers of the
      media are transported as single source (SSRC) in a single RTP
      session; as well as

      multi session transmission (MST), which should more accurately be
      called multi stream transmission, where different media layers or
      a set of media layers are transported in different RTP streams,
      i.e. using multiple sources (SSRCs).

   In the first case (SST), additional in-band as well as out-of-band
   signaling is required in order to allow identification of packets
   belonging to a specific media layer.  Furthermore, an adaptation of
   the media stream requires dropping of specific packets in order to
   provide the client with a compliant media stream.  In case of using
   encryption, it is typically required for an adapting network device
   to be in the security context to allow packet dropping and providing
   an intact RTP session to the client.  This typically requires the
   network device to be an RTP mixer.

   In general having a media unaware network device dropping excessive
   packets will be more problematic than having a Media Aware Network
   Entity (MANE).  First is the need to understand the media format and
   know which ADUs or payloads that belongs to the layers, that no other
   layer will be dependent on after the dropping.  Secondly, if the MANE
   can work as RTP mixer or translator it can rewrite the RTP and RTCP
   in such a way that the receiver will not suspect non-intentional RTP
   packet losses needing repair actions.  This as the receiver can't
   determine if a lost packet was an important base layer packet or one
   of the less important extension layers.

   In the second case (MST), the RTP packet streams can be sent using a
   single or multiple RTP sessions, and thus transport flows, e.g. on
   differnt multicast groups.  Transmitting the streams in different RTP
   sessions then the out-of-band signaling typically provides enough
   information to identify the media layers and its properties.  The
   decision for dropping packets is based on the Network Address which
   identifies the RTP session to be dropped.  In order to allow correct
   data provision to a decoder after reception from different sessions,
   data re-alignment mechanisms are described for Scalable Video Coding
   [RFC6190].  A more generic one is also described in Rapid Sync for
   RTP flows [RFC6051], which is purely based on existing RTP

   mechanisms, i.e. the NTP timestamp, for inter-session
   synchronization.  Another signaling feature is the generic indication
   of dependencies of RTP sessions in SDP, as defined in the Media
   Decoding Dependency Grouping in SDP [RFC5583].

   Using MST within a single RTP session is also possible and allow
   stream level handling instead of looking deeper into the packets by a
   MANE.  However, transport flow level properties will be the same
   unless packet based mechanisms like DiffServ is used.

   When QoS settings, e.g. DiffServ markings, are used to ensure that
   the extension layers are dropped prior the base layer the receiving
   end-point has the benefit in MST to know which layer or set of layers
   the missing packets belong as it will be bound to different RTP
   sessions.  Thus explicitly indicating the importance of the loss.

> timeout interval is also important.

If I understand this correctly, this is a minor issue with the RTCP SR
and RR packet types as they all uses 32-bit counters. However, other
packet types may have issues if they not use extended sequence number
counters.

This might be more relevant to considerations for configuring RTCP
bandwidth and design of RTCP extensions, rather than being an RTP
Payload issue. There exists a configuration goal to ensure that RTCP
reporting doesn't wrap its fields within multiple reporting intervals.

I propose that the following paragraph is added in this section:

RTCP is also affected by high packet rates. For RTCP mechanism that do
not use extended counters there is significant risk that they wrap
multiple times between RTCP reporting or feedback, thus producing
uncertainty which packet(s) that are referenced. The payload designer
can't effect the RTCP packet formats used and their design, but can note
this considerations when configuring RTCP bandwidth and reporting
intervals to avoid to wrapping issues.

> - The introduction to Section 7 could usefully reference the template

Yes, is this ok?

   A number of sections in the payload format draft need special
   consideration.  These include the Security and IANA Considerations
   sections that are required in all drafts.  Payload formats are also
   strongly recommended to have the media format description and
   congestion control considerations.  The included RTP Payload format
   template (Appendix A) contains draft text for some of these sections.

> - Appendix A.10: mention that the RTP circuit breaker ought to be

Okay, added text, I have avoided RFC 2119 language. I think circuit
breakers should make clear as an update to RFC 3550 when they are
required. The proposed text is:

   Congestion control for RTP SHALL be used in accordance with RFC 3550
   [RFC3550], and with any applicable RTP profile; e.g., RFC 3551
   [RFC3551].  An additional requirement if best-effort service is being
   used is: users of this payload format MUST monitor packet loss to
   ensure that the packet loss rate is within acceptable parameters.
   Circuit Breakers [I-D.ietf-avtcore-rtp-circuit-breakers] is an update
   to RTP [RFC3550] that defines criteria for when one is required to
   stop sending RTP Packet Streams.  The circuit breakers is to be
   implemented and followed.

Cheers

Magnus Westerlund

---

From: Colin Perkins <[email-masked]>
Date: Sun, 22 Sep 2013 17:31:08 +0100

Hi Magnus,

>      to provide better burst error robustness when the packet rate is

This looks good.

>      receivers to calculate the RTT to other session participants when

Good.

> few important details to remember when designing a payload format.

It might be worth expanding this to say "...even affect the behaviour (RTP timestamp and marker bit), but it is important to note that not all features and concepts are relevant to every payload format"?

>      multiple SSRCs to separate original data and repair or redundant

Ok.

>      information required in order to decode the payload successfully.

That's better, but I might suggest even stronger wording: "RTP payload formats often need to include metadata relating to the payload data being transported. Such metadata is sent as a payload header, at the start of the payload section of the RTP packet. The RTP packet also includes space for a header extension [RFC5275]; this can be used to transport payload format independent metadata, for example a SMPTE time code for the packet [RFC5484]. The RTP header extensions is not intended to carry headers that relate to a particular payload format., and must not contain information needed in order to decode the payload."

The last sentence of the first paragraph of Section 3.2.2 also needs updating. I suggest "Finally, [RFC5285] specifies how to transport payload format independent metadata relating to the RTP packet".

>   be noted if the payload format has this property or not.

Better, but could still be more explicit. How about changing the "Such examples are..." sentence to "A common example is a payload format for a video codec where the RTP timestamp represents the capture time of the video frame, but frames are large enough that multiple RTP packets need to be sent for each frame spread across the framing interval".

>      increasing for each sent RTP packet.

Good.

>   [I-D.ietf-avtcore-leap-second].

Okay.

>      its configuration during the session.

Good.

>   [I-D.ietf-avtcore-multiplex-guidelines].

Okay.

> SSRCs with the same CNAME sent in any of multiple RTP sessions can be

Okay.

>   drops) are provided to the flow.

Reference RFC 6679 here?

>  The other aspects are if the flow

I think this is useful. It highlights that there are issues to consider, which is the goal.

> IETF the primary milestone is registration of the Media Type for the RTP

Ok.

>   sessions.  Thus explicitly indicating the importance of the loss.

I think this is okay, but it really needs an implementer of the SVC format to comment too.

> intervals to avoid to wrapping issues.

That's fine, although I was actually suggesting something simpler, which is to change "As rule of thumb, it must not be possible to wrap the sequence number space in less than 2 minutes (TCP maximum segment lifetime)" to "...must not be possible to wrap the sequence number space in less than an RTCP reporting interval".

>   template (Appendix A) contains draft text for some of these sections.

Yes.

>   implemented and followed.

Looks good.

Cheers,
Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 26 Sep 2013 09:07:20 +0200

Hi,

Removing everything except questions / comments.

Feedback especially requested on the last comment. Anyone with SVC
experience should review the changes for Section 5.1.5.

Inline

On 2013-09-22 18:31, Colin Perkins wrote:
>>> - Section 3.2: the introduction to this section could be clearer
>>> that this is an overview of RTP features that are available
>>> independent of the payload format, and not a list of things that
>>> the payload format needs to explicitly opt in to/out of.
>> 
>> This section reviews a number of RTP features and concepts that
>> are available in RTP independent of the payload format. The RTP
>> payload format can make use of these when appropriate, and in some
>> cases even effect the behavior (RTP Timestamp and marker bit). This
>> section does not remove the necessity to read up on RTP. However it
>> does point out a few important details to remember when designing a
>> payload format.
> 
> It might be worth expanding this to say "...even affect the behaviour
> (RTP timestamp and marker bit), but it is important to note that not
> all features and concepts are relevant to every payload format"?

Good suggestion: The resulting text now reads:

This section reviews a number of RTP features and concepts that are
available in RTP independent of the payload format. The RTP payload
format can make use of these when appropriate, and even affect the
behaviour (RTP timestamp and marker bit), but it is important to note
that not all features and concepts are relevant to every payload format.
This section does not remove the necessity to read up on RTP. However it
does point out a few important details to remember when designing a
payload format.

> 
>>> - In Section 3.2.2 the statement “[RFC5285] specifies how to
>>> extend the RTP header to carry metadata relating to the payload”
>>> is potentially misleading, since the type of information that
>>> usually goes into an RTP payload header is also “metadata
>>> relating to the payload”. It might be useful to expand this
>>> discussion slightly, to make the distinction clear.
>> 
>> Is this better?
>> 
>> Header extensions:  Payload formats normally specifies the
>> carrying of meta data related to the media payload in the payload
>> header. In some cases the meta data may be more generic, e.g.
>> relevant more to the media type (e.g. audio or video), or RTP
>> packets in general.  In those cases the carrying of this additional
>> meta data can be specified in a header extension.  One example is
>> the transport of SMPTE time-codes in the RTP header [RFC5484].  As 
>> [RFC5285] specifies, header extensions must not contain information
>> required in order to decode the payload successfully.
> 
> That's better, but I might suggest even stronger wording: "RTP
> payload formats often need to include metadata relating to the
> payload data being transported. Such metadata is sent as a payload
> header, at the start of the payload section of the RTP packet. The
> RTP packet also includes space for a header extension [RFC5275]; this
> can be used to transport payload format independent metadata, for
> example a SMPTE time code for the packet [RFC5484]. The RTP header
> extensions is not intended to carry headers that relate to a
> particular payload format., and must not contain information needed
> in order to decode the payload."
> 
> The last sentence of the first paragraph of Section 3.2.2 also needs
> updating. I suggest "Finally, [RFC5285] specifies how to transport
> payload format independent metadata relating to the RTP packet".
> 

I like this, I will include this.

>>> - In Section 3.2.2, it might be useful to explain that video
>>> payload formats are a common example of “payload formats with a
>>> timestamp definition which results in no or little correlation
>>> between the media time instance and its transmission time”;
>>> otherwise this sounds like such payload formats are something
>>> unusual.
>> 
>> This discussion got moved into the new section 5.2, where the
>> related text says:
>> 
>> RTP payload formats with a timestamp definition which results in
>> no or little correlation between the media time instance and its 
>> data included, the the timestamp may jump back and forth.  It
>> should be noted if the payload format has this property or not.
>> 
>> Good enough?
> 
> Better, but could still be more explicit. How about changing the
> "Such examples are..." sentence to "A common example is a payload
> format for a video codec where the RTP timestamp represents the
> capture time of the video frame, but frames are large enough that
> multiple RTP packets need to be sent for each frame spread across the
> framing interval".

Yes, that is more focused.

>> I tried writing something about this. I don't know how useful this
>> is. Feedback much appreciated.
>> 
>> 
>> Routers and Switches on the network path between an IP sender and
>> a particular receiver can exhibit different behaviors affecting the
>> end to end characteristics.  One of the more important aspects of
>> this is queuing behavior.  Routers and Switches has some amount of
>> queuing to handle temporary bursts of data that designated to leave
>> the switch or router on the same egress link.  A queue when not
>> empty results in an increased path delay.
>> 

Yes, for people that like to dig into ECN, going to the RTP spec is a
good first step.

> 
>> The other aspects are if the flow shares the queue with other flows
>> and how the implementation affects the flow interaction.  This
>> becomes important for example when real- time flows interacts with
>> long lived TCP flows.  TCP have a built in behavior in its
>> congestion control that strive to fill the buffer, thus all flows
>> sharing the buffer experienced the delay build up.
>> 
>> A common but quite poor queue handling mechanism is tail-drop,
>> i.e. only drop packets when the incoming packet doesn't fit in the
>> queue. Active Queue Management (AQM) is a term covering mechanism
>> that tries to do something smarter buy actively managing the queue,
>> for example by sending congestion signals earlier by droping
>> packets earlier in the queue.  The behavior also affects the flow
>> interactions.  For example Random Early Drop (RED) selects which
>> packet to drop randomly.  This to give flows that have more packets
>> in the queue a higher probability to experience the packet loss
>> (congestion signal). There is ongoing work to find suitable
>> mechanisms to recommend for implementation and reduce the use of
>> tail-drop.
>> 
>> Using best effort Internet one have no guarantees for the paths 
>> provide the possibility to bound the path properties.  Where
>> Diffserv [RFC2475] markings effects the queuing and forwarding
>> behaviors of routers, the mechanism provides only statistical
>> guarantees and care in how much marked packets of different types
>> that are entering the network.  Flow based QoS like IntServ
>> [RFC1663] has the potential for stricter guarantees as the
>> properties are agreed on by each hop on the path.
> 

Good, I was uncertain if this text said the right things.

> 
>>> - The discussion of SST and MST in Section 5.1.5 seems to
>>> confuse sessions with SSRCs. Isn’t it more important whether the
>>> layers are sent within a single RTP media stream, or as separate
>>> RTP media streams with different SSRC values? Whether the
>>> different SSRCs are sent in one RTP session of many is then a
>>> separate issue, depending on how easily one wants to be able to
>>> separate the flows for QoS purposes.
>> 
>> The issue is that the SVC payload RFC is a bit confused on this
>> matter. I agree that there are two separate important distinctions
>> here. First if the layers are sent in one RTP packet stream or used
>> multiple ones. In the second case one gets the question of how one
>> distributes that over RTP sessions and underlying transports.
>> Especially as some that implements SVC MST clearly uses a single
>> RTP session and are after the possibility on a SSRC level to
>> control transmission of layers in RTP middleboxes.
>> 
>> Temporal:  For video codecs it is possible to adapt the frame
>> rate, e.g. for H.264 [RFC6184].
>> 
>> Quality:  The quality of the media stream may be scaled by
>> adapting the accuracy of the coding process, as, e.g.  possible
>> with Signal to Noise Ratio (SNR) fidelity scalability of SVC
>> [RFC6190].
>> 
>> At the time of writing this document, codecs that support
>> scalability have a bit of revival.  It has been realized that
>> getting the required functionality for supporting the features of
>> the media stream into the RTP framework is quite challenging.  One
>> of the recent examples for layered and scalable codecs is Scalable
>> Video Coding [RFC6190] (SVC).
>> 
>> included in RTP.  A layered codec supports the dropping of data
>> parts of a media stream, i.e. RTP packets may be not transmitted
>> or forwarded to a client in order to adapt the media stream rate as
>> well as the media stream quality, while still providing a decodable
>> subset of the media stream to a client.  One example for using the 
>> communication based on dropping RTP packets or removing part of
>> the payload.  Another example may be an transport channel which
>> allows for differentiation in Quality of Service (QoS) parameters
>> based on RTP sessions in a multicast session.  In such a case, the
>> more important packets of the scalable media stream (base layer)
>> may get better QoS parameters, then the less important packets
>> (enhancement layer) in order to provide some kind of graceful
>> degradation.  The scalability features required for allowing an
>> adaptive transport as described in the two examples above are based
>> on RTP multiplexing in order to identify the packets to be dropped
>> or transmitted/forwarded. The multiplexing features defined for
>> Scalable Video Coding [RFC6190] are:
>> 
>> called multi stream transmission, where different media layers or a
>> set of media layers are transported in different RTP streams, i.e.
>> using multiple sources (SSRCs).
>> 
>> belonging to a specific media layer.  Furthermore, an adaptation
>> of the media stream requires dropping of specific packets in order
>> to provide the client with a compliant media stream.  In case of
>> using encryption, it is typically required for an adapting network
>> device to be in the security context to allow packet dropping and
>> providing an intact RTP session to the client.  This typically
>> requires the network device to be an RTP mixer.
>> 
>> In general having a media unaware network device dropping
>> excessive packets will be more problematic than having a Media
>> Aware Network Entity (MANE).  First is the need to understand the
>> media format and know which ADUs or payloads that belongs to the
>> layers, that no other layer will be dependent on after the
>> dropping.  Secondly, if the MANE can work as RTP mixer or
>> translator it can rewrite the RTP and RTCP in such a way that the
>> receiver will not suspect non-intentional RTP packet losses needing
>> repair actions.  This as the receiver can't determine if a lost
>> packet was an important base layer packet or one of the less
>> important extension layers.
>> 
>> In the second case (MST), the RTP packet streams can be sent using
>> a single or multiple RTP sessions, and thus transport flows, e.g.
>> on differnt multicast groups.  Transmitting the streams in
>> different RTP sessions then the out-of-band signaling typically
>> provides enough information to identify the media layers and its
>> properties.  The decision for dropping packets is based on the
>> Network Address which identifies the RTP session to be dropped.  In
>> order to allow correct data provision to a decoder after reception
>> from different sessions, data re-alignment mechanisms are described
>> for Scalable Video Coding [RFC6190].  A more generic one is also
>> described in Rapid Sync for RTP flows [RFC6051], which is purely
>> based on existing RTP
>> 
>> synchronization.  Another signaling feature is the generic
>> indication of dependencies of RTP sessions in SDP, as defined in
>> the Media Decoding Dependency Grouping in SDP [RFC5583].
>> 
>> stream level handling instead of looking deeper into the packets by
>> a MANE.  However, transport flow level properties will be the same 
>> the extension layers are dropped prior the base layer the
>> receiving end-point has the benefit in MST to know which layer or
>> set of layers the missing packets belong as it will be bound to
>> different RTP sessions.  Thus explicitly indicating the importance
>> of the loss.
> 

Yes, that would be desirable.

> 
>>> - In Section 5.1.6, avoiding wrap-around within the RTCP
>>> reporting timeout interval is also important.
>> 
>> If I understand this correctly, this is a minor issue with the RTCP
>> SR and RR packet types as they all uses 32-bit counters. However,
>> other packet types may have issues if they not use extended
>> sequence number counters.
>> 
>> Payload issue. There exists a configuration goal to ensure that
>> RTCP reporting doesn't wrap its fields within multiple reporting
>> intervals.
>> 
>> RTCP is also affected by high packet rates. For RTCP mechanism that
>> do not use extended counters there is significant risk that they
>> wrap multiple times between RTCP reporting or feedback, thus
>> producing uncertainty which packet(s) that are referenced. The
>> payload designer can't effect the RTCP packet formats used and
>> their design, but can note this considerations when configuring
>> RTCP bandwidth and reporting intervals to avoid to wrapping
>> issues.
> 
> That's fine, although I was actually suggesting something simpler,
> which is to change "As rule of thumb, it must not be possible to wrap
> the sequence number space in less than 2 minutes (TCP maximum segment
> lifetime)" to "...must not be possible to wrap the sequence number
> space in less than an RTCP reporting interval".

That is difficult for someone that is new to quantify into meaningful
values. Especially as we have reporting intervals between milliseconds
(a scaled RTCP interval for the gigabit raw video) to many seconds for
large groups with small amounts of receiver reporting bandwidths.

In addition I don't think one reporting interval is really sufficient.
In absence of RTCP packet loss it provides the bare minimum to detect a
wrap in RTCP. But one really need to take the maximum interval between
two RTCP packets into account and considering loss I think 3-4 intervals
are needed to have reasonable saftey.

The motivation for using TCP MSL was the argument that TCP MSL is
selected as the time interval no emitted packet would still be possible
to arrive after. That is true also for RTP packets and thus a valid
considerations providing sufficient margins. It also covers almost all
RTCP usages that I can think of.

I have changed the text to now say:

Some media codecs require high packet rates, and in these cases the RTP
sequence number wraps too quickly. As rule of thumb, it must not be
possible to wrap the sequence number space within at least three RTCP
reporting intervals. As the reporting interval can vary widely due to
configuration and session properties, and also must take into account
the randomization of the interval, one can use the TCP maximum segment
lifetime, which is 2 minutes in ones calculations.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 26 Sep 2013 09:28:12 +0200

WG,

As part of editing the comments I am proposing one additional change.
This is a clarification of text in Section 3.3.2.1 that used to say:

   A further issue with offer/answer which complicates things is that
   the answerer is allowed to renumber the payload types between offer
   and answer.  This is not recommended but allowed for support of
   gateways to the ITU conferencing suite.  This means that it must be
   possible to bind answers for payload types to the payload types in
   the offer even when the payload type number has been changed, and
   some of the proposed payload types have been removed.  This binding
   must normally be done by matching the configurations originally
   offered against those in the answer.

Which I propose to change to:

   A further issue with offer/answer which complicates things is that
   the answerer is allowed to renumber the payload types between offer
   and answer.  This is not recommended but allowed for support of
   gateways to the ITU conferencing suite.  This means that it must be
   possible to bind answers for payload types to the payload types in
   the offer even when the payload type number has been changed, and
   some of the proposed payload types have been removed.  This binding
   must normally be done by matching the configurations originally
   offered against those in the answer.  This may require specification
   in the payload format of which parameters that constitute a
   configuration, for example as done in Section 8.2.2 of the H.264 RTP
   Payload format [RFC6184]; "The parameters identifying a media format
   configuration for H.264 are profile-level-id and packetization-mode".

Making clear that one may have to write a definition of it. This has
become relevant in the discussion in MMUSIC regarding BUNDLE and what a
codec configuration really is. But the basic requirement for this
originates from Offer/Answer itself (RFC 3264).

I appreciate feedback on this change.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 26 Sep 2013 09:46:22 +0000

Looks good to me except that there are bunch of lower-case 2119 keywords.
Any possibility to avoid them or is it better to make them upper case?

-----Original Message-----
From: Magnus Westerlund <[email-masked]>
Date: Thursday, September 26, 2013 10:28 AM
To: "[email-masked]" <[email-masked]>
Cc: "Ali C. Begen" <[email-masked]>
Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05

>>enough, etc. please post them to the list. We need to get this right to
>>minimize further headaches for future documents in our WG.
>>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 26 Sep 2013 14:04:58 +0200

> Any possibility to avoid them or is it better to make them upper case?

No, they should not be interpreted in the RFC 2119 upper case meaning.
This is an informative document and regular English interpretation are
fine. I find it difficult to write without using may, should, recommend
and to some degree must. And removing these out of the document would be
a massive undertaking which I fail to see the benefit with.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 26 Sep 2013 12:59:16 +0000

On Sep 26, 2013, at 3:04 PM, Magnus Westerlund <[email-masked]> wrote:

> fine.

yes, it is information and I keep forgetting that.

> I find it difficult to write without using may, should, recommend
I think putting a note somewhere around the intro part about the use of these keywords in lower case would be beneficial.

---

From: Colin Perkins <[email-masked]>
Date: Thu, 26 Sep 2013 17:07:59 +0100

Hi Magnus,

This all looks fine. 

Thanks,
Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 26 Sep 2013 18:07:39 +0000

Hi Magnus, group,

A few random comments.  None of them are showstoppers.  Yes, I should have
contributed those earlier.  Sorry.

Perhaps add a section about "writing style".  Aspects here:
(1) contrary to most other SDOs, the IETF has a history of spelling out
not only WHAT an implementation is to do, but also WHY.  As a lot of RTP
payload formats are written by media guys (who's home SDO is not
necessarily the IETF), mentioning this could help overcoming a culture
shock.
(2) OTOH, many/most implementers of RTP payload specs are the same people
that also implement the network centric parts of the media codec--at least
for well designed media codecs, systems, and payload formats.  Therefore,
it is also good to reflect the style and terminology of the media codings
pec in the payload format--even if that makes the payload spec a little
bit less accessible for folks working only in the IETF.  This is one
reason why I don't feel bad about the often lamented "density" of the
H.264 payload specs.  No compromises should be made on core IETF habits
like the use of 2119 keywords, though.
(3) It's also worth spelling out that the IETF has a historic (albeit
arguably not current) preference for lean and mean specs, even at the cost
of some functionality.  Most media codec SDOs operate under an assumption
that if there were a use-case/requirement (however exotic/weak it may be,
and I note that use/case and requirements discussions have quite often
nothing to do with the real world) and no competing tool, a proposal goes
in, pleasing certain IPR departments and leading to patent bonuses and
career advancements, at the cost of a bloated document.  Some RTP payload
formats written predominantly by media codec people arguably are bloated
as well for the same reason.  (And yes, I take personal blame for some of
this.)  While I do not see that we can change the situation (you want to
have the media competence of the media coding people), I think we can at
least point it out--hopefully in somewhat more diplomatic language--so to
explain a very common culture clash between IETF regulars and payload
format writers.

In 3.1.1 I would mention prominently the early and personal IPR disclosure
obligations in the IETF, as these differ from other SDOs which specify
media codecs.  Simply pointing to the policy docs may be not enough.

Section 3 (and section 1).  I think a lot of this description is written
for someone who wants to write an RTP payload format for an existing media
codec (with a stable and essentially unchangeable spec).  While this is
probably still the most common scenario, there are a number of cases where
the transport aspects of the media coder and the media aspects of the
transport (RTP payload format) have been developed concurrently, generally
with very pleasing results for both specs.  H.264 is one prominent
example, but there are others.  Arguably, joint development of codec and
RTP payload format is becoming a trend.  I think that a 2013 generation
RTP payload how-to should acknowledge this situation.  One way to do that
would be to include, in section 3, subsections "read and understand the
media coding spec", and "influence the media coding spec".  If people
think this is a good idea, I'm willing to draft a few paragraphs.

I think the 9000 byte path MTU is generally not available in home
environments.  Instead, MTU sizes larger than the 1500 bytes (from
Ethernet) are AFAICT, available only in a few selected (large/medium)
enterprises and in the academic world.  If that's true, it should be
stated.  And, in home environments, the limiting factor is often not even
the ISP, but those old $50 router boxes (and their NAT implementations)
that infest the world.  Mentioning this, perhaps with an informative
reference to a recent study, would send a message: if your codec will be
used a lot in home environments, don't go above 1500 bytes.  Not this
year, and not next.

Sections 5.1.1 and 5.1.2: one key use case of both aggregation and
fragmentation is the effective packetization of pre-recorded content,
where one cannot change the size of ADUs without transcoding.   The key
use case of aggregation is the packetization overhead for small ADUs such
as parameter sets or SEI messages in H.264.

In a different email, you asked for review of 5.1.5.  There are more
qualified people on this list to comment, but here are a few points.
(1) citing H.264 RFC 6184 for temporal scalability is a bit questionable,
as 6184 doe snot include a single mechanism to support temporal
scalability (although H.264 does).  So if people would go to 6184 as the
payload format for base H.264 and read it, expecting ideas on how to deal
with temporal scalability, they would come up blank after digging through
101 pages of not exactly easy to read spec language.  I fear that it would
be best to point to SVC and 6190 for temporal scalability, just as it is
done for spatial and SNR.
(2) with respect to MST: the doc could be read that re-alignment for
H.264-SVC could be implemented through 6051.  This is not the case, as
decoding time and NAL unit order are mostly decoupled (not only in SVC,
but in all modern video codecs).
(3) Perhaps write something to the extent that MST was unpopular because
of the impracticality of multiple transport addresses, and that this
reason is slowly going away through IETF-acceptance of RTP mux techniques.

Section 6.2, "recent" VC-1.  You probably wanted to cite VP8?  Calling
VC-1 and its payload spec "recent" is a bit of  a stretch.

Perhaps add a "Do and don't" sections listing key mistakes.  In the don't
section, list the handling of the timestamp in RFCs 2038 and 2250.

Stephan