Subject: Re: [AVTCORE] Header Compression and RFC5285bis

From: "Roni Even" <[email-masked]>
Date: Tue, 10 May 2016 10:36:07 +0300

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:[email-masked]] 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: [email-masked]
> ----------------------------------------------------------------------
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Stephen Casner <[email-masked]>
Date: Wed, 11 May 2016 06:49:07 +0100 (BST)

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

---

From: "Roni Even" <[email-masked]>
Date: Wed, 11 May 2016 14:06:14 +0300

Steve,
Thanks, will add this sentence
Roni

> From: Stephen Casner [mailto:[email-masked]]
> Sent: Wednesday, May 11, 2016 8:49 AM
> To: Roni Even
> Cc: 'Magnus Westerlund'; 'IETF AVTCore WG'
> Subject: 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
> > Do you think we need more text here? Any suggestions Roni
> >
> > > draft-ietf-avtext-sdes-hdr-ext-05 and RFC5285bis doesn't discuss
> > > impact of header compression due to the presence of RTP header
> extensions.
> > >
> > > 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
> > > The assumption here is that what value is set on a previous packet
> > > will be maintained on the next.
> > >
> > > maybe two larger ROHC headers to get the change across compared to
> > > if no RTP header extensions would have been present.
> > >
> > > --------------------------------------------------------------------
> > > -- Services, Media and Network features, Ericsson Research EAB/TXM
> > > Audio/Video Transport Core Maintenance [email-masked]

---

From: "Roni Even" <[email-masked]>
Date: Wed, 11 May 2016 20:01:14 +0300

Steve,
This is the full paragraph in the current version.
It looks OK to me

"Use of RTP header extensions will reduce the efficiency of RTP header
   compression, since the header extension will be sent uncompressed
   unless the RTP header compression module is updated to recognize the
   extension header.  If header extensions are present in some packets,
   but not in others, this can also reduce compression efficiency by
   requiring an update to the fixed header to be conveyed when header
   extensions start or stop being sent.  The interactions of the RTP
   header extension and header compression is explored further in
   [RFC2508] and [RFC3095]."

Roni

> > > --

---

From: Stephen Casner <[email-masked]>
Date: Wed, 11 May 2016 20:22:16 +0100

Yes, that's fine. Thanks.

-- Steve

> On May 11, 2016, at 6:01 PM, Roni Even <[email-masked]> wrote:
> 
> Steve,