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

[Magnus Westerlund <[e-mail]>]

Hi Stephan,

Thanks for the comments. See inline for comments how I see these are
addressed.

WG participants, please review!

On 2013-09-26 20:07, Stephan Wenger wrote:
> 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.

Agreed, I will include this.


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

I don't see this necessarily as being contrary to 1). I think we should
recommend using the terminology of the codec to be precise and clear.
The payload formats goal is to make clear the mapping between the two
worlds, thus the whole purpose is to bind these worlds together.


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

The RTP Payload formats may not be lean any more, but I think that is
due to the increased complexity in the codecs and the need for being
clear and explicit.


I propose that we add a section between 4.1.3 and 4.1.4 on Writing Style

My attempt for this section is the following:

4.1.4.  Writing Style

   When writing an IETF draft for an RTP payload format some few
   consideration on how to write in the IETF:

   Include Motivations:  It is common to include the motivation for why
      a particular design or technical choice was chosen.  These are
      not long statements, a sentence here and there explaining why.

   Use the Defined Terminology:  There exist defined terminology both in
      RTP and in the various media codecs.  A payload format
      specification do needs to use both to make clear the relation of
      features and their functions.

   Keeping It Simple:  IETF has a history of specifications that are
      focused on their main usage.  When it comes to RTP Payload formats
      that has a lot of modes and features the actually deployments has
      in most cases only include the most basic features that had very
      clear requirements.  Time and effort can be saved by only focusing
      on the most important use cases and keep the solution simple.


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

I agree, this should have been more clearly stated. Here are my proposal
for text around this.

  It is very important to note and understand the IETF Intellectual
   Property Rights (IPR) policy that requires early disclosures and
   disclosures based on personal knowledge from the person contributing
   in IETF.  These rules are significantly different from many other
   standardization organizations.  The IETF rules and rights associated
   with copyright and IPR are documented in BCP 78 [RFC5378] and BCP 79
   [RFC3979].  For example a person that has a patent or a patent
   application that is believed to cover a mechanism that gets added to
   the Internet draft they are contributing to (e.g. posting comments or
   suggestions on the mailing list or speaking at a meeting) they will
   need to make a timely (weeks, not months) IPR disclosure.  Read the
   above documents for the authoritative rules.  Failure to follow the
   IPR rules can have dire implications for the specification and the
   author as discussed in [RFC6701].

   The main part of the IETF process is formally defined in RFC 2026
   [RFC2026].  RFC 2418 [RFC2418] describes the WG process, the relation
   between the IESG and the WG, and the responsibilities of WG chairs
   and participants.

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

Yes, I think this is relevant to be explicit. If you can write up some
text I would be thankful, but please do so within one or maximum two weeks.

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

The message I really like to state is don't assume that 1500 bytes is
your MTU. It might be lower, and it might be higher. Design the payload
format to be flexible to allow usage in either environments.

Then there is a usage configuration that in most environment you you
need to be conservative, or maybe you should actually implement path MTU
discovery ;-).

Updated text proposal.

At the time of writing this document the most common IP Maximum
Transmission Unit (MTU) in used link layers is 1500 bytes (Ethernet data
payload). However there exist both links with smaller MTUs and links
with much larger MTUs. Certain parts of the Internet already today
support an IP MTU of 8000 bytes or more, but these are limited islands.
The most likely places to find larger MTUs than 1500 bytes are within
enterprise networks, university networks, data centers, storage networks
as well as over high capacity (10 Gbps or more) links. There is a slow
ongoing evolution towards larger MTU sizes. However, at the same time it
has become common to use tunneling protocols, often multiple ones who's
overhead when added together can shrink the MTU significant. Thus, there
exist a need to consider both limited MTUs as well as enable support of
larger MTUs. This should be considered in the design, especially in
regards to features such as aggregation of independently decodable data
units.

Note, I don't have an good reference to point at where these MTU
networks exist. This is really a speculation based on what source of
capability that exist for larger MTUs.

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

Yes, I have tried to make these clearer in the below text.

5.1.1.  Aggregation

   Aggregation allows for the inclusion of multiple application data
   units (ADUs) within the same RTP payload.  This is commonly supported
   for codecs that produce ADUs of sizes smaller than the IP MTU.  Do
   remember that the MTU may be significantly larger than 1500 bytes.
   An MTU of 9000 bytes is available today and an MTU of 64k may be
   available in the future.  Many speech codecs have the property of
   ADUs of a few fixed sizes.  Video encoders may generally produce ADUs
   of quite flexible sizes.  Thus the need for aggregation may be less.
   But some codecs produces small ADUs mixed with large, for example
   H.264 SEI messages.  Sending individual SEI message in separate
   packets are not efficient compared to combing the with other ADUs.
   There also exist cases when the ADUs are pre-produced and can't be
   adopted to a specific networks MTU.  Instead their packetization
   needs to be adopted to the network.  Thus there exist some different
   use cases with the possibility to aggregate multiple ADUs, including
   for different playback times, is useful.

   The main disadvantage of aggregation is the extra delay introduced
   (due to buffering until a sufficient number of ADUs have been
   collected at the sender) and reduced robustness against packet loss.
   Aggregation also introduces buffering requirements at the receiver.

5.1.2.  Fragmentation

   If the real-time media format has the property that it may produce
   ADUs that are larger than common MTU sizes then fragmentation support
   should be considered.  An RTP Payload format may always fall back on
   IP fragmentation, however as discussed in RFC 2736 this has some
   drawbacks.  Mainly that IP fragmented packets commonly are discarded
   in the network, especially by Network Address Translators or
   Firewalls.  The usage of RTP payload format-level fragmentation
   allows for more efficient usage of RTP packet loss recovery
   mechanisms.  It may also in some cases also allow better usage of
   partial ADUs by doing media specific fragmentation at media specific
   boundaries.  In use cases where the ADUs are pre-produced and can't
   be adopted to the network support for fragmentation can be crucial.


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

I think there is a point that tempoeral scalability can simply be done,
without explicit definition. But it should be clear that this is may
also be more explictly defined as in SVC.


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

Agreed, this is poorly formulated. I will try to make it clear that for
certain features an payload format design could rely on these tools to
be part of solution. The changed wording is:

                                                ... 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].  There exist some generic tools that may be
   of use for a payload format design for a scalable codec.  These
   include the Rapid Sync for RTP flows [RFC6051], which is using
   existing RTP mechanisms, i.e. the NTP timestamp, to ensure timely
   inter-session synchronization.  Another is the signaling feature for
   indicating dependencies of RTP sessions in SDP, as defined in the
   Media Decoding Dependency Grouping in SDP [RFC5583].


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

I think we need to be clear here. SVC MST mode appears to have gotten
significant use as multiple packet streams (SSRCs) within a single RTP
session. The original envision of the MST mode was for multicast or
other receiver controlled steering of what flows was received. From my
perspective any future scalable codec should consider having both a
single stream and a multi stream mode. However, the mapping of the RTP
packet streams needs to be flexible to cater both for multiple RTP
sessions and then commonly multicast groups as well as within a single
RTP session.


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

Failure to keep the text current. This text was first included back in
2008. Haven't been in a hurry to finish this document. But now it is time.

I updated this text to say:
The definition of RTP payload formats for video has seen an evolution
from the early ones such as H.261 towards the latest for VP-8 and
H.265/HEVC.


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

This is WG last call, of a document that has been a WG document since
2006 (then in AVT). This proposal although a good idea, is a little bit
late to introduce. Primarily as I think such a section would require a
couple of rounds of revision before getting right.

Cheers


Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------