Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed

From: "Price, Richard" <[email-masked]>
Date: Wed, 4 Jun 2003 15:41:15 +0100

Hi,

Please find attached some comments on Topic 2 (the context
replication mechanism).

Regards,

Richard

------------------------------------------------------------

Page 1: "context replication, an alternative to the context
initialization procedure found in ROHC"

I'd say "complement" rather than "alternative", as the context
replication mechanism works in conjunction with the existing
context establishment mechanisms.

Page 3: "as each new packet stream requires the entire headers
to be sent initially"

Pedantic comment - we can avoid sending the entire header even
in the IR packet, as a small number of fields can be inferred
at the decompressor (e.g. IP Payload Length etc.).

Page 4: "The fundamentals of general header compression may be
found in [RFC-3095]. These are assumed to be understood
throughout this document."

I'd like to clarify the above a little further. Is it only
necessary to understand the profile-independent parts of RFC
3095, or is knowledge of the four specific profiles also
required to implement context replication?

Page 5: "Note however that this cannot provide the guarantee
that the selected context is still part of the state managed
by the decompressor when the IR-REPLICATE will be received."

Another potential pitfall with the context replication
mechanism is that the base context may become corrupted in
the interval between the decompressor sending an ACK for the
base context, and the ACK being received by the compressor.
This would lead the compressor to incorrectly assume that the
base context is ok to use for context replication, even though
it has been damaged at the decompressor.

Page 5: "However, because [RFC-3095] does not explicitly define
context state management between compressor and decompressor,
and in particular for connection-oriented flows (e.g. TCP), only
a high degree of confidence can be achieved when selecting a
base context."

Do you mean that the decompressor may have chosen to discard the
base context (e.g. due to memory constraints)?

Page 6: "otherwise the base context is overwritten with the new
context by the replication process."

If we set the base context equal to the current context, is it
still the case that we need to acknowledge the base context using
a feedback packet? It might be useful to offer the IR-REPLICATE
packet as an ordinary packet format, which can be used to send
compressed headers even in the unidirectional case.

Page 6: "Upon reception of a STATIC-NACK, the compressor MUST
transit back to its initial no context state and SHOULD refrain
from sending IR-REPLICATE packets using the same base context."

How does the above interact with the robustness mechanisms of the
base context itself? For example, if the compressor continues to
use the base context and continues to receive positive ACKs in
the normal manner, is it ok to assume that the base context is
actually valid (and hence that the IR-REPLICATE packet itself is
where the error occurred)?

Conversely, would it be possible for the compressor to take a
STATIC-NACK for the newly replicated context as evidence that
something is wrong with the base context? It could use this
information to influence the state machine of the base context,
e.g. by causing it to transit to a lower state.

Page 6: "Upon reception of a NACK, the compressor may assume
that the static part of the decompressor context is valid but
that the dynamic part is invalid, and take actions accordingly."

Again, could this also be used by the compressor as evidence
that something is wrong with the base context?

Page 7: "Specifically, when the decompressor fails to validate
the context following the decompression of one or more initial
IR-REPLICATE packets, it MUST invalidate the context and remain
in its initial state. In addition, the decompressor SHOULD send
a STATIC-NACK."

This logic is fine for O-mode and B-mode, but I think that
different logic is required in the case of R-mode. From RFC 3095:

    "The decompressor SHOULD NOT send STATIC-NACK(R) when
     receiving an IR packet that fails the CRC check, as the
     compressor will stay in IR state and thus continue sending
     IR packets until a valid ACK is received"

The above also applies to an IR-REPLICATE packet, so the
decompressor SHOULD NOT send a STATIC-NACK in this case.

Page 7: "The decompressor SHOULD send an ACK when it succeeds to
validate the context as a result of the decompression of one or
more IR-REPLICATE packets."

For R-mode, the above logic needs to be much more precisely
defined (taking into account the "Sparse ACK" mechanism).

Page 8: "The static and dynamic chains of IR packets contains an
uncompressed representation of the original header."

This sentence is talking about the profile-independent portion
of the IR-REPLICATE packet, so I wouldn't mention the concept
of a static and dynamic "chain" (as this is profile-specific).

Page 10: "It is not recommended to use this packet to repair a
damaged context."

Are there any specific problems that can arise when repairing
a damaged context using the IR-REPLICATE packet (as opposed to,
say, a vanilla IR packet)?

Page 10: "The IR-REPLICATE has the following general format..."

I think that in the most general case the format of the
IR-REPLICATE packet should be identical to the general format
of the IR packet (Section 5.2.3 of RFC 3095). In particular,
the static and dynamic replication chains may or may not be
present depending on the specific profile.

Page 11: "The presence of a payload is inferred from the
packet length."

As above, I think that whether to do this or not is up to the
specific profile.

Page 13: "Replication of the IPv6 Header [RFC-2460]"

As well as the listed fields, why not replicate the Traffic
Class and Hop Limit as well?

Page 13: "Flow Label must not be used, i.e. this field must be
all '0's."

Would it be possible to create two contexts for the same flow
(in which case the Flow Label is replicable but non-zero)?

Page 13: "Next Header"

Any thoughts on whether it would be possible to extend the
replication mechanism to handle the complete list of extension
headers? Potentially we could replicate the Next Header field
for every header in the chain - might be a considerable saving
if the chain contains several extension headers.

Page 14: "[RFC-30905, section 5.7.7.8]."

I'm not sure we've reached thirty thousand RFCs just yet ;-)

Page 14: "Replication of the IPv4 Header [RFC-791]"

We could also consider the Type of Service, Time to Live and
IP-ID fields for replication.

Page 16: "Is it possible to identify a useful scenario where
replication of the UDP part of a context is desirable? It is not
clear how much value there is the UDP header. For UDP, the
static and dynamic chains found in [RFC-3095] could be used."

Replicating the UDP context might be useful when running ROHC
over a link where sending a large IR packet is extremely
expensive. An example of such a link is a fixed-bandwidth
speech channel, where the only way to send a ROHC header
containing more than a certain fixed number of bytes is to
discard some of the payload data (at a cost of reduced speech
quality).

> -----Original Message-----
> From: Ghyslain Pelletier [mailto:[email-masked]]
> Sent: Wednesday, June 04, 2003 9:20 AM
> To: [email-masked]
> Subject: [rohc] ROHC-TCP: Update and some topics to be discussed
> 
> 
> ROHCers,
> 
> The discussions regarding the ROHC-TCP profile need to be restarted on
> this mailing list. Let me try to kickstart this...
> 
> An updated version of the draft describing the ROHC profile of TCP,
> <draft-ietf-rohc-tcp-04.txt>, has been submitted. The following has been
> updated:
> 
> - The normative section on context replication has been removed.
>   Instead, the definition of the context replication mechanism
>   has been submitted in a separate draft, mainly for clarity.
> 
> - A basic structure for the IR/IR-DYN packets has been proposed.
>   This structure uses static and dynamic chains. See Section 5.5.1.
>   See also issue #3 later in this mail.
> 
> - A basic structure for the IR-REPLICATE packet has been proposed.
>   It follows the structure suggested in the context replication draft.
>   See Section 5.5.3. See also issue #2 later in this mail.
> 
> - Feedback format and options for ROHC-TCP has been defined.
>   See Section 5.5.4.
> 
> - Section 6 - Implementation parameter - has been removed.
> 
> Please comment on these changes and the updated version in general.
> 
> For the TCP profile to move forward, I have tried to summarize some of
> the topics that require further discussions on the mailing list:
> 
> 1) Packet formats for ROHC-TCP, two alternatives:
> 
>   o Use ROHC-FN, and how to include the packet formats in the
>     normative part of the TCP draft, or;
>   o Use box or list notation with corresponding normative text
>     describing how to encode and decode each field in the header,
>     as in RFC-3095.
> 
> 2) Context replication (See the separate draft)
> 
> 3) IR/IR-DYN format for ROHC-TCP
> 
>   The content of Section 5.5.1 is a suggestion from the editor, for
>   the purpose of providing grounds for discussions. This section does
>   not represent a consensus and the following needs to be addressed:
> 
>   o Should we use static and dynamic chains, as in 3095?
>   o Compression of TCP options for IR/IR-DYN
>   o Compression of other TCP fields in IR/IR-DYN:
>     - "data offset" is redundant
>     - "IP protocol" can be derived from the profile number
>     - "IP version" -> only two possible values, only one
>       bit is required.
>     - "TTL", particularly when compressing over the first hop
>     - "MSN", could be LSB coded
>    
> 4) Master Sequence Number (MSN)
>   o initialization of MSN (0?)
>   o compression of MSN within the packet format (LSB coded?)
> 
> So please feel very welcome to jump into any of these questions. It
> would be good to be capable of moving forward rapidly so that a new
> update can be generated in time for the Vienna meeting. Thanks!
> 
> Regards,
> 
> /Ghyslain
> 
> Ghyslain Pelletier, Dipl. Ing.
> Wireless IP Optimizations
> AWARE - Advanced Wireless Algorithm Research
> Ericsson Research, Corporate Unit
> 
> Ericsson AB, Laboratoriegränd 11
> Box 920, S-97128 Luleå, SWEDEN
> Phone : +46 (0) 920 20 24 32 
> Mobile: +46 (0) 70 609 27 73
> [email-masked]
> http://www.ericsson.com
> _______________________________________________
> 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: Ghyslain Pelletier <[email-masked]>
Date: Thu, 05 Jun 2003 15:11:50 +0200

Hi Richard,

Thanks for your comments! I've also commented in-line. I will get back
to the ones I haven't answered in this mail in a later mail.

/Ghyslain

"Price, Richard" wrote:
[snip]

Absolutely. Text will be fixed.
 
> at the decompressor (e.g. IP Payload Length etc.).

Absolutely. I can change the wording.
 
> required to implement context replication?

Ok. Will be clarified -> profile-independant parts only.

> it has been damaged at the decompressor.

Absolutely. This is why section 3.1 (second to last paragraph) talks
about "confidence". The compressor cannpt have this  certitude for the
reason you've just explained. I can add a sentence on this on page 5 as
well.
 
> base context (e.g. due to memory constraints)?

Yes. For connection-oriented flows, this could be a possible
implementation choice to save memory, and I am not sure I am willing to
constraint this possibility without this being a concious decision.
 
> compressed headers even in the unidirectional case.

It does not need to be acknowledged. Section 3.3.2. (decompressor logic)
says that the decompressor should nack upon failure and should ack upon
success. It was written specifically not to have to mandate either so
that the IR-REPLICATE can be used as you described. Do you think that
the text is not clear, or do you think that there might be a problem
with the current text?
 
[snip]

[I will get back on the feedback logic - I need to parse other related
comments first.]

> of a static and dynamic "chain" (as this is profile-specific).

This makes sense. I will adjust this. I guess for now see it more as a
suggestion together with the annex to exemplify a possible way of doing
it, other ways to do this may be defined instead.

[snip]
 
> present depending on the specific profile.

I can agree on the chains. However, I'd still like to keep the
"requirements" on the profile specific part regarding the 7-bit CRC.
 
> As above, I think that whether to do this or not is up to the

Correct.
 
> Class and Hop Limit as well?

The annex is informative and provide a possible way of structuring the
IR-REPLICATE. This is meant as a suggestion. We could add replication
for those two fields as well if we want so. I can update that.
 
> (in which case the Flow Label is replicable but non-zero)?

Please precise your thoughts on this. Right now I guess you mean
removing the requirement that it be all '0's so that it can be
replicated? What do you mean by "create two contexts for the same flow"?
 
> if the chain contains several extension headers.

We can always improve to include this. Any suggestions?
 
> I'm not sure we've reached thirty thousand RFCs just yet ;-)

Will we get there? ;-)

> IP-ID fields for replication.

Yes, we could. I can update that too.
 
> discard some of the payload data (at a cost of reduced speech

Sorry, the question in the draft was not clear. It was meant as "how
much can we save for UPD and UDP-Lite, really? Is it worth it?"

Thanks again for you comments. I'll get back on the other unanswered
questions later. I'll try to reflect your comments properly in the next
update to this draft.

/Ghyslain