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

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Fri, 8 Mar 2002 15:06:19 +0100

Hi all,

Finally, I got time to get myself updated on this thread. I think
we mainly have agreements here, and that is very good. Some comments
to the discussion:

1) To me, "context sharing" and "context reuse" have been different
   names for the same thing, and maybe "context replication" is a
   better term. However, we all seem to agree on what we are talking
   about.

2) I agree with Mark that we should avoid building unnecessary
   complexity. Making good protocols is often about not being too
   inventive. In this case, it might probably be enough if we could
   replicate IP addresses, and maybe port numbers. The requirement
   to improve efficiency for short-lived TCP transfers should then 
   be met.
   
3) One important issue to resolve is how to reference field values
   from other contexts. Based on possible solutions for that, we
   can further discuss whether (and in such case how) this should
   work between different profiles.

4) I am not sure we should use different profiles when applying 
   context replication, that might be messy but I have to think
   more on that. 

Cheers,
/L-E

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

---

From: "West, Mark (ITN)" <[email-masked]>
Date: Sun, 10 Mar 2002 15:48:57 +0000

Hi Lars-Erik,

Welcome to the party!

A couple of small comments...

Cheers,

Mark.

 >    better term. However, we all seem to agree on what we are talking

Well, I'm not sure that they are names for the same thing!  (Unless, of
course, I've misunderstood what is meant by them ;-)

"Context sharing" means (essentially) sharing a field between a number
of contexts.  For example, I have many TCP flows between 2 machines,
each has a separate TCP context, but all share the same context entry
for the IP ID.

"Context replication" (to use my name for it!) is where I initialise a
new TCP/IP context from an existing one and overwrite some of the values 
to create the new context.  (This is how I might avoid sending all the 
address and port number information, for example)

There is a subtle but important difference between initialising one
context from another (and then allowing them to diverge) and having a
single value shared by a number of a context entries.

(To be clear, I tend to view "Context Re-use" as the standard
ROHC/header compression concept that a context can be re-initialised to
support a new flow.  The new flow need bear no relationship to the old
flow in this case).

 >    context replication, that might be messy but I have to think

I'm still very unclear on this one.  However, I think that a reasonable
decision might arise out of considering a simple, effective way to
handle context sharing/replication.  I don't think that we should be
aiming to support inter-profile sharing as a definite goal, but if it 
happens...
(Which, I think, is effectively in agreement with your point 3)

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

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Sun, 10 Mar 2002 21:46:23 +0100

>   In this case, it might probably be enough if we could
>    replicate IP addresses, and maybe port numbers.

Still catching up with the thread myself, but what about TCP options?
These are getting bulky and are likely to be very compressible in initial
packets with little effort.

Gruesse, Carsten

---

From: "West, Mark (ITN)" <[email-masked]>
Date: Sun, 10 Mar 2002 18:31:19 +0000

It struck me that a concrete example might help, here...

When I talk about context sharing, I am thinking about something that 
can actually already be done within EPIC-lite -- it's up to the profile 
writer to use it (if he/she wants to!)

If I have encoding methods for (say) IPv4 and TCP headers, then I could 
combine them with a 'CONTEXT' encoding, like this:

TCP-IPv4 = IPv4               ; the IP header context
            CONTEXT(TCP,4)     ; 4 sets of TCP context
            IRREGULAR(2,100%)  ; the index for the TCP context

In this simple example, one TCP-IPv4 context holds 4 copies of the TCP 
'part'.  So, a new TCP part can be set up without having to set-up the 
underlying IP part.  In this case, the last IRREGULAR encoding 
identifies *which* of the TCP parts is being used.

(Obviously you can 'share' any part of a header in any way that makes 
sense within the profile.  And this is at the discretion of the profile 
author.  If it doesn't make sense to do it, than don't!)

What's missing from this (and this is where the context replication 
comes in), is some way of being able to use some existing context data 
to initialise a new part.

At the very least we need to be able to copy a set of values (for 
example TCP destination port), but it may be useful to be able to copy 
and modify some values (for example TCP source port, where this is an 
ephemeral port and increments by a small amount).

I think that, in most cases, it should be possible to select a subset of 
the context values (which may not be protocol fields, but other values 
used in compression) which it is sensible to copy.

Hopefully this attempt to 'clarify' things hasn't confused you too much..?!

Cheers,

Mark.

---

From: "West, Mark (ITN)" <[email-masked]>
Date: Sun, 10 Mar 2002 22:08:43 +0000

I keep forgetting TCP options, but you are quite correct!  Lots of nice 
SYN packet negotiations could be dealt with this way, yes...

Cheers,

Mark.