Subject: [rohc] TCP 'shareable' fields

From: "West, Mark" <[email-masked]>
Date: Mon, 24 Feb 2003 08:53:38 -0000

Hi all,

Whilst there are a few nits, random references and other odd bits to finalise on the behaviour draft, the main outstanding item appears to be the discussion of 'shareable' TCP fields.  (Although, at the risk of making words up, I've changed the name to 'replicable', since I don't think that 'sharing' [old argument!] is an accurate description of how they are used).

Having finally got around to updating this, I thought I'd post some updated text for comments, prior to submitting the revised draft.  So, here it is...

4. Classification of replicable header fields

   Where multiple flows either overlap in time or occur sequentially
   within a short space of time there can be a great deal of similarity
   in header field values.  Such commonality of field values is
   reflected in the compression context.  Thus, it should be possible to
   utilise links between fields across different flows to improve the
   compression ratio.  In order to do this, it is important to
   understand the 'replicable' characteristics of the various header
   fields.

   The key concept is that of 'replication', where an existing context
   is used as a baseline and replicated to initialise a new context.
   Those fields that are the same are then automatically initialised in
   the new context.  Those that have changed will be updated or
   overwritten with values from the initialisation packet that triggered
   the replication.  This section considers the commonality between
   fields in different flows.

   It should be noted, however, that replication is based on contexts
   (rather than just field values) and so 'meta-fields' that are part of
   the context should also be included.  These, of course, are dependent
   upon the nature of the compression algorithm being applied.

   A brief analysis of the relationship of TCP/IP fields among
   'replicable' packet streams follows.

         'N/A' -- The field need not be considered in the replication
            process as it is inferred or known 'a priori' (and,
            therefore, does not appear in the context).

         'No' -- The field cannot be replicated since its change pattern
            between two packet flows is uncorrelated.

         'Yes' -- The field may be replicated.  This does not guarantee
            that the field value will be the same across two candidate
            streams, only that it might be possible to exploit
            replication to increase the compression ratio.  Specific
            encoding methods can be used to improve the compression
            efficiency.

4.1 IPv4 Header (inner and/or outer)

          +-----------------------+---------------+------------+
          | Field                 | Class         | Replicable |
          +-----------------------+---------------+------------+
          | Version               | STATIC        | N/A        |
          | Header Length         | STATIC-KNOWN  | N/A        |
          | DSCP                  | CHANGING      | No  (1)    |
          | ECT flag              | CHANGING      | No  (2)    |
          | CE flag               | CHANGING      | No  (2)    |
          | Packet Length         | INFERRED      | N/A        |
          | Identification        | CHANGING      | Yes (3)    |
          | Reserved flag         | CHANGING      | No  (4)    |
          | Don't Fragment flag   | CHANGING      | No         |
          | More Fragments flag   | STATIC-KNOWN  | N/A        |
          | Fragment Offset       | STATIC-KNOWN  | N/A        |
          | Time To Live          | CHANGING      | Yes        |
          | Protocol              | STATIC        | N/A        |
          | Header Checksum       | INFERRED      | N/A        |
          | Source Address        | STATIC-DEF    | Yes        |
          | Destination Address   | STATIC-DEF    | Yes        |
          +-----------------------+---------------+------------+

   (1) The DSCP is marked based on the application's requirements.  If
      it can be assumed that replicable connections often carry the same
      type of traffic, the DSCP may be regarded as replicable.  However,
      issues such as re-marking will need to be taken into account.

   (2) It is not possible for the ECN bits to be replicated (note that
      use of the ECN nonce scheme is anticipated).  However, it seems
      likely that all TCP flows between ECN-capable hosts will use ECN,
      the use (or not) of ECN for flows between the same end-points
      might be considered replicable.  See also note (4).

   (3) The replicable context for this field includes the IP-ID, NBO,
      and RND flags (as described in ROHC RTP).  This highlights that
      the replication is of the context, rather than just the header
      field values and, as such, needs to be considered based on the
      exact nature of compression applied to each field.

   (4) Since the possible future behavior of the 'Reserved Flag' cannot
      be predicted, it is not considered as replicable.  However, it
      might be expected that the behaviour of the reserved flag between
      the same end-points will be similar.  In this case, any selection
      of packet formats (for example) based on this behaviour might
      carry across to the new flow.  In the case of packet formats, this
      can probably be considered as a compressor-local decision.

4.2 IPv6 Header (inner and/or outer)

          +-----------------------+---------------+------------+
          | Field                 | Class         | Replicable |
          +-----------------------+---------------+------------+
          | Version               | STATIC        | N/A        |
          | Traffic Class         | CHANGING      | Yes (1)    |
          | ECT flag              | CHANGING      | No  (2)    |
          | CE flag               | CHANGING      | No  (2)    |
          | Flow Label            | STATIC-DEF    | N/A        |
          | Payload Length        | INFERRED      | N/A        |
          | Next Header           | STATIC        | N/A        |
          | Hop Limit             | CHANGING      | Yes        |
          | Source Address        | STATIC-DEF    | Yes        |
          | Destination Address   | STATIC-DEF    | Yes        |
          +-----------------------+---------------+------------+

   (1) See comment for IPv4, above.

   (2) See comment for IPv4, above.

4.3 TCP Header

          +-----------------------+---------------+------------+
          | Field                 | Class         | Replicable |
          +-----------------------+---------------+------------+
          | Source Port           | STATIC-DEF    |  Yes (1)   |
          | Destination Port      | STATIC-DEF    |  Yes (1)   |
          | Sequence Number       | CHANGING      |  No  (2)   |
          | Acknowledgement Number| CHANGING      |  No        |
          | Data Offset           | INFERRED      |  N/A       |
          | Reserved Bits         | CHANGING      |  No  (3)   |
          | Flags                 |               |            |
          |         CWR           | CHANGING      |  No  (4)   |
          |         ECE           | CHANGING      |  No  (4)   |
          |         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      |  Yes (5)   |
          +-----------------------+---------------+------------+

   (1) On the server side, the port number is likely to be a well-known
      value.  On the client side, the port number is generally selected
      by the stack automatically.  Whether the port number is replicable
      depends upon how the stack chooses the port number.  However, most
      implementations use a simple scheme which sequentially picks the
      next available port number.  This is clearly exploitable in a
      compression scheme.

   (2) With the recommendation (and expected deployment) of TCP Initial
      Sequence Number randomization, defined in RFC 1948 [13], it will
      be impossible to share the sequence number.  Thus, this field will
      not be regarded as replicable.

   (3) See comment (4) for the IPv4 header, above.

   (4) See comment (2) on ECN flags for the IPv4 header, above.

   (5) The urgent pointer is very rarely used.  This means that, in
      practice, the field may be considered replicable.

4.4 TCP Options

          +---------------------------+--------------+------------+
          | Option                    | SYN-only (1) | Replicable |
          +---------------------------+--------------+------------+
          | End of Option List        | No           | No   (2)   |
          | No-Operation              | No           | No   (2)   |
          | Maximum Segment Size      | Yes          | Yes        |
          | Window Scale              | Yes          | Yes        |
          | SACK-Permitted            | Yes          | Yes        |
          | SACK                      | No           | No         |
          | Timestamp                 | No           | No         |
          +---------------------------+--------------+------------+

   (1) This indicates whether the option only appears in SYN packet or
      not.  Options that are not 'SYN-only' may appear in any packet.

      Many TCP options are used only in SYN packets.  Some options, such
      as MSS, Window Scale, SACK-Permitted etc., will tend to have the
      same value among replicable packet streams.
      Thus, to support context sharing, the compressor should maintain
      such TCP options in the context (even though they only appear in
      the SYN segment).

   (2) Since these options have fixed values, they could be regarded as
      replicable.  However, the only interesting thing to convey about
      these options is their presence: if it is known that such an
      option exists, its value is defined.

4.5 Summary of replication

   From the above analysis, it can be seen that there are reasonable
   grounds for exploiting redundancy between flows, as well as between
   packets within a flow.  Simply consider the advantage of being able
   to elide the source and destination addresses for a repeated
   connection between two IPv6 endpoints.

   The final point to note for the use of replication is that it
   requires the compressor to have a suitable degree of confidence that
   the source data is present and correct at the decompressor.  This may
   place some restrictions on which of the 'changing' fields, in
   particular, can be utilised during replication.

... comments welcome!

Cheers,

Mark.

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

---

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

Mark,

This is a nice update and I do not have many comments. I think
the classification looks good, and overall we now seem to be
consistent with what we have agreed to during the last 9 months.

A few comments below!

Rgds,
/L-E

> Whilst there are a few nits, random references and other odd 
> bits to finalise on the behaviour draft, the main outstanding 
> item appears to be the discussion of 'shareable' TCP fields.  
> (Although, at the risk of making words up, I've changed the 
> name to 'replicable', since I don't think that 'sharing' [old 
> argument!] is an accurate description of how they are used).

Yes, this seems to be the common understanding since May -02.
Let's stick to that term, hopefully we will now at least be 
consistent at some places...=)

>    It should be noted, however, that replication is based on
>    contexts (rather than just field values) and so 'meta-fields'
>    that > are part of the context should also be included.
>    These, of course, are dependent upon the nature of the
>    compression algorithm being applied.

The last line would become clearer in our context if we modify and
extend it to:
"...the compression protocol (ROHC profile) being applied."

By the way, is it clear what is meant with "meta-fields"? It is
not to me. I guess you mean "data not part of the original 
headers", but does it make sense to replicate that? Do we need
to analyze what information might be considerable for that
purpose?

> 4.2 IPv6 Header (inner and/or outer)

Which comment for IPv4? We should probably clarify that the field
has a different name, i.e. refer to the actual v4 field.

>    connection between two IPv6 endpoints.

This summary is fine, but maybe we should also note already in this
summary that it is important to find a suitable trade-off, providing
the means of replicating a field will always imply a cost, and must
thus be justified by a reasonably gain.
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "West, Mark" <[email-masked]>
Date: Tue, 25 Feb 2003 13:37:02 -0000

Hi from SIPit...

I agree with and will incorporate your comments -- thanks!

BTW - yes 'meta-fields' means what you think it means; I will try to clarify.  My understanding is that you would actually replicate *context*, and the context is more than just the fields (e.g. the IP-ID Network Byte Order).  However, the behaviour of these additional things in the context is slightly outside of just the protocol behaviour.  I think...  Although, having said that, we do discuss the way the IP-ID behaves.  So perhaps I can bound the description a bit better.

Cheers,

Mark.

-----Original Message-----
From: Lars-Erik Jonsson (EAB)
To: West, Mark; [email-masked]'
Sent: 25/02/03 13:13
Subject: RE: [rohc] TCP 'shareable' fields

Mark,

A few comments below!

Rgds,
/L-E

---

From: "Price, Richard" <[email-masked]>
Date: Tue, 25 Feb 2003 14:31:40 -0000

Hi,

The so-called 'meta-fields' are mentioned in ROHC-TCP and also
the Formal Notation, but in these drafts they're known as
'control fields'.  It would be nice to use a consistent term
between all of the drafts.

I'm not sure that either of the current terms is particularly
descriptive - how about adopting a more explicit term such as
'compressor-created fields'?

Regards,

Richard

> From: West, Mark 
> Sent: Tuesday, February 25, 2003 1:37 PM
> To: 'Lars-Erik Jonsson (EAB) '; [email-masked]' '
> BTW - yes 'meta-fields' means what you think it means; I will 
> try to clarify.  My understanding is that you would actually 
> replicate *context*, and the context is more than just the 
> fields (e.g. the IP-ID Network Byte Order).  However, the 
> behaviour of these additional things in the context is 
> slightly outside of just the protocol behaviour.  I think...  
> Although, having said that, we do discuss the way the IP-ID 
> behaves.  So perhaps I can bound the description a bit better.
> 
> Cheers,
> 
> Mark.
> 
>