Subject: [rohc] context sharing issues on ROHC/TCP

From: "Hongbin Liao (Intl Staffing)" <[email-masked]>
Date: Mon, 4 Mar 2002 18:31:21 +0800

Hi, ROHCers
 
I would like to raise the discussion on context sharing for ROHC/TCP.
The following a brief study on the TCP field behavior among sharable
packet stream. After that, we may design the profile (packet format) for
context sharing packet. Comments are welcome!
 
Hongbin L.
03/04/2002

Short-lived TCP transfers are dominant in current Web-dominant Internet.
It
will degrade the performances of header compression schemes which
establish a
new context by sending full headers initially. Context sharing is
introduced
to minize the cost of context initiation headers.
 
The following is a study on TCP/IP field behavior between two 'sharable'
packet stream or context. Also, several issues is raised on context
sharing.

TERMS
 
'sharable'      - Two packet streams are defined as sharable if they
belong
                  to the same profile (ROHC/TCP, etc.) AND have at least
one
                  identical IP address (Source Address or Destination
Address).
 
                - The sharable property of a field specifiy how similar
the
                  value in a new context is to the one in the previous
                  context.
                  (whether a new context concurrently sharing data with
                  another context, or a reused context sharing data with
the
                  previous context)
                  A field's sharable property specified how similar the
field
                  values are in the sharable packet streams. It has the
                  following values:
 
        'N/A'   - The field is unnecessary to be shared since it can be
                  inferred or used to define a packet stream
 
        'No'    - The field is impossibel to be shared since its change
                  pattern between two packet streams are irregular
 
        'Yes'   - The field is possibel to be shared. Optimized encoding
                  method can be used to improve the compression
efficiency.

IPv4 Header (inner and/or outer)
 
Field                   Class           Sharable
------------------------------------------------
Version                 STATIC          N/A
Header Length           STATIC-KNOWN    Yes
Type Of Service         CHANGING        No
Packet Length           INFERRED        N/A
Identification          CHANGING        Yes (1)
Reserved flag           STATIC-KNOWN    Yes
Don't Fragment flag     STATIC          No
More Fragments flag     STATIC-KNOWN    No
Fragment Offset         STATIC-KNOWN    No
Time To Live            CHANGING        Yes
Protocol                STATIC          N/A
Header Checksum         INFERRED        N/A
Source Address          STATIC-DEF      N/A
Destination Address     STATIC-DEF      N/A
 
(1) the sharable context for this field includes IP-ID, NBO, and RND
flags

IPv6 Header (inner and/or outer)
 
Field                   Class           Sharable
------------------------------------------------
Version                 STATIC          N/A
Traffic Class           CHANGING        No
Flow Label              STATIC-DEF      N/A
Payload Length          INFERRED        N/A
Next Header             STATIC          N/A
Hop Limit               CHANGING        Yes
Source Address          STATIC-DEF      N/A
Destination Address     STATIC-DEF      N/A

TCP Header
 
Field                   Class           Sharable
------------------------------------------------
Source Port             STATIC-DEF      Yes (2)
Destination Port        STATIC-DEF      Yes (2)
Sequence Number         CHANGING        Yes (3)
Acknowledgement Number  CHANGING        No
Data Offset             INFERRED        N/A
Reserved Bits           CHANGING        Yes (4)
Control Bits
        URG             CHANGING        No
        ACK             CHANGING        No
        PSH             CHANGING        No
        RST             CHANGING        No
        SYN             CHANGING        No
        FIN             CHANGING        No
Window                  CHANGING        Yes
CHECKSUM                CHANGING        No
Urgent Pointer          CHANGING        No
 
(2) On the server side, the port number should be well-known value. On
the
    client side, the port number is selected by OS automatically.
Whether the
    port number is sharable depends on how the OS chooses port number.
    However, most implementation uses a simple scheme which just search
next
    available port number.
 
(3) With the deployment of TCP Initial Sequence Number Randomization,
the
    Sequence Number will be impossible to share at all.
 
(4) Don't include ECN flags if ECT is enabled

ECN Flags
 
Field                   Class           Sharable
------------------------------------------------
ECT                     CHANGING        Yes
CE                      CHANGING        No
ECN                     CHANGING        No
CWR                     CHANGING        No

TCP Options
 
Option                          SYN-only (5)    Sharable
------------------------------------------------
End of option list Option       No              No
No-Operation Option             No              No
Maximum Segment Size Option     Yes             Yes
Window Scale Option             Yes             Yes
SACK-Permitted Option           Yes             Yes
SACK Option                     No              No
Timestamps Option               No              Yes
 
(5) SYN-only means whether the options appear in SYN packets only. For
'Yes',
the option only appears in SYN packets; otherwise, the option may appear
in
SYN packets or not.
 
Because most TCP options are used only in SYN packet, header compression
schemes that don't support context sharing may not include these options
in
the context. However, two sharable packet stream likely have the same
TCP
options, e.g., the same MSS, Window Scale, SACK-Permitted and etc.,
context
sharing mechanism should maintain such options in the context.

Issues on context sharing
 
1. How to select an existing context as the sharable context of the new
packet
   stream?
   This problem is splitted into two sub-issues:
   The fisrt one is how to define two packet streams are sharable? The
above
   statement assumes a sharable packet stream has at least one identical
IP
   address. However, it is possible two packet streams with two
completely
   different IP address can also share contexts. For example, two
different
   clients visit a Web service which is built as a cluster of identical
   servers in the same IP subnet. Since hosts in the same IP subnet tend
to
   have identical TCP/IP implementation, these two packet streams are
   sharable. A simple solution is to provide several network address
plus
   network mask.  When comparing IP addresses, the scheme uses network
   addresses and masks to check whether two IP addresses are from the
same IP
   subnet.
   The other issue is that, even there is an exact definition of
sharable
   packet streams, it would be possible there are two or more candidate
packet
   streams. Which one should be selected? A random one or a recent one?
A
   recent context may be more preferable.
 
2. Context sharing between different profiles?
   Can a TCP context benefits from a RTP context? How much the gain is?
How
   complex the scheme will be? The simplest solution may forbid it at
all.

Comments are welcome!

---

From: "West, Mark (ITN)" <[email-masked]>
Date: Wed, 06 Mar 2002 00:17:00 +0000

Hi Hongbin,

Thanks for this.  Just a few brief comments in-line...

Cheers,

Mark.

Hongbin Liao (Intl Staffing) wrote:

 > Short-lived TCP transfers are dominant in current Web-dominant 
Internet. It
introduced
sharing.
belong
 >                   to the same profile (ROHC/TCP, etc.) AND have at 
least one
 >                 - The sharable property of a field specifiy how 
similar the
 >                   another context, or a reused context sharing data 
with the
efficiency.
 > IPv4 Header (inner and/or outer)

As far as TCP is concerned, I would rather view the TOS octet as a 6-bit
DSCP and 2 ECN bits.  I can imagine different transport protocols being
differently marked, but is it not possible that the DSCP could be shared
by multiple TCP flows?  (I'm not a QoS expert, so don't quote me...)

I would have thought that, since the possible future behaviour of the
'Reserved Flag' cannot be predicted, it should be considered as not
shareable.

flags
 > IPv6 Header (inner and/or outer)

Same argument as above for the traffic class octet.

 > Field                   Class           Sharable

I'm not sure why the window is seen as shareable.  It *might* be 
possible to initialise one context from another, but the fluctuations in 
window are per-flow.

 >
 > (2) On the server side, the port number should be well-known value. 
On the
 >     However, most implementation uses a simple scheme which just 
search next
 >     available port number.

Agreed.  It seems likely that port numbers can at least be intialised
from an existing context.

 >
 > (3) With the deployment of TCP Initial Sequence Number Randomization, the

This is true.  It may well be unwise to try and share the sequence 
number at all.

 > (4) Don't include ECN flags if ECT is enabled

I think that the ECN bits ought to be listed.
Ah - just seen the next section!  Apologies...

 > Field                   Class           Sharable

I think that we should at least consider that the IP ECN bits will not
necessarily be ECT/CE but will make use of the ECN nonce scheme.  This
would mean that none of the ECN flags could be shared.

 > the option only appears in SYN packets; otherwise, the option may 
appear in
 > SYN packets or not.>
 > schemes that don't support context sharing may not include these 
options in
 > the context. However, two sharable packet stream likely have the same TCP
context
 > sharing mechanism should maintain such options in the context.

This is a good point and an interesting concept.  Being able to make use
of common SYN options may well be worthwhile for short-lived connections.

Are you assuming that timestamps are shareable because they are 
time-based?  I guess I need to think about this one a bit more...

 >    The fisrt one is how to define two packet streams are sharable? 
The above
 >    statement assumes a sharable packet stream has at least one 
identical IP
completely
different
 >    servers in the same IP subnet. Since hosts in the same IP subnet 
tend to
 >    sharable. A simple solution is to provide several network address plus
 >    The other issue is that, even there is an exact definition of sharable
 >    streams. Which one should be selected? A random one or a recent one? A

Starting from the simplest point, the most likely case for sharing is
when the source and destination addresses match.  Anything more 
sophisticated than this is likely to be significantly more complex.

The main question appears to me to be the level of granularity that 
context sharing is allowed at.  To deal with the partial sharing that 
you have mentioned we need to be able to pick individual fields.
My concern is that if we allow sharing on selectable subsets of fields, 
we risk adding more overhead and complexity than we save.

I'll write some more on this when I've thought about it a bit more!

 >    Can a TCP context benefits from a RTP context? How much the gain 
is? How
all.

I'm not sure how much this would gain.  Sharing betwen profiles seems
like more trouble that it's worth.  (At least, this is my current opinion)

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

(Yes, I do know that my disclaimer is in an attachment.  And, no, I
didn't ask for it to be that way)