Subject: RE: [rohc] Possibility not to transmit UDP checksums

From: "Lecompte, David" <[email-masked]>
Date: Tue, 1 Nov 2005 11:01:45 +0100

Hi Mark,

thanks very much for your answer, this really helps making the situation clearer for me.

If I understand it correctly, it means that, though it is in principle technically possible to remove the checksum on a particular link without anyone being able to know it, this is against IP protocols design & architecture, so no IETF body will specify something to do this.

I was asking because two octets are usually considered a valuable gain in 3GPP (which has adopted ROHC), and some 3GPP member company is technically arguing for a proposal to remove the UDP checksums on radio links (in fact, replace them with constant pseudo-checksum before ROHC compression, remove it after ROHC compression, but I wonder how you can insert the pseudo-checksum in the right place before ROHC decompression at the receiver side). The proposal was rejected once, not with technical arguments but because of a general feeling (we didn't do this earlier, there should be a good reason why), but it is coming back.

So I would then argue in 3GPP on this proposal in the following way : IETF does not like it, 3GPP relies on IETF for ROHC interoperability, the proposal could interact with ROHC (and unless I missed something it does not work), so this is a rather dangerous way forward, does 3GPP really want to take the responsibility to do this at its own risk ?

Does this fit with your understanding of this issue ?

Cheers,
David.

-----Message d'origine-----
De : Mark West [mailto:[email-masked]] 
Envoyé : vendredi 28 octobre 2005 19:01
À : Lecompte, David
Cc : [email-masked]
Objet : Re: [rohc] Possibility not to transmit UDP checksums

David,

There has been more than one long, drawn-out discussion about the removal
of transport-layer checksums.  The short summary of this is: "don't do
it!"  And if you want a reason, well, that's a philosophical issue...

The UDP checksum (as the TCP checksum and the SCTP checksum and ...) is
the only *end-to-end* check of the integrity of the packet.  Yes, a link
might use a strong CRC, but that is no guarantee that the packet arriving
at the receiving host is the same as the one originally sent.

(We elide the IP checksum because that's only a hop-by-hop check and RoHC
has its own integrity checking.)

The end-to-end integrity argument is an architectural cornerstone and not
one to be ignored for the sake of a couple of bytes better compression.

Note, of course, that for IPv4 it is possible to switch the UDP checksum
off (although this is not recommended -- if you don't care about bit-
errors in the payload, use UDP-lite).  Also note, though, that this is a
choice made by the end-system, not by the compressor.

Cheers,

Mark.

--
Mark A. West, Senior Consultant Engineer
Roke Manor Research Ltd., Romsey, Hants.  SO51 0ZN
Phone +44 (0)1794 833311   Fax  +44 (0)1794 833433

On Fri, 28 Oct 2005, Lecompte, David wrote:

> Date: Fri, 28 Oct 2005 19:27:10 +0200
> From: "Lecompte, David" <[email-masked]>
> To: [email-masked]
> Subject: [rohc] Possibility not to transmit UDP checksums
>
> Hi ROHCers,
>
> as far as I understood, in all ROHC profiles defined until now, UDP
> checksums are always transmitted as they are, regardless of the fact
> that ROHC may operate over a link that is already using strong CRCs at
> link or physical layer, which could well be redundant with the
> transmission of UDP checksums.
>
> Is there a reason why there isn't an option in ROHC profiles to remove
> UDP checksums at the compressor and calculate them and add them at the
> decompressor, in order to save two bytes ?
>
> My guesses would be :
>
> - such situation is not a use case for ROHC :
> Maybe it was considered that if there are strong CRCs at lower layers,
> compression needs not be robust. My understanding is that strong CRCs
> are useful for links with high error rates, such as wireless links,
> which can use strong FEC, but still suffer from high loss rates. So
> compression needs to be robust there, hence the use of ROHC.
>
> - ROHC technical problem :
> In case there is a strong CRC at link or physical layer, I can't really
> see any issue there. The lower layers CRCs can indicate errors, in which
> case ROHC can simply discard the packet, instead of adding a correct UDP
> checksum to an erroneous packet. Is there any other technical issue ?
>
> - implementation problems :
> The ROHC decompressor needs to calculate UDP checksums over whole
> packets. So one more constraint for the ROHC decompressor. But this is
> just implementation.
>
> - other solutions :
> Maybe there is another standardised way to remove UDP checksums on a
> link. If so, can you please indicate references.
>
> Thanks in advance for your contributions,
> David.
>
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
>

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc