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

From: Ghyslain Pelletier <[email-masked]>
Date: Wed, 04 Jun 2003 10:19:35 +0200

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

---

From: [email-masked]
Date: Wed, 4 Jun 2003 18:22:43 -0500

Hi, 
I have some thoughts on some of the Richard's comments. Please search for [Yousuf] below.

Cheers,
Yousuf

-----Original Message-----
From: ext Price, Richard [mailto:[email-masked]]
Sent: Wednesday, June 04, 2003 9:41 AM
To: 'Ghyslain Pelletier'; [email-masked]
Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed

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.

[Yousuf] I think it is possible to use STATIC-NACK for indicating corruption in the base context, and another NACK for indicating transmission error in IR-REPLICATE packet. We have two CRCs. 7-bit CRC covers the original uncompressed header and the 8-bit CRC covers the IR packet including static and dynamic chain (this is with the change proposed in my last email). If 8-bit CRC verifies integrity of IR-REPLICATE packet header, but the 7-bit CRC failed after decompression, then this implies that we have a problem in the base context. In this case only the decompressor will send a STATIC-NACK indicating that the decompression failed due to the problem in the base context. The compressor would discard that base context and send IR packet.  

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.

[Yousuf] Can we solve this concern by adding IR-REPLICATE state between 
IR and CO state in the compressor state machine as shown below. 

                 Optimistic approach / ACK                 ACK
               +------>-------->------>------>---------+  +->-+
               |  Base Ctxt Avail          ACK         |  |   | 
               | +----------+     +---->---->---------||  |   |
               | |          V     |                   vv  |   v
           +----------+    +--------------+         +----------+
           | IR State |    | IR-REP State |         | CO State |
           +----------+    +--------------+         +----------+
               ^  ^         |    ^   |                  |
               |  +---<-----+    +-<-+                  |
               |    STATIC-NACK  Timeout/NACK           |
               |                                        |
               |  Timeout / NACK / STATIC-NACK          |
               +-------<-------<-------<-------<--------+

I think this is also what context context replication is doing. 

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,
>

---

From: "Price, Richard" <[email-masked]>
Date: Thu, 5 Jun 2003 17:31:28 +0100

> > A.1: Why didn't we define a flag for marking Traffic Class as
> > replicable? Is this because adding a bit would mean adding a byte and
> > that would exactly be the saving in the Traffic class case?
> 
> This can be added without requiring another octet. We could use codes
> insteads of flags. As Richard pointed out, we could also add hop limit
> as well. I can update that.

Hi,

It might be a good idea to switch from indicator flags to indicator codes,
as we save quite a few bytes due to not sending the flag bytes in every
IR-REPLICATE packet.

As a comparison, here's a set of IR-REPLICATE packet formats for TCP/IP,
using indicator codes rather than flags:

http://sigcomp.srmr.co.uk/~rjp/IR_REPLICATE.txt

N.B. The packet formats are generated automatically using the OH
algorithm, so we can choose the exact number of formats that are
generated (22 packet formats is probably more than we need!).

I also made a few other changes that might be useful for improving the
efficiency of the packet formats:

* Added 4 bits of MSN in every packet (I think that this will
  be useful for robustness).

* Added replication of the IP TOS and TTL.

* Added the ability to replicate the IP-ID (by sending varying
  numbers of LSBs).

* Added the ability to infer the TCP Ack field whenever it is set
  to 0.

* Eliminated the Data Offset (can be inferred at the decompressor).

Compression ratio is pretty good - minimum packet size is now 9 bytes
(plus framework overhead), compared to 18 bytes for the original proposal.

Regards,

Richard

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Fri, 6 Jun 2003 10:04:11 +0200

> > > A.1: Why didn't we define a flag for marking Traffic Class
> > > as replicable? Is this because adding a bit would mean
> > > adding a byte and that would exactly be the saving in the
> > > Traffic class case?
> > 
> > GP:
> > This can be added without requiring another octet. We could
> > use codes insteads of flags. As Richard pointed out, we could
> > also add hop limit as well. I can update that.

Just because it can be done does not mean it should be done. I
personally think we should limit the replication possibilities
to addresses (potentially including ports), as I think it would
be a mistake to make this mechanism too flexible and complex.
 
> As a comparison, here's a set of IR-REPLICATE packet formats 
> for TCP/IP, using indicator codes rather than flags:
> 

I know these are a little bit lengthy, but I would prefer to
still get these to the list. At this point, we do not need to
have many formats, discussions would rather benefit from
having small sets to look at and discuss.

/L-E

---

From: "Price, Richard" <[email-masked]>
Date: Fri, 6 Jun 2003 10:23:12 +0100

Hi,

It's worth remembering that if we limit the replication possibilities
to addresses, then we'll be unable to support more general mechanisms
such as Early Compression.

Moreover, I think it would be a mistake to assume that more flexible
packet formats are necessarily more complex. If you define the
packet formats using ROHC-FN, the set which I proposed is actually
somewhat easier to describe than Ghyslain's proposal (because it
is generated directly from the behaviour of TCP/IP). So we get the
extra efficiency and flexibility, without making the profile any
more complex.

Regards,

Richard

> having small sets to look at and discuss.

Here they are ...

Key:

"|" indicates the beginning/end of a field.

":" indicates that a field is split over multiple octets.

Abbreviations:

A                    = TCP_ACK_FLAG
B                    = TCP_ECN_BITS
E                    = IP_ECN_BITS
D                    = PADDING
P                    = TCP_PSH_FLAG
I                    = IP_DONT_FRAGMENT
TEB                  = TCP_ECN_BITS
TRF                  = TCP_RSF_FLAGS
MSN                  = MASTER_SEQ_NUMBER
T                    = TCP_URG_FLAG
IEB                  = IP_ECN_BITS

Packet 0:

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| 0   0 |      MSN      | T |   :
+---+---+---+---+---+---+---+---+
:  TRF  | P | A |  TEB  |  IEB  |
+---+---+---+---+---+---+---+---+
| I |   IP_ID   |    PADDING    |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        TCP_SEQ_NUMBER         :
+---+---+---+---+---+---+---+---+
:              ...              :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:         TCP_CHECKSUM          |
+---+---+---+---+---+---+---+---+

Packet 1:

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| 0   1   0 |      MSN      | T |
+---+---+---+---+---+---+---+---+
|    TRF    | P | A |  TEB  | E :
+---+---+---+---+---+---+---+---+
:   | I |   IP_ID   |  PADDING  |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        TCP_SEQ_NUMBER         :
+---+---+---+---+---+---+---+---+
:              ...              :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|        TCP_SOURCE_PORT        |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:         TCP_CHECKSUM          |
+---+---+---+---+---+---+---+---+

Packet 2:

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| 0   1   1 |      MSN      | T |
+---+---+---+---+---+---+---+---+
|    TRF    | P | A |  TEB  | E :
+---+---+---+---+---+---+---+---+
:   | I |   IP_ID   |  PADDING  |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        TCP_SEQ_NUMBER         :
+---+---+---+---+---+---+---+---+
:              ...              :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|         TCP_DEST_PORT         |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:         TCP_CHECKSUM          |
+---+---+---+---+---+---+---+---+

Packet 3:

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| 1   0   0   0 |      MSN      |
+---+---+---+---+---+---+---+---+
| T |    TRF    | P | A |  TEB  |
+---+---+---+---+---+---+---+---+
|  IEB  | I |   IP_ID   |   D   |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        TCP_SEQ_NUMBER         :
+---+---+---+---+---+---+---+---+
:              ...              :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:         TCP_CHECKSUM          |
+---+---+---+---+---+---+---+---+
|        IP_TIME_TO_LIVE        |
+---+---+---+---+---+---+---+---+

Packet 4:

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| 1   0   0   1 |      MSN      |
+---+---+---+---+---+---+---+---+
| T |    TRF    | P | A |  TEB  |
+---+---+---+---+---+---+---+---+
|  IEB  | I |   IP_ID   |   D   |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        TCP_ACK_NUMBER         :
+---+---+---+---+---+---+---+---+
:              ...              :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        TCP_SEQ_NUMBER         :
+---+---+---+---+---+---+---+---+
:              ...              :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:         TCP_CHECKSUM          |
+---+---+---+---+---+---+---+---+

Packet 5:

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| 1   0   1   0   0 |    MSN    :
+---+---+---+---+---+---+---+---+
:   | T |    TRF    | P | A | B :
+---+---+---+---+---+---+---+---+
:   |  IEB  | I |   IP_ID   | D |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        TCP_SEQ_NUMBER         :
+---+---+---+---+---+---+---+---+
:              ...              :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|         TCP_DEST_PORT         |
+---+---+---+---+---+---+---+---+
|        TCP_SOURCE_PORT        |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:         TCP_CHECKSUM          |
+---+---+---+---+---+---+---+---+

Packet 6:

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| 1   0   1   0   1 |    MSN    :
+---+---+---+---+---+---+---+---+
:   | T |    TRF    | P | A | B :
+---+---+---+---+---+---+---+---+
:   |  IEB  | I |    PADDING    |
+---+---+---+---+---+---+---+---+
|             IP_ID             |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        TCP_SEQ_NUMBER         :
+---+---+---+---+---+---+---+---+
:              ...              :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:         TCP_CHECKSUM          |
+---+---+---+---+---+---+---+---+

Packet 7:

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| 1   0   1   1   0 |    MSN    :
+---+---+---+---+---+---+---+---+
:   | T |    TRF    | P | A | B :
+---+---+---+---+---+---+---+---+
:   |  IEB  | I |   IP_ID   | D |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        TCP_SEQ_NUMBER         :
+---+---+---+---+---+---+---+---+
:              ...              :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|        TCP_SOURCE_PORT        |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:         TCP_CHECKSUM          |
+---+---+---+---+---+---+---+---+
|        IP_TIME_TO_LIVE        |
+---+---+---+---+---+---+---+---+

Packet 8:

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| 1   0   1   1   1 |    MSN    :
+---+---+---+---+---+---+---+---+
:   | T |    TRF    | P | A | B :
+---+---+---+---+---+---+---+---+
:   |  IEB  | I |   IP_ID   | D |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        TCP_SEQ_NUMBER         :
+---+---+---+---+---+---+---+---+
:              ...              :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|         TCP_DEST_PORT         |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:         TCP_CHECKSUM          |
+---+---+---+---+---+---+---+---+
|        IP_TIME_TO_LIVE        |
+---+---+---+---+---+---+---+---+

Packet 9:

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| 1   1   0   0   0 |    MSN    :
+---+---+---+---+---+---+---+---+
:   | T |    TRF    | P | A | B :
+---+---+---+---+---+---+---+---+
:   |  IEB  | I |   IP_ID   | D |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        TCP_ACK_NUMBER         :
+---+---+---+---+---+---+---+---+
:              ...              :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        TCP_SEQ_NUMBER         :
+---+---+---+---+---+---+---+---+
:              ...              :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|        TCP_SOURCE_PORT        |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:         TCP_CHECKSUM          |
+---+---+---+---+---+---+---+---+

Packet 10:

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| 1   1   0   0   1   0 |  MSN  :
+---+---+---+---+---+---+---+---+
:       | T |    TRF    | P | A |
+---+---+---+---+---+---+---+---+
|  TEB  |  IEB  | I |   IP_ID   |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        TCP_ACK_NUMBER         :
+---+---+---+---+---+---+---+---+
:              ...              :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        TCP_SEQ_NUMBER         :
+---+---+---+---+---+---+---+---+
:              ...              :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|         TCP_DEST_PORT         |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:         TCP_CHECKSUM          |
+---+---+---+---+---+---+---+---+

Packet 11:

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| 1   1   0   0   1   1 |  MSN  :
+---+---+---+---+---+---+---+---+
:       | T |    TRF    | P | A |
+---+---+---+---+---+---+---+---+
|  TEB  |  IEB  | I |   IP_ID   |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        TCP_ACK_NUMBER         :
+---+---+---+---+---+---+---+---+
:              ...              :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        TCP_SEQ_NUMBER         :
+---+---+---+---+---+---+---+---+
:              ...              :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:         TCP_CHECKSUM          |
+---+---+---+---+---+---+---+---+
|        IP_TIME_TO_LIVE        |
+---+---+---+---+---+---+---+---+

Packet 12:

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| 1   1   0   1   0   0   0 |   :
+---+---+---+---+---+---+---+---+
:    MSN    | T |    TRF    | P |
+---+---+---+---+---+---+---+---+
| A |  TEB  |  IEB  | I |   D   |
+---+---+---+---+---+---+---+---+
|             IP_ID             |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        TCP_SEQ_NUMBER         :
+---+---+---+---+---+---+---+---+
:              ...              :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|        TCP_SOURCE_PORT        |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:         TCP_CHECKSUM          |
+---+---+---+---+---+---+---+---+

Packet 13:

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| 1   1   0   1   0   0   1 |   :
+---+---+---+---+---+---+---+---+
:    MSN    | T |    TRF    | P |
+---+---+---+---+---+---+---+---+
| A |  TEB  |  IEB  | I |   D   |
+---+---+---+---+---+---+---+---+
|             IP_ID             |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        TCP_SEQ_NUMBER         :
+---+---+---+---+---+---+---+---+
:              ...              :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|         TCP_DEST_PORT         |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:         TCP_CHECKSUM          |
+---+---+---+---+---+---+---+---+

Packet 14:

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| 1   1   0   1   0   1   0 |   :
+---+---+---+---+---+---+---+---+
:    MSN    | T |    TRF    | P |
+---+---+---+---+---+---+---+---+
| A |  TEB  |  IEB  | I | IP_ID :
+---+---+---+---+---+---+---+---+
:   |          PADDING          |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        TCP_SEQ_NUMBER         :
+---+---+---+---+---+---+---+---+
:              ...              :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|         TCP_DEST_PORT         |
+---+---+---+---+---+---+---+---+
|        TCP_SOURCE_PORT        |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:         TCP_CHECKSUM          |
+---+---+---+---+---+---+---+---+
|        IP_TIME_TO_LIVE        |
+---+---+---+---+---+---+---+---+

Packet 15:

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| 1   1   0   1   0   1   1 |   :
+---+---+---+---+---+---+---+---+
:    MSN    | T |    TRF    | P |
+---+---+---+---+---+---+---+---+
| A |  TEB  |  IEB  | I | IP_ID :
+---+---+---+---+---+---+---+---+
:   |          PADDING          |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        TCP_ACK_NUMBER         :
+---+---+---+---+---+---+---+---+
:              ...              :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        TCP_SEQ_NUMBER         :
+---+---+---+---+---+---+---+---+
:              ...              :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|         TCP_DEST_PORT         |
+---+---+---+---+---+---+---+---+
|        TCP_SOURCE_PORT        |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:         TCP_CHECKSUM          |
+---+---+---+---+---+---+---+---+

Packet 16:

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| 1   1   0   1   1   0   0 |   :
+---+---+---+---+---+---+---+---+
:    MSN    | T |    TRF    | P |
+---+---+---+---+---+---+---+---+
| A |  TEB  |  IEB  | I |   D   |
+---+---+---+---+---+---+---+---+
|             IP_ID             |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        TCP_SEQ_NUMBER         :
+---+---+---+---+---+---+---+---+
:              ...              :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:         TCP_CHECKSUM          |
+---+---+---+---+---+---+---+---+
|        IP_TIME_TO_LIVE        |
+---+---+---+---+---+---+---+---+

Packet 17:

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| 1   1   0   1   1   0   1 |   :
+---+---+---+---+---+---+---+---+
:    MSN    | T |    TRF    | P |
+---+---+---+---+---+---+---+---+
| A |  TEB  |  IEB  | I |   D   |
+---+---+---+---+---+---+---+---+
|             IP_ID             |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        TCP_ACK_NUMBER         :
+---+---+---+---+---+---+---+---+
:              ...              :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        TCP_SEQ_NUMBER         :
+---+---+---+---+---+---+---+---+
:              ...              :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:         TCP_CHECKSUM          |
+---+---+---+---+---+---+---+---+

Packet 18:

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| 1   1   0   1   1   1   0 |   :
+---+---+---+---+---+---+---+---+
:    MSN    | T |    TRF    | P |
+---+---+---+---+---+---+---+---+
| A |  TEB  |  IEB  | I | IP_ID :
+---+---+---+---+---+---+---+---+
:   |          PADDING          |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        TCP_ACK_NUMBER         :
+---+---+---+---+---+---+---+---+
:              ...              :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        TCP_SEQ_NUMBER         :
+---+---+---+---+---+---+---+---+
:              ...              :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|        TCP_SOURCE_PORT        |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:         TCP_CHECKSUM          |
+---+---+---+---+---+---+---+---+
|        IP_TIME_TO_LIVE        |
+---+---+---+---+---+---+---+---+

Packet 19:

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| 1   1   0   1   1   1   1   0 |
+---+---+---+---+---+---+---+---+
|      MSN      | T |    TRF    |
+---+---+---+---+---+---+---+---+
| P | A |  TEB  |  IEB  | I |   :
+---+---+---+---+---+---+---+---+
: IP_ID |        PADDING        |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        TCP_ACK_NUMBER         :
+---+---+---+---+---+---+---+---+
:              ...              :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        TCP_SEQ_NUMBER         :
+---+---+---+---+---+---+---+---+
:              ...              :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|         TCP_DEST_PORT         |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:         TCP_CHECKSUM          |
+---+---+---+---+---+---+---+---+
|        IP_TIME_TO_LIVE        |
+---+---+---+---+---+---+---+---+

Packet 20:

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| 1   1   0   1   1   1   1   1 |
+---+---+---+---+---+---+---+---+
|      MSN      | T |    TRF    |
+---+---+---+---+---+---+---+---+
| P | A |  TEB  |  IEB  | I | D |
+---+---+---+---+---+---+---+---+
|             IP_ID             |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        TCP_SEQ_NUMBER         :
+---+---+---+---+---+---+---+---+
:              ...              :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|         TCP_DEST_PORT         |
+---+---+---+---+---+---+---+---+
|        TCP_SOURCE_PORT        |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:         TCP_CHECKSUM          |
+---+---+---+---+---+---+---+---+

Packet 21:

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| 1   1   1 | T |    TRF    | P |
+---+---+---+---+---+---+---+---+
| A |  TEB  |  IEB  | I |       :
+---+---+---+---+---+---+---+---+
:    IP_TOS     |    PADDING    |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:       MASTER_SEQ_NUMBER       |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        TCP_URG_POINTER        |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:          TCP_WINDOW           |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:             IP_ID             |
+---+---+---+---+---+---+---+---+
|     TCP_OPTIONS_PRESENCE      |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:       TCP_OPTIONS_ORDER       :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        TCP_ACK_NUMBER         :
+---+---+---+---+---+---+---+---+
:              ...              :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        TCP_SEQ_NUMBER         :
+---+---+---+---+---+---+---+---+
:              ...              :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:         TCP_DEST_PORT         |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        TCP_SOURCE_PORT        |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:         TCP_CHECKSUM          |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:        IP_DEST_ADDRESS        :
+---+---+---+---+---+---+---+---+
:              ...              :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|                               :
+---+---+---+---+---+---+---+---+
:       IP_SOURCE_ADDRESS       :
+---+---+---+---+---+---+---+---+
:              ...              :
+---+---+---+---+---+---+---+---+
:              ...              |
+---+---+---+---+---+---+---+---+
|        IP_TIME_TO_LIVE        |
+---+---+---+---+---+---+---+---+
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Hongbin Liao \(Intl Staffing\)" <[email-masked]>
Date: Fri, 6 Jun 2003 18:57:29 +0800

Hi, Richard
	Could u give the ``formal notation'' for IR-REPLICATE? It is not clear how that code points are generated?

Regards
Hongbin
06/06/2003

> From: Price, Richard [mailto:[email-masked]] 
> Sent: Friday, June 06, 2003 5:23 PM
> To: 'Lars-Erik Jonsson (EAB)'; [email-masked]
> > > > > replicable? Is this because adding a bit would mean adding a 
> > > > > byte and that would exactly be the saving in the 
> Traffic class 
> > > > > case?
> > > > 
> > > > GP:
> > > > This can be added without requiring another octet. We could use 
> > > > codes insteads of flags. As Richard pointed out, we 
> could also add 
> > > > hop limit as well. I can update that.
> > 
> > personally think we should limit the replication possibilities to 
> > addresses (potentially including ports), as I think it would be a 
> > mistake to make this mechanism too flexible and complex.
> 
> Hi,
> 
> It's worth remembering that if we limit the replication 
> possibilities to addresses, then we'll be unable to support 
> more general mechanisms such as Early Compression.
> 
> Moreover, I think it would be a mistake to assume that more 
> flexible packet formats are necessarily more complex. If you 
> define the packet formats using ROHC-FN, the set which I 
> proposed is actually somewhat easier to describe than 
> Ghyslain's proposal (because it is generated directly from 
> the behaviour of TCP/IP). So we get the extra efficiency and 
> flexibility, without making the profile any more complex.
> 
> Regards,
> 
> Richard
> 
> > I know these are a little bit lengthy, but I would prefer 
> to still get 
> > these to the list. At this point, we do not need to have 
> many formats, 
> > discussions would rather benefit from having small sets to 
> look at and 
> > discuss.
> 
> Here they are ...
> 
> Key:
>

---

From: "Price, Richard" <[email-masked]>
Date: Fri, 6 Jun 2003 12:22:25 +0100

Hi Hongbin,

I've attached the ROHC-FN description of the IR-REPLICATE
packet formats. It's almost identical to the description
of the CO packet formats, with a couple of tweaks  - I've
deleted some encodings that are useful in the CO packets,
but probably won't be needed for IR-REPLICATE packets.

Regards,

Richard

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

ir_replicate_formats  ::=   ordinary_huffman(tcp_ip_header)

tcp_ip_header         ::=   create_msn
                            ip_header
                            tcp_header
                            master_seq_number

ip_header             ::=   inferred_ip_checksum
                            inferred_size(16,-16)
                            ip_version
                            ip_header_length
                            ip_tos
                            ip_length
                            ip_id
                            ip_reserved
                            ip_dont_fragment
                            ip_more_fragments
                            ip_offset
                            ip_time_to_live
                            ip_protocol
                            ip_checksum
                            ip_source_address
                            ip_dest_address

tcp_header            ::=   tcp_checksum
                            tcp_source_port
                            tcp_dest_port
                            tcp_seq_number
                            tcp_ack_number
                            tcp_data_offset
                            tcp_reserved
                            tcp_ip_ecn_fields
                            tcp_urg
                            tcp_ack_flag
                            tcp_psh_flag
                            tcp_rsf_flags
                            tcp_window
                            tcp_urg_fields

master_seq_number     ::=   next_field(msn)
                            lsb(4,0) // irregular(16)

ip_version            ::=   value(4,4)

ip_header_length      ::=   value(4,5)

ip_tos                ::=   static // irregular(6)
                            label(2,ecn)

ip_length             ::=   skip(16)

ip_id                 ::=   inferred_offset(16,msn)
                            lsb(3,0) 90% / lsb(8,0) 10% // irregular(16)

ip_reserved           ::=   value(1,0)

ip_dont_fragment      ::=   irregular(1)

ip_more_fragments     ::=   value(1,0)

ip_offset             ::=   value(13,0)

ip_time_to_live       ::=   static 80% / irregular(8) 20%

ip_protocol           ::=   value(8,6)

ip_checksum           ::=   skip(16)

ip_source_address     ::=   static // irregular(32)

ip_dest_address       ::=   static // irregular(32)

tcp_source_port       ::=   static 70% / lsb(8,0) 30% // irregular(16)

tcp_dest_port         ::=   static 70% / lsb(8,0) 30% // irregular(16)

tcp_seq_number        ::=   irregular(32)

tcp_ack_number        ::=   value(32,0) 80% / irregular(32) 20%

tcp_data_offset       ::=   label(4,data_offset)

tcp_reserved          ::=   value(4,0)

tcp_ip_ecn_fields     ::=   next_field(ecn)
                            ip_ecn_bits
                            tcp_ecn_bits

ip_ecn_bits           ::=   irregular(2)

tcp_ecn_bits          ::=   irregular(2)

tcp_urg               ::=   label(1,urg_flag)

tcp_ack_flag          ::=   irregular(1)

tcp_psh_flag          ::=   irregular(1)

tcp_rsf_flags         ::=   irregular(3)

tcp_window            ::=   static // irregular(16)
                            skip(16)

tcp_checksum          ::=   irregular(16)

tcp_urg_fields        ::=   next_field(urg_flag)
                            urgf_zero // urgf_one

urgf_zero             ::=   tcp_urg_flag
                            static

urgf_one              ::=   tcp_urg_flag
                            tcp_urg_pointer

tcp_urg_flag          ::=   irregular(1)

tcp_urg_pointer       ::=   irregular(16)

> From: Hongbin Liao (Intl Staffing) [mailto:[email-masked]]
> Sent: Friday, June 06, 2003 11:57 AM
> To: Price, Richard; Lars-Erik Jonsson (EAB); [email-masked]
> 	Could u give the ``formal notation'' for IR-REPLICATE? 
> It is not clear how that code points are generated?
> 
> Regards
> Hongbin
> 06/06/2003
> 
> > > > > > byte and that would exactly be the saving in the Traffic class 
> > > > > > case?
> > > > > 
> > > > > GP:
> > > > > codes insteads of flags. As Richard pointed out, we could also add 
> > > I know these are a little bit lengthy, but I would prefer to still get 
> > > these to the list. At this point, we do not need to have many formats, 
> > > discussions would rather benefit from having small sets to look at and 
> > > discuss.
> > 
> > Here they are ...
> > 
> > Key:
> >

---

From: [email-masked]
Date: Fri, 6 Jun 2003 07:31:31 -0500

I would also support Richard's thoughts that we should not limit replication to few fields, like addresses and ports. Also, using codes instead of flags is not adding complexity.

Regards,
Yousuf

-----Original Message-----
From: ext Price, Richard [mailto:[email-masked]]
Sent: Friday, June 06, 2003 4:23 AM
To: 'Lars-Erik Jonsson (EAB)'; [email-masked]
Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed

Hi,

Regards,

Richard

Here they are ...

Key:

Abbreviations:

A                    = TCP_ACK_FLAG
B                    = TCP_ECN_BITS
E                    = IP_ECN_BITS
D                    = PADDING
P                    = TCP_PSH_FLAG
I                    = IP_DONT_FRAGMENT
TEB                  = TCP_ECN_BITS
TRF                  = TCP_RSF_FLAGS
MSN                  = MASTER_SEQ_NUMBER
T                    = TCP_URG_FLAG
IEB                  = IP_ECN_BITS

Packet 0:

  0   1   2   3   4   5   6   7

Packet 1:

  0   1   2   3   4   5   6   7

Packet 2:

  0   1   2   3   4   5   6   7

Packet 3:

  0   1   2   3   4   5   6   7

Packet 4:

  0   1   2   3   4   5   6   7

Packet 5:

  0   1   2   3   4   5   6   7

Packet 6:

  0   1   2   3   4   5   6   7

Packet 7:

  0   1   2   3   4   5   6   7

Packet 8:

  0   1   2   3   4   5   6   7

Packet 9:

  0   1   2   3   4   5   6   7

Packet 10:

  0   1   2   3   4   5   6   7

Packet 11:

  0   1   2   3   4   5   6   7

Packet 12:

  0   1   2   3   4   5   6   7

Packet 13:

  0   1   2   3   4   5   6   7

Packet 14:

  0   1   2   3   4   5   6   7

Packet 15:

  0   1   2   3   4   5   6   7

Packet 16:

  0   1   2   3   4   5   6   7

Packet 17:

  0   1   2   3   4   5   6   7

Packet 18:

  0   1   2   3   4   5   6   7

Packet 19:

  0   1   2   3   4   5   6   7

Packet 20:

  0   1   2   3   4   5   6   7

Packet 21:

  0   1   2   3   4   5   6   7

---

From: [email-masked]
Date: Fri, 6 Jun 2003 07:47:24 -0500

Hi Ghyslain,
Thanks for providing clarification. Few inline comments below.

Regards,
Yousuf

-----Original Message-----
From: ext Ghyslain Pelletier [mailto:[email-masked]]
Sent: Thursday, June 05, 2003 9:45 AM
To: Saifullah Yousuf (NRC/Dallas)
Cc: [email-masked]
Subject: Re: [rohc] ROHC-TCP: Update and some topics to be discussed

Hi Yousuf,

Thanks for your comments. Some answers in-line. I will get back to some
of the issues I won't address in this mail in a later mail.

Regards,

/Ghyslain

[email-masked] wrote:
> 
> Hi Gyslain,
> 
> The following are my comments on the context replication draft (draft-pelletier-rohc-context-replication-00.txt):
> 
> - Section 3.2.2: What is "OPTIONAL improved forward transition"?
> I was not able to find any description for this term.

This is written in the same way as in RFC-3095, section 5.4.1.1.
Basically, what this means is that it is not necessary - the compressor
may still transit to a higher state, but it can help such a transition
to happen faster.

> - Section 3.2.2.1 - last two paras: NACK is not sent in response to
> IR-REPLICATE. Instead, it looks like that it is a general failure
> information procedure for informing decompression of a subsequent
> packet not IR-REPLICATE. I think these two paras are irrelevant to
> context replication. I'd suggest to either take out these paras or
> explicitly mention that this is a general failure procedure.

I am not sure that I understand the first statement in the comment. What
do you mean by "NACK is not sent in response to IR-REPLICATE"? I'd like
you to bring some precisions so I can bring you a better answer. Section
3.3.2. of the draft states that the decompressor can send a NACK in
response to an IR-REPLICATE in some cases.

[Yousuf] Your answer under the following comment has provided the clarification. Thanks!
 
> - Section 3.3.2 - Third para: Could you please clarify when the
> compressor will be sending IR-REPLICATE packets as subsequent packets
> after receiving ACK for successful decompression of the initial
> IR-REPLICATE. The decompressor after successfully validating
> IR-REPLICATE will send ACK, which moves the compressor from IR to CO
> state (taking ROHC-TCP state machine). I think in this state the
> compressor will be sending compressed packets not IR-REPLICATE.

I think that we do not prevent the IR-REPLICATE to be sent and
decompressed in other states than IR state, that is we do not prevent it
(and I don't think we can anyway) to be used as an ordinary packet.

[snip]
[I'll get back on the feedback and failure mechanism.]
[I think this should be taken separately.]

> 
> Section 3.4.1 - third para: The way I understood this para is that
> the 8-bit CRC could cover entire IR header but a profile may not do
> that and the reason is in section 5.2.6 of RFC 3095. I was unable to
> find the explanation in the reference, could you please explain this
> limitation.

Recall point 10) in section 5.2.6. of RFC-3095 states:

 10) If the packet type is IR, the profile indicated in the IR packet
     determines how it is to be processed.  If the CRC fails to verify
     the packet, it MUST be discarded.  If a profile is indicated in
     the context, the logic of that profile determines what, if any,
     feedback is to be sent.  If no profile is noted in the context,
     no further action is taken.

This is framework logic, and the IR-REPLICATE is also an IR packet. The
text in the context replication draft states the consequence of that
point for the IR-REPLICATE regarding the type of CRC, its presence in an
IR packet (thus this applies to the IR-REPLICATE as well) and nature of
what it protects (e.g. it cannot be redefined to cover say the original
uncompressed header instead). Therefore only the extent of the CRC
coverage can be redefined by a profile and it must meet the minimal
coverage required (CID, Profile, etc. - that is at least the initial
part of the packet ending with the Profile field).

[Yousuf] The above text is clearer than the text in the draft. You may 
like to use the above clarification in the draft.
 
> Section 3.4.2 - IR-REPLICATE format figure: I think it would be more
> clear to show 7-bit CRC and Base CID in the figure. These fields are
> described but are not shown in the figure.

The 7-bit CRC (always present) and the Base CID (if present) are both
part of the profile specific information. This means that how they are
to be represented in the format depends on the packet format defined by
a specific profile, and this may vary from one profile to another.
Therefore it would not be appropriate in my opinion to show these fields
in the figure. Consider for example a profile that would define two
"sets" of packet formats, one of which includes the Base CID for when
the compressor wants to create a different context and keep the base
context, and one that doesn't for when we want to overwrite the base
context. Another profile might be defined so that the Base CID field is
always present in the format.

Still, it is appropriate for the text to mandate the presence of a 7-bit
CRC in the packet and mention that an identifier to the Base CID may be
present because these belong to the replication mechanism - their
functionality and nature is defined by context replication.
 
> Appendix A: Is this the intention that the formats mentioned in this
> Appendix will become standardized format? If that is the case, then I
> would suggest to put these formats in the main body of the draft not
> in appendix.

The appendix is informative. This is simply a suggestion to exemplify a
possible structure to the IR-REPLICATE packet. Other approaches than
chains (for example) might be taken. As said previously, this part is
profile specific, so I am not sure how/if we can make this part
normative in this document. See also my reply to Richard's comments on
this.

[Yousuf] At this moment the draft is suggesting it. But, eventually
the format of IR-REPLICATE packet per profile needs to be standardized. If not this document
then may be the per profile document would be the place to put this format as
normative text.

[Yousuf] That would be good. I would also support using codes and add all 
the fields.

> A.2: The two spare bits left in the first byte can be used for the
> replication flags for Type of Service and Identification fields. This
> will not cause any addition in the packet size. Could you please
> define the spare bits as the flags.

Yes, I can do that. As Richard pointed out, we could also add TTL as
well.

Thanks for your comment. I will get back on the question I haven't
answered in a later mail.

/Ghyslain

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Fri, 6 Jun 2003 15:22:39 +0200

> I would also support Richard's thoughts that we should not 
> limit replication to few fields, like addresses and ports. 
> Also, using codes instead of flags is not adding complexity.

If there had been any concrete arguments for doing so, that
had made sense. However, the usefulness of it has not been
presented. Actually, Carsten has several times asked us if we
can really present convincing arguments for context replication 
in general, which is a good guestion (still to be answered).
 
/L-E

---

From: [email-masked]
Date: Fri, 6 Jun 2003 09:31:39 -0500

The main argument is that developing a protocol with unnecessary limitation is going to limit the usefulness of the protocol. If replication could use fields other than addresses and ports from the base context, then that should be allowed in the protocol. This will provide more saving in the context establishment packet size.

Regarding the usefulness of context replication in general, one good argument is that the context replication reduces the size of context establishment packet. Thus, it performs compression right from the very first packet. 

This is more useful in short lived transactions. Without context replication the compressor will be sending the full header for context establishment. The compressor does not start compression until it is confident that the decompressor has built the context. The transfer of full header may continue for more than one packet, and by the time the compressor is confident the transaction could be over.

Another advantage is that decreasing the size of context establishment packet also decreases the transmission time and the chance of transmission error on the packet between the compressor and decompressor. Both of these help in speeding up the context build up at the decompressor, which in turn helps in faster transition into more efficient compression/decompression states.

Regards,
Yousuf

-----Original Message-----
From: ext Lars-Erik Jonsson (EAB)
[mailto:[email-masked]]
Sent: Friday, June 06, 2003 8:23 AM
To: [email-masked]
Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed

 
/L-E

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Fri, 6 Jun 2003 17:03:17 +0200

Yousuf,

> Regarding the usefulness of context replication in general, 
> one good argument is that the context replication reduces the 
> size of context establishment packet. Thus, it performs 
> compression right from the very first packet. 
> 
> This is more useful in short lived transactions. Without 
> context replication the compressor will be sending the full 
> header for context establishment. The compressor does not 
> start compression until it is confident that the decompressor 
> has built the context. The transfer of full header may 
> continue for more than one packet, and by the time the 
> compressor is confident the transaction could be over.
> 
> Another advantage is that decreasing the size of context 
> establishment packet also decreases the transmission time and 
> the chance of transmission error on the packet between the 
> compressor and decompressor. Both of these help in speeding 
> up the context build up at the decompressor, which in turn 
> helps in faster transition into more efficient 
> compression/decompression states.

We all know about these general arguments, but we must...

1) find "reasonable" cases when it really is possible to replicate
2) show that the relative gain is significant enough to justify
   new protocol solutions

These are questions that should be addressed for each new field we
intend to add replication support for.

> The main argument is that developing a protocol with 
> unnecessary limitation is going to limit the usefulness of 
> the protocol.

It is a fairly well established protocol design practice to limit 
protocol functionality to what is really useful. There are too
many unnecessary complex protocols out there, and we have seen
many cases where protocols are "re-used" for new things just
because they "could easily be extended for new purposes", while
it in general is not a technically good idea.

> If replication could use fields other than 
> addresses and ports from the base context, then that should 
> be allowed in the protocol. This will provide more saving in 
> the context establishment packet size.

If one can show 1) and 2) above, I might agree with you.

It is our mission to develop useful standards to address
known problems, but nothing more than that!

/L-E

P.S. Note that I personally believe there are cases when context
     replication might be useful. However, we are playing a 
     dangerous game here if we start adding more functionality
     just because we think it is cool (and possible to do).
     We have to show that what we develop is really useful.
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Price, Richard" <[email-masked]>
Date: Fri, 6 Jun 2003 16:07:41 +0100

Hi,

Context replication in general is extremely easy to justify, due
to the importance of getting a good compression ratio even on
short-lived TCP flows.

For example, consider one or more wireless SIP call setups running
over TCP (with compression of both SIP and TCP over the wireless
link). Each call setup will only consist of a handful of packets
in each direction, so "conventional" ROHC context establishment will
get little (if any) compression of the TCP headers before the
connection closes.

In SigComp we provided several mechanisms for optimising the
compression of short-lived flows (static dictionary, user-specific
dictionary etc.), and for TCP we must do the same. Context replication
will help significantly in the wireless environment by allowing us to
take advantage of redundancy between different TCP connections (as
the proposed packet formats show, we can get a 60-byte TCP/IPv6
header down to just 15 bytes even for the first packet of the flow).

Regards,

Richard

> From: Lars-Erik Jonsson (EAB) 
> Sent: Friday, June 06, 2003 2:23 PM
> To: [email-masked]

---

From: "Price, Richard" <[email-masked]>
Date: Fri, 6 Jun 2003 16:57:06 +0100

Hi,

I'd like to expand on my previous post with some concrete numbers
(which I hasten to add are only rough-and-ready approximations, but
hopefully should be good enough for our needs).

As a rough ballpark, in a 3G network we're aiming for a total
call setup time of between 1-2s. Anything above 2s we consider
unacceptable, and we believe that new protocol solutions are
required. Anything below 1s is "optimal", and further gain is not
especially important. Anything between 1-2s is "good enough" -
obviously the closer to 1s the better, but we would need to
take into account other factors such as protocol complexity before
necessarily opting for the more efficient solution.

A typical 3GPP call setup requires around 12 SIP messages (6 in
each direction). Total time to send these messages over an
8 kbit/s bearer is around 10s - completely unacceptable!

With SigComp we can reduce the time to send the SIP messages
themselves down to around 1.5s, which we consider to be "good
enough". However, if we have to send the underlying TCP/IPv6 headers
in full then we add an additional 12 * 60 / 1000 = 0.72s delay,
bringing the total call setup delay to around 2.25s (plus any
processing delay). This is outside the band that we're aiming for.

Thus, it would be really useful to be able to cut at least 1/3rd
off the average size of a TCP/IPv6 header, even when the number
of packets in the flow is very small. With conventional ROHC
context establishment mechanisms this is unlikely to be possible
(particularly if SIP is opening connections on a per-transaction
basis, i.e. every 2-3 messages). Therefore, I believe that we're
justified in considering context replication to improve the
compression ratio of short-lived flows.

> intend to add replication support for.

Alternatively, why not just base the IR-REPLICATE packets on the
ordinary CO packets themselves? This will give us much more
flexibility, and at less cost than creating brand new IR-REPLICATE
packets completely from scratch.

Regards,

Richard

---

From: [email-masked]
Date: Fri, 6 Jun 2003 11:29:02 -0500

Hi Lars-Erik,

> Sent: Friday, June 06, 2003 10:03 AM
> To: [email-masked]

[Yousuf] Good! At least we agree that context replication in general is useful :) 

> it in general is not a technically good idea.
[Yousuf] Using codes instead of flags (the idea from an earlier email from Richard) is
not adding any complexity and is also not adding any new protocol solution. The bits which are defined as flags will be defined as codes. They will be used in the same way for addresses and ports as for any other fields. Therefore, I don't see 2) as a concern. Regarding 1), any field replication
is a saving. If the same code mechanism can do that without adding any bits in the IR-REPLICATE format then I don't see a problem.  
IMHO there are protocols out there and their flexibility has made them more useful and popular without compromising any technicality.

Regards,
Yousuf

---

From: "Price, Richard" <[email-masked]>
Date: Mon, 16 Jun 2003 17:35:05 +0100

Hi,

I've added a few comments inline on the ROHC-TCP issues not related to
context replication.

One issue that isn't mentioned below is the packet formats themselves
(i.e. the CO packets and the IR-REPLICATE packets). This is the last
major gap in the ROHC-TCP profile - it would be great if we could fill
it in before Vienna, as we'd then have enough to offer a real, working
TCP compression scheme...

For the CO packets, we've made an initial proposal in:

http://www.ietf.org/internet-drafts/draft-price-rohc-tcp-packet-formats-00.t
xt

The draft lists the packet formats in both ROHC-FN form and box notation
form, so we can discuss the formats themselves without worrying about how
they're documented.

For the IR-REPLICATE packets there are currently two proposals - one
using indicator flags in the context replication draft, and one using
indicator codes in:

http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01523.html

If anyone has comments on either of the above, they would be much
appreciated!

Regards,

Richard

>     describing how to encode and decode each field in the header,

As well as deciding how to notate the TCP packet formats, we actually
need to design them in the first place ;-)

>   o Should we use static and dynamic chains, as in 3095?

The chain-based approach might be worth updating for ROHC-TCP, as there
is a lot of scope for compressing the Next Header/Kind fields that
indicate which items are present in the chain.

At a minimum, I think we should replace the Next Header/Kind fields from
the more common TCP options and IP extension headers with shorter
equivalents (e.g. there are 7 common TCP options, so it's enough to send
a 3-bit indicator rather than the entire Kind field in full). More
aggressive compression is possible, but we'd need to discuss whether we
actually need it or not.

>   o Compression of TCP options for IR/IR-DYN

We have quite a lot of flexibility here, depending on how aggressive
we want to make the compression. The proposed IR(-DYN) packet formats
in <draft-price-rohc-tcp-packet-formats-00.txt> keep things pretty
simple for the TCP options. We compress the "obvious" fields that can
always be inferred at the decompressor, such as the Length fields in
fixed-length options, but fields with more complex behaviour are always
sent uncompressed.

>     - "data offset" is redundant

Definitely worth compressing the Data Offset, as this is guaranteed to
work for all (valid) TCP packets. So we don't need any additional packet
formats...

>     - "IP protocol" can be derived from the profile number

Again, we should definitely do this, because it doesn't cost any
extra packet formats.

>     - "IP version" -> only two possible values, only one

Only saves 3 bits, but costs nothing, so let's go for it...

>     - "TTL", particularly when compressing over the first hop

Not sure about this one - would be useful for short-lived TCP flows,
but needs at least one additional packet format (to send the TTL in
full, just in case it can't be compressed for whatever reason).

>     - "MSN", could be LSB coded

In the IR(-DYN) packets we can't use LSB encoding for the MSN because
we don't have a value in the context. However, if we want more aggressive
compression than just sending the MSN in full, we could potentially
use an encoding method which we call "irregular_padded". It works
like LSB encoding, except that instead of getting the MSBs from the
context, the decompressor assumes that they are 0 instead. This allows
us to compress small values of the MSN down to a few bits right from
the first IR packet.

>   o initialization of MSN (0?)

I think that the most flexible solution would be to let the compressor
choose the initial value for the MSN, as it doesn't cause any
interoperability problems to initialise the MSN to a value other than 0.
Of course, the packet formats may influence this decision (e.g. by
encoding small values of the MSN more efficiently than large values).

>   o compression of MSN within the packet format (LSB coded?)

In the CO packets we can compress the MSN using LSB encoding (how
many LSBs to send in each packet format is an open issue, which is
discussed further in <draft-price-rohc-tcp-packet-formats-00.txt>).

In the IR(-DYN) packets we can't use LSB encoding, but we can use
"irregular_padded" encoding instead (see above).

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Tue, 17 Jun 2003 14:36:18 +0200

Richard,

> One issue that isn't mentioned below is the packet formats
> themselves (i.e. the CO packets and the IR-REPLICATE packets).
> This is the last major gap in the ROHC-TCP profile - it would
> be great if we could fill it in before Vienna, as we'd then
> have enough to offer a real, working TCP compression scheme...
> 
> draft-price-rohc-tcp-packet-formats-00.txt
> 
> The draft lists the packet formats in both ROHC-FN form and 
> box notation form, so we can discuss the formats themselves
> without worrying about how they're documented.

I do not think our problem here is in the details, but rather
how to put the formats in ROHC TCP. If we had known that, we 
could easily include a first-attempt format set and then improved
it, but I do not think that makes sense without first agreeing
on the format documentation approach.

/L-E

---

From: "Price, Richard" <[email-masked]>
Date: Tue, 17 Jun 2003 19:42:16 +0100

> The editor added formats for IR and IR-DYN in the ROHC-TCP draft because
> he unfortunately hadn't realized that you also had a proposal for those
> and was under the belief that the IRs would follow the same structure as
> in RFC-3095. The idea was also to generate discussions on those to at
> least move forward with IR formats, while waiting for the CO packets. I
> should have added an author's note to this effect in the draft. Mea
> culpa. Obviously the IRs will be adjusted based on agreements on the
> list.
> 
> On the other hand I do agree with Lars-Erik that the issue on how to
> document the packet formats is the pressing issue. While this does not
> prevent us to comment on the formats that you have suggested, it does
> make it hard to include them to the ROHC-TCP draft at this point.

I certainly agree that more discussion is required on how to present
the packet formats in ROHC-TCP. However, doesn't the same apply for the
IR and IR-DYN packets? We need to decide how to present them before we
can include them in the ROHC-TCP draft.

Regards,

Richard