[AVTCORE] adressing header extnsion trasmission consideration in RFC5285-bis

["Roni Even" <[e-mail]>]

Hi guys,

During the IESG review of draft-ietf-avtext-splicing-notification the issue
of when and how often an RTP sender should send the RTP header extension to
provide high probability for the arrival of the header extension. On the
email thread it was clear that this is a general topic and it should be
better addressed in the rfc5285-bis draft. Dave Singer suggested that we use
the text from section 4.2.3 of draft-ietf-avtext-sdes-hdr-ext-07. I looked
at the text and it make sense to use it changing the reference from SDES RTP
header extension to any header extension.

 

I suggest to add a sub section 4.1.1 in 4.1 about Transmission
considerations with the following text.

 

 

 

4.1.1 Transmission Considerations

   

As is good network practice, data SHOULD only be transmitted when
   needed.  The RTP header extension SHOULD only be present in a packet
   if that packet also contains one or more extension elements, as
   defined here.  An extension element SHOULD only be present in a
   packet when needed; the signaling setup of extension elements
   indicates only that those elements can be present in some packets,
   not that they are in fact present in all (or indeed, any) packets.

 

some general considerations for getting the header extensions
   delivered to the receiver:


   1.  The probability for packet loss and burst loss determine how many
       repetitions of the header extensions will be required to reach a
       targeted delivery probability, and if burst loss is likely, what
       distribution would be needed to avoid getting all repetitions of
       the header extensions lost in a single burst.

   2.  If a set of packets are all needed to enable decoding, there is
       commonly no reason for including the header extension in all of
       these packets, as they share fate.  Instead, at most one instance
       of the header extension per independently decodable set of media
       data would be a more efficient use of the bandwidth.

   3.  How early the Header Extension item information is needed, from the
first
       received RTP data or only after some set of packets are received,
       can guide if the header extension(s) should be in all of the
       first N packets or be included only once per set of packets, for
       example once per video frame.

   4.  The use of RTP level robustness mechanisms, such as RTP
       retransmission [RFC4588], or Forward Error Correction, e.g.,
       [RFC5109] may treat packets differently from a robustness
       perspective, and header extensions should be added to
       packets that get a treatment corresponding to the relative
       importance of receiving the information.

   As a summary, the number of header extension transmissions should be
   tailored to a desired probability of delivery taking the receiver
   population size into account.  For the very basic case, N repetitions
   of the header extensions should be sufficient, but may not be
   optimal.  N is selected so that the header extension target delivery
   probability reaches 1-P^N, where P is the probability of packet loss.
   For point to point or small receiver populations, it might also be
   possible to use feedback, such as RTCP, to determine when the
   information in the header extensions has reached all receivers and
   stop further repetitions.  Feedback that can be used includes the
   RTCP XR Loss RLE report block [RF C3611], which will indicate
   successful delivery of particular packets.  If the RTP/AVPF Transport
   Layer Feedback Messages for generic NACK [RFC4585] is used, it can
   indicate the failure to deliver an RTP packet with the header
   extension, thus indicating the need for further repetitions.  The
   normal RTCP report blocks can also provide an indicator of successful
   delivery, if no losses are indicated for a reporting interval
   covering the RTP packets with the header extension.  Note that loss
   of an RTCP packet reporting on an interval where RTP header extension
   packets were sent, does not necessarily mean that the RTP header
   extension packets themselves were lost.

 

 

 

The question is if this text make sense and also should we have the same
text in both drafts?

 

 

I will do some more editorial changes to section 4.1 and also have the last
part of 4.1 as "4.1.2 header extension type considerations"

 

 

Thanks

 

Roni Even