Subject: RE: [rohc] Comments on UDP-lite compression

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Tue, 11 May 2004 14:10:00 +0200

Hi Mark,

Thanks for your review and comments. 

Non-NiTS:
---------
Matching the packet length is what has precedence. Is this also your opinion?
Or do you feel that this might be wrong?

Having a null size payload is not the case that is normally expected.
However, when this occurs, i.e.

  size(payload) == null and if
  field(CC) == length(packet)

if the compressor then uses CE(OFF), the compressor knows that the CC field will be inferred at the decompressor, and that the length of the packet will be used. So I don't think that there is any ambiguity based on the text.

However, if the compressor would rather use a fixed value for the CC and avoid the decompressor to infer the CC after the length of the packet, then the compressor should use:

CE(OFF) for packets with field(CC) == constant != length(packet), and
CE()    for packets with field(CC) == constant == length(packet).

Recall that CE() does not update the context, so the compressor can avoid any ambiguity.

I don't think that there is any contradiction regarding this in the text, however I will have a closer look to see where I can make a clarification.

NiTS:
-----
I'll change the text according to your suggestions.
I can change the acronym 'CE' to 'CCE', after "Checksum Coverage Extension".

I assume that you are fine with the changes mentionned in my previous mail to the list?

Thanks again,

/Ghyslain

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of West,
Mark
Sent: den 11 maj 2004 02:17
To: [email-masked]
Subject: [rohc] Comments on UDP-lite compression

Hi all,

Here are my comments on the UDP-lite compression draft.  I think that
there's only one of any real significance; the others are minor typos /
grammar tweaks (which you can feel free to ignore if you wish!)

Cheers,

Mark.

Non-NiTS

- If CE(OFF) is sent, the decompressor is supposed to infer the setting of
the CFI flag.  However, what about the case where CC == packet length ==
context(CC) (e.g. CC is used to protect the RTP header and there is a
'null length' RTP payload?  I'm not sure that this is ambiguous (i.e.
the packet length has precedence over matching the context when setting
CFI)?  However, it would be good to ensure that the text for this really
is unambiguous...

NiTS

- I assume that the RFC numbers will be filled in for [UDP-lite] and
[IPonly] as part of the RFC Ed process?

- S1. 'guaranteed to an extremely high extent even when' -> 'guaranteed
to an extremely high extent, even when'

- S3.1. 'and allow applications' -> 'and allows applications'

- S3.1. '16-bit checksum and it is applied' -> '16-bit checksum, which
is applied'

- S3.1. 'share protocol identifier' -> 'share a protocol identifier'

- S3.2. 'inferred from the IP module' -> 'inferred from the IP header'

- S3.3. 'found in the Appendix A' -> 'found in Appendix A'

- S5.1. 'infomration relevant to previous' -> 'information about
previous'

- S5.1. 'describing the packet stream, or parameters' -> 'describing the
packet stream or compression parameters'

- S5.3.1. [figure] '(includes no SN)' -> '(does not include SN)'

- S5.3.2. Is the acronym 'CE' confusable (easily) with Congestion
Experienced in ECN?  Probably not, but I'd thought that I'd mention
it..!  (CCE == Checksum Coverage Extension has been proposed as an
alternative; this sounds good to me!)

- S5.3.2. 'while the field could previously' -> 'where the field could
previously'

- S5.3.2. 'of such deviations are seldom' -> 'of such deviations is
rare'

- S5.6. 'context of the packet stream, as the stream is currently
compressed' -> 'context of the packet stream required by the current
compressed structure'

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

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

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

---

From: "West, Mark" <[email-masked]>
Date: Tue, 11 May 2004 23:37:53 +0000 (GMT)

Hi Ghyslain,

> Or do you feel that this might be wrong?

That sounds fine to me.

> Having a null size payload is not the case that is normally expected.

I agree that it's a pretty rare occurence; but then those are always the
ones that bite you when you least expect it!

> if the compressor then uses CE(OFF), the compressor knows that the CC
> field will be inferred at the decompressor, and that the length of the
> packet will be used. So I don't think that there is any ambiguity based
> on the text.
>

Agree.

> However, if the compressor would rather use a fixed value for the CC and
> avoid the decompressor to infer the CC after the length of the packet,
> then the compressor should use:
>

That's a good point.

>
> I don't think that there is any contradiction regarding this in the
> text, however I will have a closer look to see where I can make a
> clarification.

Sounds good to me.  To be honest, when this occured to me, I re-read the
text briefly and decided that it was sufficiently interesting to bring up
as a review comment.  However, your explanation makes sense.  If it is
possible to make it less likely that it will be read in the way that I
did, then that would be great!

> I can change the acronym 'CE' to 'CCE', after "Checksum Coverage Extension".

Great...

> I assume that you are fine with the changes mentionned in my previous mail to the list?

Yes -- no problem with any of those.

Cheers,

Mark.