Re: [AVTCORE] Header Compression and RFC5285bis

Roni,

I think it would be appropriate to include another sentence before the
one you propose:  "The use of RTP header extensions may reduce the
effectiveness of header compression."

                                                        -- Steve

On Tue, 10 May 2016, Roni Even wrote:

> Hi Magnus,
> I am updating the document based on other comments from Colin.
> The current text says "The interactions of the RTP   header extension and
> header compression is explored further in   [RFC2508] and [RFC3095]."
> Do you think we need more text here? Any suggestions
> Roni
>
> > -----Original Message-----
> > From: avt [mailto:avt-bounces@ietf.org] On Behalf Of Magnus Westerlund
> > Sent: Saturday, April 02, 2016 6:47 PM
> > To: IETF AVTCore WG; Stephen Casner
> > Subject: [AVTCORE] Header Compression and RFC5285bis
> >
> > Hi,
> >
> > Stephen Casner raised a private comment on the
> > draft-ietf-avtext-sdes-hdr-ext-05 when he did the IANA expert review.
> > This was that both
> > draft-ietf-avtext-sdes-hdr-ext-05 and RFC5285bis doesn't discuss impact of
> > header compression due to the presence of RTP header extensions.
> >
> > I have to agree that this is something that at least RFC5285bis should
> have a
> > discussion on. There are some impact.
> >
> > In the case of Robust Header Compression (ROHC) (RFC 5795 and RFC 5225)
> > the impact to my understanding is the following. RFC5225 and the RTP
> > profile don't compress the actual header extension at all. The X bit in
> the
> > header is compressed and it is classified in Section A.5 as Rarely
> changing.
> > The assumption here is that what value is set on a previous packet will be
> > maintained on the next.
> >
> > Looking at the emerging usages that is mostly right, but there will be
> periods
> > where the x bit may be flipping its value. The usage I am considering is
> these
> > initial inclusion of the MID, CNAME etc. However for example a video
> > stream, it is sufficient to include the header extension in a single
> packet out
> > potentially many for an particular video image/frame. Thus one might have
> a
> > on, off, next TS, on, then off on subsequent packets.
> >
> > The impact of the classification as Rarely changing is that when a change
> is
> > needed a larger header than otherwise needed will be sent.
> > Thus the impact will be that each on and off behaviour will result in one
> and
> > maybe two larger ROHC headers to get the change across compared to if no
> > RTP header extensions would have been present.
> >
> > I haven't looked at CRTP, but I would guess similar impact.
> >
> > Cheers
> >
> > Magnus Westerlund
> >
> > ----------------------------------------------------------------------
> > Services, Media and Network features, Ericsson Research EAB/TXM
> > ----------------------------------------------------------------------
> > Ericsson AB                 | Phone  +46 10 7148287
> > Färögatan 6                 | Mobile +46 73 0949079
> > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> > ----------------------------------------------------------------------
> >
> > _______________________________________________
> > Audio/Video Transport Core Maintenance
> > avt@ietf.org
> > https://www.ietf.org/mailman/listinfo/avt
>
>
>