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

From: "Qian Zhang" <[email-masked]>
Date: Fri, 8 Mar 2002 16:50:12 +0800

Hi all,

I would like to clarify some points related the discussion about the
context sharing issue on ROHC/TCP.

1. The main purpose for context sharing
As we all agreed, context sharing could be beneficial for short-lived
TCP transfers. It is used to decrease the system cost for the context
establishment. By sharing the context, especially the options in SYN
packet, it can reduce the SYN packet loss/error probability and speed up
the TCP connection establishment procedure.

2. The application scenario for context sharing
The context sharing mechanism can be used when source and destination of
all the TCP/IP flows are the same. Meanwhile, this mechanism can also be
when all the connections have the same Source-IP. In this case, multiple
users in the same cell may browse web from the same server. In all those
cases, the multiple connections can be occurred sequentially or
simultaneously.

3. The difference between "context sharing" and "context reusing"
I had raised this discussion a month before. Details can be found in
http://www.cdt.luth.se/rohc/msg03557.html.

The key message is that there are much more fields that are similar to
the ones in other context than the exactly fixed/static ones, thus using
"context reusing" can utilize this similarity and improve the
compression efficiency. Meanwhile, by using "context reusing" mechanism,
it can support finer granularity sharing in rather simple way (by
sending the context update (or Partial Header) packet as Hongbin
mentioned in previous email). 

Thus, I would like to clarify that we may need to make a clear
definition about "context sharing" and "context reusing".

4. The sharable fields
The sharable characteristic for each TCP/IP field had been analyzed in
detail in
https://www1.ietf.org/mail-archive/working-groups/rohc/current/msg00111.
html.

To make the context updating (finer granularity sharing) procedure
simple, we can set the sharable value of TCP sequence number and window
field as 'No'.

However, we need to maintain the initial window of the connection in the
context. 

5. Context updating
Besides IR packet, we can introduce a PARTIAL-IR packet format to
perform the context updating. For those fields with the sharable value
as 'NO', they have the same format with the IR packet, and for those
fields with the sharable value as 'Yes', we can apply different encoding
method for different field.

Please feel free to add your comments.

Qian

-----Original Message-----
From: West, Mark (ITN) [mailto:[email-masked]] 
Sent: Thursday, March 07, 2002 6:41 AM
To: Julije Ozegovic
Cc: Hongbin Liao (Intl Staffing); [email-masked]
Subject: Re: [rohc] context sharing issues on ROHC/TCP

Hi all,

A couple of brief comments...

Cheers,

Mark.

Julije Ozegovic wrote:

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

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.

> Has anybody analyze whether layering approach can gain better 
> 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.

-- 
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: "West, Mark (ITN)" <[email-masked]>
Date: Fri, 08 Mar 2002 11:54:10 +0000

Hi Qian,

Some comments inline...

Cheers,

Mark.

> the TCP connection establishment procedure.

Agreed.

> http://www.cdt.luth.se/rohc/msg03557.html.

This is a helpful distinction to point out.  Obviously it is useful if 
we can have clear terminology so we all know what we are talking about...

I think that "context sharing" is clear.  I understand what you mean by 
"context reuse", but I think that this might get confused with the idea 
of re-using a previously used context for a new flow.  What we are 
talking about here, if I understand it, is intitialising a new context 
from an existing one and overwriting certain entries with values from 
the (partial) IR packet?  Perhaps "context replication"?  [although it 
isn't strictly a direct copy]

> mentioned in previous email). 

ok

> definition about "context sharing" and "context reusing".

Agreed.

> method for different field.

Do you expect that the shareable value will be mutable per packet?  That 
is, are there going to be (say) some fields that are NEVER shared; some 
that are ALWAYS shared (perhaps); and some that MAY be shared (with a 
flag to indicate this)?

Also, when you talk about using different encodings, are you thinking 
about doing more than simply choosing whether or not to copy a context 
value from the source context?  I can see that there may be some 
benefits to doing this; but I can also see that this might add 
complexity to the intialisation process.
It's certainly something to think about, though...