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

From: "Hongbin Liao (Intl Staffing)" <[email-masked]>
Date: Wed, 6 Mar 2002 16:25:12 +0800

Hi, Marks

Thanks for your comments. Please see my comments inline.

Hongbin L.
03/05/2002

> -----Original Message-----
> From: West, Mark (ITN) [mailto:[email-masked]] 
> Sent: Wednesday, March 06, 2002 8:17 AM
> To: Hongbin Liao (Intl Staffing)
> Cc: [email-masked]
> Subject: Re: [rohc] context sharing issues on ROHC/TCP
> 
> 
> 
> Hi Hongbin,
> 
> Thanks for this.  Just a few brief comments in-line...
> 
> Cheers,
> 
> Mark.
> 
> 
> Hongbin Liao (Intl Staffing) wrote:
> 
>  > 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
>  >
> 
> 
> 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...)
> 

The packet is marked based on application requirements. However, I agree
with you that TOS should be sharable.

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

Agree.

>  >
>  > (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
>  >
> 
> Same argument as above for the traffic class octet.
> 
>  >
>  > 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
>  >
> 
> 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.
> 

Sorry, the Window, here, should be referred as the initial value (or
maximum value) of RWND. Since sharable packet streams are likely to have
the same initial RWND, it would optimize the SYN packet size for
short-lived  TCP traffics.

>  >
>  > (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.
> 
> 
> 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
>  >     Sequence Number will be impossible to share at all.
>  >
> 
> 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...
> 
>  > ECN Flags
>  >
>  > Field                   Class           Sharable
>  > ------------------------------------------------
>  > ECT                     CHANGING        Yes
>  > CE                      CHANGING        No
>  > ECN                     CHANGING        No
>  > CWR                     CHANGING        No
>  >
> 
> 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.

Agree!

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

Yeah, that is why (initial) Window is regarded as sharable.

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

Yeah. However, the duration between two sharable packet streams is large
enough, there will be no gain for sharing timestamp.

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

In fact, IMHO, such an issue should be considered as an implementation
issue. We can only provide guidelines on it. For simplicity, packet
streams with the same Source-IP should be considered as sharable packet
streams, and only the most recent one should be used the candidate to be
shared.

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

IMHO, context sharing is only used to alleviate the cost of new context
establishment. Only context update (or Partial Header) packet is more
efficient than Full Header packet, it wins. We can use another specific
profile for Partial Header packet to minimize the overhead and
complexity.

>  > 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.
>  >
> 
> 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)
> 

Agree.

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

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

---

From: Julije Ozegovic <[email-masked]>
Date: Wed, 06 Mar 2002 12:19:09 +0100

Hi all!

it seem to me that context sharing could be more beneficial if 
approached from the "protocol layering" side (as opposed to the 
current "protocol aggregation" approach).

IP context can be used for all connections between two hosts, 
and separate TCP or UDP contexts for each connection. Than, 
common UDP context can be shared for multiple RTP flows, etc.

It is possible that separate TCP context, between two hosts, can 
act better in the case of short TCP connections too.

This approach assumes separate profiles for protocols, and 
"distributed" contexts.

Has anybody analyze whether layering approach can gain better 
compression/computation ratio?

Best regards,
Julije Ozegovic

---

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

Hi all,

A couple of brief comments...

Cheers,

Mark.

Julije Ozegovic wrote:

> approached from the "protocol layering" side (as opposed to the current 
> "protocol aggregation" approach).

I don't think that we have really explored the relative benefits. 
However, I have certainly approached this in the past from a 'protocol 
layering' point of view.  I'm interested to think about what is the best 
approach.

> 
> IP context can be used for all connections between two hosts, and 
> separate TCP or UDP contexts for each connection. Than, common UDP 
> context can be shared for multiple RTP flows, etc.
> 

I think that the idea of sharing IP contexts between 2 hosts is clearly 
beneficial.  We also have to consider Hongbin's proposal to think about 
finer granularity sharing.

I think that RTP/UDP flows have a 1:1 mapping, so I don't believe that 
it is useful to share UDP contexts for RTP flows.

> It is possible that separate TCP context, between two hosts, can act 
> better in the case of short TCP connections too.
> 

Well, I think that (certainly at the level of whole headers) TCP headers 
will have separate contexts.  This is more a case of necessity than 
efficiency, I think.

However, the possibility of initialising a new TCP context by basing it 
on an existing one may aid efficiency.  (For example, port numbers may 
be common [or similar] -- Hongbin gives other examples).

> This approach assumes separate profiles for protocols, and "distributed" 
> contexts.
> 

No, I don't think that this does necessarily assume separate profiles 
for the protocol components.  I can post an example profile to show how 
this would work...

I'm not sure what you mean by a distributed context.

> compression/computation ratio?

We haven't analysed it.  But we think that it's a good idea and we're 
obviously interested in pursuing it.

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