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

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

_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg