Subject: RE: [rohc] Updating the ROHC impl. guide

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Tue, 25 Feb 2003 18:33:24 +0100

Micke,

> -----Original Message-----
> From: Mikael Degermark [mailto:[email-masked]]
> Sent: den 25 februari 2003 16:12
> To: Lars-Erik Jonsson (EAB); Rohc (E-mail)
> Subject: Re: [rohc] Updating the ROHC impl. guide
> 
> > 4) Section 4.11 seems to be totally incorrect, as RTP SN is only
> >    16 bits long, and feedback packets can carry 16 bits. I do 
> >    not know where this section comes from, but it should be removed.
> 
> I don't have the document in front of me, but the ESP SN is 32 bits, 
> so that may explain it. 

The current text says:

"4.11.  Multiple SN options in one feedback packet

  The length of the sequence number field in the original RTP
  header is 32 bits.  A decompressor can't send back all the
  32 bits in a feedback packet unless it uses multiple SN options
  in one feedback packet.  Section 5.7.6.1 declares that a
  FEEDABCK-2 packet can contain variable number of feedback
  options and the options can appear in any order.

  A compressor - that wants to be conform to the specification -
  should be able to process multiple SN options in one feedback
  packet."

You might be correct that it should have said ESP instead of RTP.
Any opinions about what to do with this section?

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

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Wed, 26 Feb 2003 14:39:56 +0100

> > > 4) Section 4.11 seems to be totally incorrect, as RTP SN is
> > >    only 16 bits long, and feedback packets can carry 16 bits.
> > >    I do not know where this section comes from, but it should
> > >    be removed.
> > 
> > I don't have the document in front of me, but the ESP SN is 
> > 32 bits, so that may explain it. 
> 
> The current text says:
> 

What about rewriting the section to apply only to profile 3, ESP?

/L-E

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Wed, 26 Feb 2003 15:51:59 +0100

That is ok with me. Then we keep it as it is, just changing
the motivating example to ESP SN (which actually is 32 bits).

OK?
/L-E

> Sent: den 26 februari 2003 22:27
> To: Lars-Erik Jonsson (EAB)
> Wouldn't it be simplest to have a general rule that multiple 
> SN options
> are allowed? The reason for having this rule is of course 
> ESP, but it seems
> simplest to have an implementation allow it for any CID.
> 
> Fits "be conservative in what you send, liberal in what you receive"
> principle.
> 
> Cheers,
> 
> Micke
> ----- Original Message -----
> From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
> To: "'Mikael Degermark'" <[email-masked]>; "Rohc (E-mail)"
> <[email-masked]>
> Sent: Wednesday, February 26, 2003 6:39 AM
> Subject: RE: [rohc] Updating the ROHC impl. guide
> 
>

---

From: [email-masked]
Date: Wed, 26 Feb 2003 16:21:30 -0600

Lars-Erik,

Some comments below.

Zhigang
 
> 1) Section 4.9 should clarify that a UO-1-ID packet with an
>    Extension 3 must never be sent with RND flags that changes
>    the packet interpretation, i.e. that would violate the base
>    condition for UO-1-ID (at least one RND value must be 0).
>    The last line of the first paragraph is also redundant and
>    unclear.
> 
>  * Proposed modified text for the first paragraph of section 4.9:
> 
>   "Extension-3 is applied to give values and indicate changes to
>    fields other than SN, TS and IP-ID in IP header(s) and RTP
>    header.  In case of UO-1-ID packets, it should be noted that
>    values provided in extensions do not update the context, with
>    an exception for SN, TS and IP-ID fields, which always update
>    the context (Section 5.7.3.). It should also be noted that a
>    UO-1-ID packet with Extension 3 must never be sent with RND
>    flags that changes the packet interpretation, i.e. that would
>    violate the base condition for UO-1-ID (at least one RND value
>    must be 0)."

Sorry, I probably missed the discussions in the past, but what is the 
reason for this section? Why Extension-3 needs special clarification,
but not other extensions? I thought the following texts from RFC 3095 
are already clear.

Section 5.7: 
(The same text is repeated in section 5.7.5.1. I remember we intentionally
make it redundantly clear, as it is a crucial point for correct parsing.)

   "When no IPv4 header is present in the static context, or the RND
   flags for all IPv4 headers in the context have been established to be
   1, the packet types R-1-ID, R-1-TS, UO-1-ID, and UO-1-TS MUST NOT be
   used.

   While in the transient state in which an RND flag is being
   established, the packet types R-1-ID, R-1-TS, UO-1-ID, and UO-1-TS
   MUST NOT be used.  This implies that the RND flag(s) of the Extension
   3 may have to be inspected before the format of a base header
   carrying an Extension 3 can be determined."

Section 5.7.3:

      "Note: UO-1-ID cannot be used if there is no IPv4 header in the
      context or if value(RND) and value(RND2) are both 1."

Section 5.7.3:

      UO-1-ID packets update context(IP-ID).  Values provided in
      extensions, except those in other SN, TS, or IP-ID fields, do not
      update the context.
 
> 6) As suggested by Zhigang and agreed on the list, we should give
>    an additional clarification in section 4.7.
> 
>  * Proposed additional paragraph in 4.7:
>   "An updating packet thus updates the reference values of all
>    header fields, either explicitly or implicitly. In UO-mode,
>    all packets are updating packets (except for UO-1-ID, which
>    only updates TS, SN and IP-ID, see 5.7.3), while in R-mode
>    all packets with a CRC are updating packets."

The above text has some self-contradiction. For example, the text
seems to say UO-1-ID is not an updating packet, which is untrue.
It looks to me that we are clarifying two things here: a) what are 
updating packets, and b) what do they update. So, can we re-arrange
above text as follows?

"In UO-mode, all packets are updating packets, while in R-mode
all packets with a CRC are updating packets. An updating packet
in R-mode updates the reference values of all header fields, either 
explicitly or implicitly. Same is true for updating packets in
UO-mode, except for UO-1-ID, which only updates TS, SN and IP-ID
(see 5.7.3)."
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Thu, 27 Feb 2003 10:06:39 +0100

Zhigang,

The issues addressed in the implemeter's guide are mainly issues
identified during implementation (interoperability test discussions).
Some of the issues are clear from 3095, but repeated questions still
indicate that additional reminders to implementers are useful.

> but not other extensions? I thought the following texts from RFC 3095 

Section 4.9 of the implementer's guide was originally written for the
purpose of reminding implementers of something that is actually clear
in 3095, as there seemed to be confusion about UO-1-ID and its updating
properties for fields in Extension 3. This should be clear from 3095,
but all questions motivated an additional reminder. The point about RND
in such packets is however something that is not clear from 3095. If
RND is changed in an UOR-2 with Extension 3, the decompressor must
re-parse the packet (as explained in 4.10), but if this happens for 
UO-1-ID, something is obviously wrong.

> seems to say UO-1-ID is not an updating packet, which is untrue.

OK, let's put it this way then:

   "An updating packet thus updates the reference values of all
    header fields, either explicitly or implicitly. In UO-mode,
    all packets are updating packets (note that UO-1-ID packets
    only update TS, SN and IP-ID, see 5.7.3), while in R-mode
    all packets with a CRC are updating packets."

Thanks!
/L-E

---

From: [email-masked]
Date: Thu, 27 Feb 2003 14:47:12 -0600

Lars-Erik,

> indicate that additional reminders to implementers are useful.

The reason I asked was that my proposal to add some texts back in 
April 2002 were rejected on the basis that they were clear from 3095,
even though they addressed questions that have been raised in ROHC 
mailing list. So, I guess above is the new criteria for content
of the user guide? 

> The point about RND

I thought it's clear from the following text in 3095.

   "While in the transient state in which an RND flag is being
   established, the packet types R-1-ID, R-1-TS, UO-1-ID, and UO-1-TS
   MUST NOT be used."

>     all packets with a CRC are updating packets."

But there is still a controdiction between the first sentence
and the second one. In fact, the first sentence is correct only
for R-mode. For UO-mode, what an updating packet updates depends on
packet type.

My proposed text in earlier email (copied below again) solves the 
above problem. I'm wondering do you disagree with any particular
point in the text?

BR,
Zhigang

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Fri, 28 Feb 2003 09:49:41 +0100

> So, I guess above is the new criteria for content of the user guide? 

Well, the section we talk about has been there for quite a while.
Anyway, there is no single criteria, we have to look at each case.
We do not want this document to grow too much, but when questions are
repeatedly asked, we have to consider adding something. When things
have been added during the last year, it has been a result of repeated
questions on the interops, and/or the mailing list. The additions we
have made have lately been related to very special details, which
probably (hopefully) indicates that we should not have to add much more
to this document (but it will stay as an I-D, as previously agreed).

Cheers,
/L-E

---

From: [email-masked]
Date: Fri, 28 Feb 2003 10:16:39 -0600

> Anyway, there is no single criteria, we have to look at each case.

Since this is a WG document, it would help to have some kind of
criteria/rules for what should be included and what should not.
Also, if the criteria change, it should be announced/documented.

This can help discussions and save time, especially when there
is disagreement.

Zhigang

---

From: [email-masked]
Date: Fri, 28 Feb 2003 10:32:10 -0600

Lars-Erik,

Any thoughts on my proposed text for section 4.7? In particular,
if you have think it is correct? Note that I added UO-0 in the
last sentence. Also, what about UO-1 and UO-1-TS? Do they update
all the header fields or just a subset?

------------------
UO-mode, except for UO-1-ID and UO-0, which only update TS, SN 
and IP-ID (see 5.7.3)."
------------------

Zhigang