Subject:   Response to liaison letter "Questions regarding the ROHC Protocol"

Date:      Mon, 19 March 2007

To:        Susanna.Kooistra@etsi.org; Claude.Arzelier@etsi.org

CC:        narten@us.ibm.com; statements@ietf.org;
           gonzalo.camarillo@ericsson.com;
           magnus.westerlund@ericsson.com

From:      IETF ROHC WG chair: lars-erik@lejonsson.com

Purpose:   Information


This is a response to the liaison letter from the 3GPP TSG RAN WG2 received February 8 2007 entitled "Questions regarding the ROHC Protocol":

https://datatracker.ietf.org/documents/LIAISON/?????
***Letter is currently not available from the IETF LS page***

ROHC, as any header compression scheme, can only compress header information that is redundant on a per-link basis,  either within the same packet or between packets of the same flow, and for which the compressed/decompression process can ensure transparency. Transparency here means both bitwise (i.e. that the outcome of the decompression process must always result in an IP header that is bitwise identical to the original, uncompressed header) and in functional terms (i.e. that the compression/decompression will not affect end-to-end header functionality in any way). 

The UDP checksum is computed over a "pseudo header" and over the payload of the packet; therefore the value of the UDP checksum cannot be predicted, and no useful change pattern can be identified from one packet to another that would allow a header compression algorithm to compress this field.  

The UDP checksum is the only end-to-end mechanism to verify the integrity of the packet. Even if a link uses its own strong CRC, it does not provide the guarantee that the packet arriving at the receiving host is the same as the one originally sent. Applications rely on the UDP checksum as an end-to-end mechanism for verifying the integrity of the packet, and any tampering with the checksum within the network would break this end-to-end property, meaning that applications would have to start adding their own error detection mechanisms.

To summarize, the UDP checksum field appears from a header compression perspective to vary "randomly" from one packet to another, and there is no other field that provides the same functionality. Therefore it cannot be compressed by any header compression scheme. This should answer question 1 in the liaison.

The ROHC WG has discussed this question before and concluded that the UDP checksum cannot be compressed and/or removed without breaking the end-to-end integrity properties of the UDP protocol. The end-to-end integrity argument related to the UDP checksum is an architectural cornerstone that cannot simply be ignored to save a few bytes. Specifying the removal of the UDP checksum in a ROHC profile would go against the transparency requirement and is thus out of question. This should answer question 3.

With respect to questions 2 and 4, it is outside the scope of the IETF to evaluate proposals in other standardization bodies, although the answers to question 1 and 3 above may give some hints that could indeed be interpreted as saying "proposals as the one included with the liaison letter deviate from IETF's fundamental design principles and would not be adressed by this specifications body".

Best regards,
/Lars-Erik Jonsson, IETF ROHC WG Chair