Subject: [rohc] WG Last-Call for draft-ietf-rohc-rfc3095bis-rohcv2-profiles

From: Carl Knutsson <[email-masked]>
Date: Tue, 09 Oct 2007 16:28:22 +0200

Hi all,

The authors and I have agreed that it is time for a working group last
call for v2 profiles draft (draft-ietf-rohc-rfc3095bis-rohcv2-profiles-02).

This will be the usual WG last-call as suggested in RFC2418, except that
it will be three week last-call instead of two. Please send comments to
the ROHC mailing list [email-masked] before Tue, 2007-10-30, 12:00 UTC

I plan to continue the successful tradition of committed-document-
reviewers (CDR) for the WG Last-Call. To relieve the work-load of the
reviewer, I have decided split the review in two parts, one review of
the formal-notation part of the draft and one of the text part.

The CDR commit to do a review of one of the two sections of the draft
before the last-call deadline expires. I will announce the CDRs on the
list within next few days, when all candidates have been convinced to
volunteer:).

Best Regards,
/Carl Knutsson

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

---

From: Jani Juvan <[email-masked]>
Date: Wed, 10 Oct 2007 15:31:21 +0200

Hi all,

This is my first post on the ROHC mailing list. Since Carl now has
chair-duties, I am likely to contribute more to the list on behalf of
Effnet.

I have 2 minor notes on the formal notation for the latest draft:

1. The df bit is in the wrong place for RTP co_common. It is listed
under flags2, whereas the encoding methods put it under flags1. This is
most likely a residue from the previous version with co_repair.

2. This is just a suggestion: the field name "timestamp" in
variable_scaled_timestamp could be confused with the unscaled timestamp
value. Maybe it could be called ts_scaled instead to relate to the
control field?

Regards,

Jani Juvan

-- 
Jani Juvan

Effnet AB               http://www.effnet.com
Gustavslundsvägen 151 C Phone: +46 (0)8 564 605 54
Box 15040               Fax:    +46 (0)8 564 605 60
SE-167 15 Bromma

This message and any files transmitted with it is are confidential and may contain proprietary information. It is intended solely for the the addressee(s). Please notify the sender immediately by e-mail if you have received this message in error and delete this message from your system. Any unauthorized review, use, disclosure, copying, distribution or any action taken or omitted in reliance on the contents of this message, is prohibited and may be unlawful.

---

From: "Kristofer Sandlund" <[email-masked]>
Date: Mon, 15 Oct 2007 10:24:57 +0200

Hi Jani,

thanks for the feedback.

I fully agree with both your comments and will update my local copy
with the changes so it will be included with the update after the
WGLC.

BR,
  Kristofer

Jani Juvan <mailto:[email-masked]> wrote on den 10 oktober 2007
15:31 :

> variable_scaled_timestamp could be confused with the unscaled
> timestamp value. Maybe it could be called ts_scaled instead to relate
> to the control field? 
> 
> Regards,
> 
> Jani Juvan
> 
> Carl Knutsson wrote:
>> Hi all,
>> 
>> The authors and I have agreed that it is time for a working group
>> last call for v2 profiles draft
> (draft-ietf-rohc-rfc3095bis-rohcv2-profiles-02).
>> 
>> This will be the usual WG last-call as suggested in RFC2418, except
>> that it will be three week last-call instead of two. Please send
>> comments to the ROHC mailing list [email-masked] before Tue,
>> 2007-10-30, 12:00 UTC 
>> 
>> before the last-call deadline expires. I will announce the CDRs on
>> the list within next few days, when all candidates have been
>> convinced to volunteer:). 
>> 
>> Best Regards,
>> /Carl Knutsson
>> 
>>

---

From: Jani Juvan <[email-masked]>
Date: Mon, 15 Oct 2007 13:53:51 +0200

Hi again,

There is another typo still lingering in the FN. The discriminator for
Non-NULL esp static is encoded as uncompressed_value(8, 255) (meaning
it isn't sent). This should be compressed_value(8, 255).

/Jani

Kristofer Sandlund wrote:

Hi Jani,

thanks for the feedback.

BR,
Kristofer

Hi all,

1. The df bit is in the wrong place for RTP co_common. It is listed
under flags2, whereas the encoding methods put it under
flags1. This is
most likely a residue from the previous version with co_repair.

Regards,

Jani Juvan

Carl Knutsson wrote:

Hi all,

Best Regards,
/Carl Knutsson

--
Jani Juvan

---

From: "Kristofer Sandlund" <[email-masked]>
Date: Mon, 15 Oct 2007 14:13:15 +0200

Hi,

Agreed. It is a typo, so I will fix it. Thanks for catching it.

/k

Jani Juvan <mailto:[email-masked]> wrote on den 15 oktober 2007
13:54 :

> Hi again,
> 
> There is another typo still lingering in the FN. The
> discriminator for Non-NULL esp static is encoded as
> uncompressed_value(8, 255) (meaning it isn't sent). This
> should be compressed_value(8, 255).
> 
> /Jani
> 
> 	Jani Juvan <mailto:[email-masked]>
> <mailto:[email-masked]>  wrote on den 10 oktober 2007 	15:31 :
> 
> 
> 
> 		Hi all,
> 
flags1.
> 		This is most likely a residue from the previous version
> with co_repair.
>

---

From: Biplab Sarkar <[email-masked]>
Date: Wed, 17 Oct 2007 11:59:06 +0530

Hi all,

I have a few comments on the draft.

[1] I am wondering why there is no mention of the IR pkts in the formal
representation of ROHC headers in [6.8.2.4]. I see none of the profiles
explicitly capturing the IR pkts. 

[2] We have some support for re-ordering of packets between compressor
and decompressor. Since all pkt formats are not immune to re-ordering, I
think we need to relax some of the strict guidelines laid by RFC3095 to
help the decompressor to deal with the situation.
      My suggestion is to have decompressors maintain the "previous"
contexts for sometime so that any pkts that were delayed can still be
decompressed. And instead of discarding the delayed pkts it can send it
up to the application. It might avoid "context" updations in such
scenarios. But this will allow delayed pkts to be accepted even if there
is an IR or UOR-2-Ext3 pkt that changed the context drastically.
Switching between timer based compression and WLSB happens quiet often
because of the network delays at the input of the compressor. So this
will help a lot in such scenarios.

[3] co_repair header format is being captured [6.8.2.2] but its not used
yet.  I wonder why not go for crc-8 bit instead of crc-7 bit in this
pkt. Any way we are having an un-used bit "r1" lying in the packet. And
won't it be better to avoid capturing a Header format which is yet not
used. Since we might not be in the best position to say the merits and
demerits of a particular format during its future use.

Thanks
Biplab

---

From: "Kristofer Sandlund" <[email-masked]>
Date: Wed, 17 Oct 2007 15:44:37 +0200

Hi Biplab,

comments inline

Biplab Sarkar <mailto:[email-masked]> wrote on den 17
oktober 2007 08:29 :

> * PGP Signed by an unknown key: 10/17/2007 at 08:29:06 AM
> 
> Hi all,
> 
> [1] I am wondering why there is no mention of the IR pkts in
> the formal representation of ROHC headers in [6.8.2.4]. I see
> none of the profiles explicitly capturing the IR pkts.
> 

The IR is defined in 6.8.1 of the document.

> [2] We have some support for re-ordering of packets between
> compressor and decompressor. Since all pkt formats are not
> immune to re-ordering, I think we need to relax some of the
> strict guidelines laid by RFC3095 to help the decompressor to deal

3095 is NOT a normative reference to this document, so you should
never refer to it w.r.t. these profiles and therefore absolutely
no rule or guideline in 3095 applies to these profiles.
These profiles use the new ROHC framework doc as a normative ref,
and any part that is needed for the profiles is defined inside this
document.

>       with the situation. My suggestion is to have decompressors
> maintain the "previous" contexts for sometime so that any pkts that
> were delayed can still be decompressed. And instead of discarding
> the delayed pkts it can send it up to the application. It
> might avoid "context" updations in such scenarios.

This is an implementation-specific optimization, which you
are free to do if you want to, but it does not affect interoperability
and therefore should not go in the spec.
Note that when discussing most decompressor issue, the doc says
"MUST NOT be delivered to upper layers" and does not say 
"MUST discard", which means that you can store packets for any local
repair or buffering scheme that you might come up with.

> But this
> will allow delayed pkts to be accepted even if there is an IR
> or UOR-2-Ext3 pkt that changed the context drastically.
> Switching between timer based compression and WLSB happens
> quiet often because of the network delays at the input of the
> compressor. So this will help a lot in such scenarios.
> 
> [3] co_repair header format is being captured [6.8.2.2] but
> its not used yet.

What do you mean by "not used yet"? Any format defined in the
spec can be used by the compressor at any time.

>  I wonder why not go for crc-8 bit instead
> of crc-7 bit in this pkt. 

This has been discussed on the list a number of times, and the IR-DYN
format has on multiple occasions been identified as being problematic,
mostly because of its use of a CRC-8. Therefore this format solves
all the identified issues with IR-DYN, partially by having
a CRC-7 and a CRC-3. 

>Any way we are having an un-used
> bit "r1" lying in the packet. And won't it be better to avoid
> capturing a Header format which is yet not used.

Again, I do not understand why you're saying this. There is ABSOLUTELY
NO DIFFERENCE between this and any other packet format, it is defined
for all these profiles and can be used whenever (although it is
mainly intended for context repairs).

/Kristofer

> Since we
> might not be in the best position to say the merits and
> 	call for v2 profiles draft
> * Unknown Key
> * 0x6D543EEE (L)

---

From: Jani Juvan <[email-masked]>
Date: Tue, 23 Oct 2007 13:38:47 +0200

Hi all,

just noticed another error in the text. Under 6.9.2.2. The
ACKNUMBER-NOT-VALID option the text says:

The ACKNUMBER-NOT-VALID option MUST NOT appear more than once in the
FEEDBACK-2 format and MUST NOT appear in the same feedback element as
the MSN option, otherwise the compressor MUST discard the entire
feedback element.

But now there is no MSN option in the feedback, so that part is irrelevant.

/Jani

-- 
Jani Juvan

---

From: "Kristofer Sandlund" <[email-masked]>
Date: Tue, 23 Oct 2007 13:52:41 +0200

Hi Jani.

Agreed. It is a leftover from the previous version, so I will remove
the part about the MSN option.
Thanks for catching that.

/Kristofer

Jani Juvan <mailto:[email-masked]> wrote on den 23 oktober 2007

---

From: Carl Knutsson <[email-masked]>
Date: Wed, 31 Oct 2007 10:08:48 +0100

Hi all,

The first working group Last-Call has ended. The CDRs have asked me for
more time to finish the review. The new deadline is 2/11 Friday 12.00 UTC.

/Carl Knutsson (rohc-wg-chair)