Subject: [Tsvwg] Comment on: draft-ietf-tsvwg-udp-lite-00.txt

From: [email-masked]
Date: Wed, 30 Jan 2002 15:15:39 +0200

Hi all,

First off, my understanding from Salt Lake City is that UDP-lite would
be ready for WG last call. If this is true, consider my comment
applicable for last call.

My comment regards the applicability of UDP-lite for header compression.

RFC3095 ROHC header compression cannot be used for UDP Lite. The reason is the following: The classic UDP length field is replaced in UDP Lite by the checkusm coverage. ROHC compressor assumes that the UDP length field is redundant, i.e., it is not sent over the link, and can be inferred from other information in the decompressor (see references in the end of my e-mail). Naturally, checksum coverage of UDP Lite is not redundant, and cannot be built the same way as UDP lenght field by decompressor. This means that UDP Lite cannot be handled by current ROHC, so a new ROHC profile is needed.

This means that it must be possible to distinguish between classic UDP and UDP Lite, so that in the presence of Header Compression, UDP Lite will be sent as uncompressed and classic UDP as compressed by ROHC. Or later, when there is a new profile for UDP Lite, and it is implemented, the profile could be selected accordingly, based on the protocol identifier. 

If the protocol identifier is shared between classic UDP and UDP Lite, I wonder, how the above-mentioned situation could be handled. Seemingly, there is no other way to distinguish between UDP Lite and classic UDP, so the new protocol identifier is needed. I suggest that the draft's recommendation of a new protocol ID be required and a new IP protocol ID be applied for.

cheers,
John

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

---

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Wed, 30 Jan 2002 15:58:56 +0100

John,

I think you may have misread the UDP Lite draft. Also, the
potential header compression problem you mention is not as
difficult as one may believe. See details below...

> RFC3095 ROHC header compression cannot be used for UDP Lite.

It would just not compress if the Coverage fields is not equal 
to Length.
 
> ...so a new ROHC profile is needed.

Yes, to be able to compress it.

> This means that it must be possible to distinguish between 
> classic UDP and UDP Lite, so that in the presence of Header 
> Compression, UDP Lite will be sent as uncompressed and 
> classic UDP as compressed by ROHC. 

An explicit indication is not really needed, se below.

> Or later, when there is a new profile for UDP Lite, and it is
> implemented, the profile could be selected accordingly, based
> on the protocol identifier. 

One profile could support both, se below.
 
> If the protocol identifier is shared between classic UDP and 
> UDP Lite, I wonder, how the above-mentioned situation could 
> be handled. 

According to the UDP Lite draft, it is not the intention to share
protocol identifier with UDP.

   "Therefore, this draft proposes to allocate a new protocol
    identifier for UDP Lite."

   "We request that a new ip protocol identifier is allocated
    for UDP Lite."

For more than a year now, we have been discussing the two alternatives
of either having a separate identifier or share identifier with UDP. For
the reasons described in the draft, the latter alternative has been 
given up. Anyway, I agree with you that the draft could probably be 
clearer in this regard, i.e. avoid wording such as "propose to".

By the way, the header compression aspects you refer to have been
discussed (in Minneapolis last year, I think), and we agreed that for
HC purposes both approaches would work. The reason is that the current
RFC3095 profiles would automatically not compress UDP Lite if the 
coverage field is not equal to length, and new UDP Lite-aware profiles
could be made able to handle (compress) both UDP variants. However, as
mentioned above, this is not an issue any longer since we have agreed
not to share protocol id with UDP.

Cheers,
/Lars-Erik

---

From: [email-masked]
Date: Thu, 31 Jan 2002 14:48:01 +0200

Hi Lars-Erik,

> difficult as one may believe. See details below...

I don't think it is difficult, see comments in-line.
 
> Yes, to be able to compress it.

This is exactly what I meant - 3095 could not compress UDP-lite
& a new profile would be needed.

> of either having a separate identifier or share identifier 
> with UDP. For the reasons described in the draft, the latter alternative 
> has been given up. Anyway, I agree with you that the draft could probably 
> be clearer in this regard, i.e. avoid wording such as "propose to".

I think you need to be more explicit - IANA will balk at the IANA
section if you are not explicit, such as:

   "A new IP protocol identifier will be allocated for UDP Lite."

> not to share protocol id with UDP.

Sounds reasonable to me.

Thanks,
John