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

[David Singer <[e-mail]>]

This looks reasonable to me.

Do we need to say that header extensions that change decoding setup are not a good design; if lost, the decoder will not have the correct setup for following packets and unexpected behavior may occur (and repetition cannot completely remove this possibility)?


> On Jul 10, 2016, at 4:21 , Roni Even <[e-mail]> wrote:
> 
> 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

David Singer
Manager, Software Standards, Apple Inc.