Subject: [tsvwg] ECN and header compression (RoHC)

From: "Ingemar Johansson S" <[email-masked]>
Date: Wed, 18 Nov 2009 07:46:23 +0100

Hi

A short comment to a short subject on the TSVWG session. 
Snippet from the TSVWG notes 
http://www.ietf.org/proceedings/09nov/minutes/tsvwg.txt
==============
Bob: I thought that ECN-Nonce would break header compression.
Magnus: No, it is just more inefficient to compress.
==============

Speaking with RoHC in mind, Magnus is correct in that ECN does not break header compression, it just makes it more inefficient. Typically a change in the ECN bits will lead to an additional RoHC overhead of 4 bytes for 3 consecutive packets, using a random ECT will then mean a 4 byte extra overhead continuously. With a fixed ECT (e.g ECT(0) )one will only get the extra overhead when the ECN bits change from ECT(0) to ECN-CE and vice versa.
Now 4 bytes does not sound that much but it makes a difference for the links where header compression is meant to be used (VoIP)

BR
/Ingemar
=================================
INGEMAR JOHANSSON  M.Sc. 
Senior Research Engineer 

Ericsson AB
Multimedia Technologies
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]
www.ericsson.com 
Visit http://labs.ericsson.com !
=================================

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 18 Nov 2009 09:18:50 +0000

4B is a lot of additional overhead for one bit of information, which 
ROHC spec are we speaking about here?

Just to confirm:

* I guess this same overhead occurs when the ECT(0) value changes to CE?
* and would result if ECT(0) value changes to ECT(1) or CE in PCN?

Gorry

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Wed, 18 Nov 2009 10:40:42 +0100

Hi

Comments inline 
BR
Ingemar

> -----Original Message-----
> From: Gorry Fairhurst [mailto:[email-masked]] 
> Sent: den 18 november 2009 10:19
> To: Ingemar Johansson S
> Cc: [email-masked]
> Subject: Re: [tsvwg] ECN and header compression (RoHC)
> 
> 
> 4B is a lot of additional overhead for one bit of 
> information, which ROHC spec are we speaking about here?
RFC3095, not sure the later specs but I believe that the same applies there aswell. One possible future improvement to RoHC whould actually be a profile that does not compress the DSCP and ECN bits at all but I don't know if there is any interest in this.

> * and would result if ECT(0) value changes to ECT(1) or CE in PCN?
Yes, on the other hand these events are likely less frequent than a completely random ECT(0)/ECT(1) change.

> > Speaking with RoHC in mind, Magnus is correct in that ECN 
> does not break header compression, it just makes it more 
> inefficient. Typically a change in the ECN bits will lead to 
> an additional RoHC overhead of 4 bytes for 3 consecutive 
> packets, using a random ECT will then mean a 4 byte extra 
> overhead continuously. With a fixed ECT (e.g ECT(0) )one will 
> only get the extra overhead when the ECN bits change from 
> ECT(0) to ECN-CE and vice versa.
> > Now 4 bytes does not sound that much but it makes a 
> difference for the 
> > links where header compression is meant to be used (VoIP)
> > 
> > BR
> > /Ingemar