Subject: [rohc] Summary: draft-saifullah-rohc-tcp-early-comp*-00.txt

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Fri, 8 Nov 2002 12:56:40 +0100

ROHC-TCPers,

I have now read the "draft-saifullah-rohc-tcp-early-comp*-00.txt"
drafts, the various postings by Yousuf, Richard, Ghyslain and
Qian, and discussed this issue with Carsten. This mail is intended
to try to summarize the issue and our findings. Initially, I would
like to say that I think the mail list discussions got unnecessary
non-constructive and unclear, and several parties contributed to
that. Maybe some responses just went out too quickly, as often.

* What the drafts are about:

First of all, we can conclude that these drafts introduces an idea
of pre-populating context information to the decompressor, prior
to the reception of any packets. The pre-populated information
(in practice one IP address) could then be referred to when
creating a context, reducing overhead from the initial IR packets.
To do this, out-of-band mechanisms are needed in the actual link
technology to carry out the actual pre-population of data, and
in-band functions must be provided by the compression protocol so
that the pre-populated information can be referred to in context
initiation. The drafts identifies these components and provides an
example to explain what makes this possible to do in GPRS.

Although the general idea is rather simple, it should be noted that
its applicability is limited to some special environments and
certain circumstances. In general, it is not possible to know any
header information before the first packet arrives, but it can be
possible in some cases where compression is carried out over the
very last hop, to one single end host with one IP address. 

* What is relevant for ROHC:

As mentioned above, the proposed functionality requires out-of-band
mechanisms to pre-populate context information and in-band header
compression mechanisms that can refer to the pre-populated data
when initializing a context. How the former is provided is
obviously out of scope for the ROHC work, while the latter is
dependent on internal ROHC protocol mechanisms. This does not
necessary mean that new specific mechanisms are needed explicitly
for this purpose, but existing mechanisms might also be re-used.

The only part of this that is of relevance for the ROHC WG is thus
how to consider how the latter mechanism can in some way provided
by the compression mechanisms, assuming it is decided to be
worth the potential effort. There seems to be no disagreement
that this is the only issue related to the proposal that is
relevant for the WG to consider, and also that this should in practice be a rather minor issue to resolve.

* TCP Context Replication:

Context replication is a mechanism that we have agreed to define
for ROHC TCP to improve compression of short-lived TCP transfers,
i.e. cases when several consecutive TCP connections appear that
have the same sender and/or recipient. If a previous context has
reusable header information, that data can be re-used when a new
context is established. Context replication is an ordinary in-band
header compression mechanism, the new thing is just that an IR 
packet can refer to an old context for some initialization information.

As Richard and Qian have pointed out, we have not yet defined the
inner workings of the context replication mechanism, but we have
settled the general principles, which of course must be done before
addressing the details. One thing that we have agreed on is that
the IR-REPLICATE would just be a variant of the regular IR packet
for ROHC TCP, i.e. we can and will avoid an additional packet type.

* How the proposed functionality relates to Context Replication:

When comparing Context replication and the proposed pre-population
functionality, significant differences can be observed. Context
replication is an in-band function, totally integrated in the
compression scheme itself, while pre-population of context
information requires out-of-band mechanisms. Context replication is
based on the general observation that if a previous context has
similarities to a new one to be established, the existing
information can be re-used. To use out-of-band pre-populated
information when establishing a context is on the other hand a 
principle assuming knowledge that in general can not be known,
and is therefore only applicable under constrained circumstances.

However, even if there are significant differences in principle,
there are important commonalities in that both can establish some
of the information in new contexts based on data already available
at the decompressor. Both require a slightly modified IR packet
that can exclude some fields and instead refer to the data already
available at the decompressor. For context replication, another
context is referred to, while pre-populated context information
might be referred to in various ways. If the same method as for
context replication could be used, one single generic mechanism
would be able to serve both purposes. ROHC-TCP would then have only
its own context replication mechanism, but that mechanism could be
utilized to support context establishment based on pre-populated
information, in environments where such out-of-band mechanisms are
applicable and available. As suggested by both Qian and Ghyslain,
support for the proposed functionality would then be an issue 
covered by the context replication work we are already doing.

* How to go forward with this work:

Let us go on with ROHC TCP and define the inner workings of the
context replication mechanism, and when we do that work we should
consider how the context replication mechanism can be reused by a
link specific implementation for the purpose of initiate a context
based on pre-populated context information. This way, we will
address this from a ROHC point of view, i.e. not make specific
assumptions about any environment, but instead try to provide the
means to implement such mechanisms where that is appropriate.

Regards,
/L-E

--------------------------------------
Lars-Erik Jonsson
IETF ROHC WG Chair
E-mail: [email-masked]
Phone: +46 920 20 21 07
Home: +46 920 999 57

My opinions are my personal opinions and should not be considered
as the opinions of my employer, if not explicitly stated. 
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Price, Richard" <[email-masked]>
Date: Fri, 8 Nov 2002 15:15:33 -0000

> means to implement such mechanisms where that is appropriate.

Hi,

The above proposal looks like an excellent way forwards on this
issue. Once we've investigated how to provide the context replication
mechanism in more detail the modifications needed to also support
outband context establishment should become clear. The WG can then
decide whether to include the necessary modifications as part of
the TCP/IP profile.

Regards,

Richard

---

From: [email-masked]
Date: Fri, 8 Nov 2002 15:16:25 -0600

Hi,
Thank you for summarizing the discussion.  There are some important points which were not present in the summary, so I have included them; please see my comments below. Also, thank you for considering early compression (or pre-populated) in the way forward for ROHC TCP work. We have couple of requests for proper and efficient consideration of the proposed work. Please find them also at the end and inform us with your feedback.

Regards,
---
Yousuf

-----Original Message-----
From: ext Lars-Erik Jonsson (EAB)
[mailto:[email-masked]]
Sent: 08 November, 2002 5:57 AM
To: [email-masked]'
Subject: [rohc] Summary: draft-saifullah-rohc-tcp-early-comp*-00.txt

ROHC-TCPers,

[Yousuf] I would like to clarify that the early compression draft is not limited to "where compression is carried out over the very last hop, to one single end host with one IP address". I think this statement is overly narrowing the application of early compression. I have given the example of GPRS and have shown IP address and also IP version. In GPRS, there is another parameter called Traffic Flow Template which is basically a packet filter and is present at the decompressor side, and could contain one or more of the following paramaters.
·	Destination Address
·	Protocol number (IPv4) or Next Header (IPv6)
·	IPSec Security Parameter Index
·	Type of Service (IPv4) or Traffic Class (IPv6)
·	Flow Label (IPv6)
I didn't mention TFT in the GPRS draft for brevity. But, we can see that TFT offers much more than "one IP address".
I have also given example of RSVP. It could be used to setup a tunnel, which is not necessarily "the very last hop". The
RSVP signaling contains the following header fields, which can again be used for early compression purposes:
·	Source and destination address
·	Source and destination port
·	Flow Label (IPv6)
·	Protocol ID
These two examples should be enough to remove the above stated limitations.

[Yousuf] The following are some additional important differences, these were also shared in the email discussion:
- context replication requires a previous TCP connection. Early Compression Enabler can start compressing from the very first packet without any previous TCP connection. It doesn't require any ROHC-TCP base context
- context replication requires base context in B-mode and in FO/SO state, Early Compression Enabler doesn't have this limitation.
- context replication requires storage of a base context. Early compression Enabler doesn't mandate such storage.

[Yousuf] In the first sentence it is implied that early compression is a link specific implementation. This is not correct, please refer to the RSVP example in the emails. 
To assure that the Early Compression work will be considered in the next version of the ROHC-TCP draft, we have the following two requests: 
1) we will participate in the work of defining the context replication/early compression. This would save time and effort, in contrast to first developing context replication mechanism and later trying to fit early compression on it. Also, considering that the context replication protocol development is still in its preliminary stage, this request is fairly easy to accomodate. 
2) the name of the work should be changed to something like "context replication & early compression" to reflect our idea. This is because the term "context replication" implies a specific method, i.e. an inband method which uses a base context. Now we are adding another method which does not replicate any base context and is not limited to inband methods. 

Regards,
/L-E

---

From: "Qian Zhang (MSR)" <[email-masked]>
Date: Mon, 11 Nov 2002 11:10:08 +0800

We also agree that we should now go with ROHC-TCP and consider this
pre-populated context information when provide detail information in
context replication scheme. 

Regards,
Qian

-----Original Message-----
From: Price, Richard [mailto:[email-masked]] 
Sent: Friday, November 08, 2002 11:16 PM
To: 'Lars-Erik Jonsson (EAB)'; [email-masked]'
Subject: RE: [rohc] Summary: draft-saifullah-rohc-tcp-early-comp*-00.txt

Hi,

Regards,

Richard

---

From: [email-masked]
Date: Mon, 11 Nov 2002 08:32:37 -0600

Hi Lars-Erik, Qian, Ghyslain, Richard, and others,

Please consicder that postponing early compression after defining the inner workings of context replication is only going to slow down the ROHC-TCP  work unnecessarily. We know that we have to define ROHC-TCP for context replication and early compression, we also agree that the modifications will be very similiar if not same, then considering them simultaneously is a better approach. What do you think?

Cheers,
Yousuf

-----Original Message-----
From: ext Lars-Erik Jonsson (EAB)
[mailto:[email-masked]]
Sent: 11 November, 2002 2:10 AM
To: Saifullah Yousuf (NRC/Dallas)
Subject: RE: [rohc] Summary: draft-saifullah-rohc-tcp-early-comp*-00.txt

Yousuf,

We have a strong rough consensus on the list for how to go further
with this work, i.e. to continue with ROHC-TCP, define the inner
workings of context replication, and then consider how out-of-band
mechanisms can re-use (potentially with some adjustments) the
in-band context replication mechanism for referring pre-populated 
context data.

This is the way that has been envisioned and supported by Qian,
Ghyslain and Richard, and is also what me and Carsten think is
the proper way. We will address this issue, but not before we have
settled the details of the context replication mechanism. 

BR
/L-E

---

From: "Price, Richard" <[email-masked]>
Date: Mon, 11 Nov 2002 16:19:44 -0000

Hi Yousuf,

I believe that the best way of introducing early compression into the
TCP/IP work is as an enhancement to the context replication mechanism
that we've previously agreed to standardise. Once the inner workings
of context replication have been defined it should be clear that more
general early compression techniques can be supported with only a
small amount of additional effort (perhaps a minor change to the
IR-REPLICATE packet formats).

Regards,

Richard

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, November 11, 2002 2:33 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; Price,
> Richard; [email-masked]
> Subject: RE: [rohc] Summary: 
> draft-saifullah-rohc-tcp-early-comp*-00.txt
> 
> 
> Please consicder that postponing early compression after 
> defining the inner workings of context replication is only 
> going to slow down the ROHC-TCP  work unnecessarily. We know 
> that we have to define ROHC-TCP for context replication and 
> early compression, we also agree that the modifications will 
> be very similiar if not same, then considering them 
> simultaneously is a better approach. What do you think?
> 
> Cheers,
> Yousuf
>  
> 
> Subject: RE: [rohc] Summary: 
> draft-saifullah-rohc-tcp-early-comp*-00.txt
> 
> 
> Yousuf,
>

---

From: [email-masked]
Date: Mon, 11 Nov 2002 15:50:18 -0600

Hi,
My last email lack any technical argument for simultaneous consideration of early compression with context replication, allow me to provide some this time:

- Let's assume that the context replication uses the profile specific bit in  packet type to indicate context replication. Now how are we going to introduce early compression. Either we add a new field in the header OR change the definition done for context replication.  
- Context replication requires sending of an identifier to locate the base context. This is not needed for early compression. Later, we need to make it optional. And also devise a method to indicate this as an optional field.
- Context replication does not offer some mechanism, like fall back to regular TCP/IP compression. Later, either it will be introduced for context replication OR make an exemption for not having fall back for early compression. 

If A1 is a subset of A and we define A1 first and later try to extend it to define A, we gonna do lot of change of definition. It is better to define A first and later enhance it to define any subset case. By "A", I mean Early Compression Enabler, and by "A1" I mean context replication. For Early Compression (out of band) mechanisms, A2, A3, etc. we don't need to define anything in ROHC. 

If the concern is that there is not enough thinking done for early compression and it would hamper the context replication standardization, then that can be easily judged by the contents of the draft.    

Cheers,
Yousuf

-----Original Message-----
From: ext Price, Richard [mailto:[email-masked]]
Sent: 11 November, 2002 10:20 AM
To: Saifullah Yousuf (NRC/Dallas); [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: RE: [rohc] Summary: draft-saifullah-rohc-tcp-early-comp*-00.txt

Hi Yousuf,

Regards,

Richard

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Tue, 12 Nov 2002 13:31:40 +0100

Dear ROHC-TCPers,

Thanks to Ghyslain for further clarifying the reasoning behind the
approach supported by most parties, which I previously summarized.
This is in line with what I feel is the rough consensus of the group.

As various parties did express a belief that D) should be possible
to do, which sounds reasonable, it is a natural way of addressing
this issue. That would result in one single in-band mechanism,
generally defined for in-band usage, but re-usable by external
mechanisms. It would be up to externals to define such out-of-band mechanisms, based on what is available from the ROHC-TCP protocol,
instead of us having to define an additional internal ROHC-TCP
mechanism to serve an out-of-band purpose. 

Cheers,
/L-E

> B) The WG will first define context replication;
> C) Context replication is an in-band mechanism that creates a
>    context based on another valid context;
> D) Once Context Replication is defined, the WG will consider how
>    out-of-band mechanisms can re-use the in-band context
>    replication mechanism for referring pre-populated context data.
> 
> Please note the difference in the approach between D) and the
> proposal found in the draft, as in A). My understanding is that
> the WG believes that the same objectives as A) should be possible
> to achieve by reusing context replication and follow the
> principles of D).
> 
> I personnally believe that the correct approach is to go with 
> B), C) and D). This will likely generate a single solution that
> is defined purely as an internal ROHC-TCP mechanism, while still
> allowing out-of-band mechanisms the possibility to reuse the
> context replication function. This is basically what I have
> written in previous mails [M1], and that was emphasized again
> by Qian [M2].

---

From: [email-masked]
Date: Tue, 12 Nov 2002 09:54:20 -0600

Hi Ghyslain,

Before going on, let's use the following terminology (good engineering
starts with clear terminology): 

- "Context prepopulation": that are what the "early" drafts about. I
agree with the first point in Lars-Erik's email [M3].

- "Context replication": is to reuse ("base") context already established
previously by ROHC-TCP. Currently described in tcp-03.

(I also like the terminology in email from Qian and Hongbin: "intra-protocol 
replication" and "inter-protocol replication". But I think "prepopulation"
captures our idea better.)

I do agree that we can design a single mechanism (logic and packet format) 
in rohc-tcp profile that can server both context replication and prepopulation
(can we use this terminology in tcp-04?). As discussions point out, there
are commonality between them.

What I disagree is the two-step approach: first define the mechanism only
for context replication, and then modify/extend it for context pre-population.
I don't see a particular reason for that, unless you think a single 
mechanism is not possible (I see many "ifs" in your summary).

As a result of this discussion, we already understand and agree on the 
concepts. Yousuf even discussed a few detailed issue on the packet
format. So, why not just go ahead and work out the mechanism supporting
both context replication & prepopulation in tcp-04?

(In practice, we have more resources here working on rohc-tcp. Why not 
utilize them? I understand one reason for slow progress on rohc-tcp
was lack of resources.)

BR,
Zhigang

> From: ext Ghyslain Pelletier 
> [mailto:[email-masked]]
> Sent: November 12, 2002 4:52 AM
> To: Liu Zhigang.C (NRC/Dallas); Saifullah Yousuf (NRC/Dallas)
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [rohc] Summary: 
> Zhigang, Yousuf,
> I think it is important at this point to keep in mind the differences
> between agreeing on "general principles to follow" and discussing
> "specific solutions". 
> 
> Once more, to ensure that there is no misunderstanding, the "Early
> Compression" drafts are basically proposing to consider the following
> principle:
> 
> A) Defining a ROHC-TCP profile that can reuse information
>   ("Early Fields") that has been previously exchanged out-of-band
>   ("Early Compression Mechanism") by providing a mechanism that
>   carries in-band ("Early Compression Enabler") a reference
>   ("Option Specific Information") to this external information.
> 
> My understanding of the WG rough consensus is basically that the
> following approach has been chosen and agreed:
> 
> C) Context replication is an in-band mechanism that creates a context
>    based on another valid context;
>    out-of-band mechanisms can re-use the in-band context replication
>    mechanism for referring pre-populated context data.
> 
> Please note the difference in the approach between D) and the proposal
> found in the draft, as in A). My understanding is that the WG believes
> that the same objectives as A) should be possible to achieve 
> by reusing
> context replication and follow the principles of D).
> 
> B), C) and
> D). This will likely generate a single solution that is defined purely
> as an internal ROHC-TCP mechanism, while still allowing out-of-band
> mechanisms the possibility to reuse the context replication function.
> This is basically what I have written in previous mails [M1], and that
> was emphasized again by Qian [M2].
> 
> Finally, let me summarize once more my understanding of the WG's rough
> consensus, from Lars-Erik summary [M3]:
> 
> - The WG will proceed, at least in a first step, with only the
>   definition of the context replication mechanism as in C);
> 
> - Once the context replication is defined and agreed by the WG,
>   if the resulting mechanism does not make it possible fullfil D), and
>   if this can be done with only small and justified modifications
>   to the context replication mechanism, then the group may decide
>   to proceed with those modifications.
> 
> In this respect, the WG is not "postponing" any work, but rather going
> with the approach as stated in D), and that the fullfilment of the
> objectives of A) should not entail more than a rather small 
> extension of
> the principles behind context replication. I believe 
> proceeding in this
> order will help streamline the work, and this way will 
> effectively speed
> up the ROHC-TCP work.
> 
> Hopefully, this clarifies the various positions expressed during this
> discussion, which lead to the way forward as summarized by 
> Lars-Erik in
> [M3].
> 
> Best regards,
> 
> /Ghyslain
> 
> References:
> -----------
> [M1]:
> http://www1.ietf.org/mail-archive/working-groups/rohc/current/
> msg00983.html
> [M2]:
> http://www1.ietf.org/mail-archive/working-groups/rohc/current/
> msg01003.html
> [M3]:
> http://www1.ietf.org/mail-archive/working-groups/rohc/current/
> msg01013.html
> 
> Ghyslain Pelletier
> Wireless IP Optimizations
> AWARE - Advanced Wireless Algorithm Research
> Ericsson Research, Corporate Unit
> Ericsson AB
> Luleå, Sweden
> 
> 
> [email-masked] wrote:
> > 
> > Hi,
> > 
> > I agree with Yousuf it would be better if we work on context
> > replication and early compression simultaneously. By simultaneously,
> > I don't mean running things in parallel. Instead, we work together
> > (especially on packet format) with considerations of both from
> > the beginning. That seems a reasonable engineering approach to speed
> > up the work.
> > 
> > I saw Yousuf already gave some technical arguments for the 
> "simultaneous"
> > approach in a separate email. Are there particular reasons that
> > make one believe the approach will slow down the work instead?
> > 
> > BR,
> > Zhigang
> > 
> > > From: ext [email-masked]
> > > [mailto:[email-masked]]
> > > Sent: November 11, 2002 8:33 AM
> > > To: [email-masked]
> > > [email-masked]; [email-masked]

---

From: [email-masked]
Date: Wed, 13 Nov 2002 09:47:20 -0600

Hello,

I have only seen believes and assertions to justify D, from the folks who are in favor of D. 

I have already shared technical and logical reasons for simultaneous consideration of "Context
Replication Mechanism" and "Context Pre-population Enabler" (Zhigang! I think we should have enabler in this term, to eliminate any confusion of specifying out-of-band mechanism).
http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01028.html
I didn't see any response in defiance to my reasons in the emails that followed on this thread. 

If the reason really is that the context replication was decided before context pre-population enabler in ROHC-TCP. If this is the reason, then it is not a good reason and also consider that context replication work has not progressed in terms of protocol specifications. 

Best Regards,
Yousuf

-----Original Message-----
From: ext Lars-Erik Jonsson (EAB)
[mailto:[email-masked]]
Sent: 12 November, 2002 6:32 AM
To: [email-masked]
Subject: RE: [rohc] Summary: draft-saifullah-rohc-tcp-early-comp*-00.txt

Dear ROHC-TCPers,

Cheers,
/L-E

---

From: [email-masked]
Date: Wed, 13 Nov 2002 11:19:16 -0600

Hi Ghyslain,
Your final summarization clearly identifies the problems with this two step approach. After publishing context replication, then the changes for the "Context Pre-population Enabler" has to be "small and justified modifications to the context replication mechanism". You have also clearly indicated that the "Context Prepopulation Enabler" should be a rather small extension of the principles behind context replication. You are imposing a requirement, which is not part of the ROHC-TCP requirements. Could you please justify from where you get this requirement?

I have already shared my concerns with this two step outward approach, i.e. defining a subset first and then extending it to a superset. I have shared the link to archive in my last email. I have mentioned and proved in my draft that "Context Pre-population Enabler" is more general and accomodates "Context Replication". I am afraid that if we take your two step outward approach, we will not pass any "small and justified modifications" test, since it is not defined anywhere :)

The context replication will be developed behind the doors and later shared on the mailing list. If the "Context Pre-population Enabler" fits into that with "small and justified modifications" it will be accepted otherwise toss it out, even though there is a consensus on the mailing list that context Pre-population or early compression enabler is a good idea. Could you tell me why?

This is what I am asking, and please give me your response on this question:
- We should develop context replication and  "Context Prepopulation Enabler" specifications together to save energy and time in rohc-tcp 04 timeframe. Instead of developing 04 only for context replication by excluding  Context Prepopulation Enabler, and later starting this whole effort of justification and incorporation for 05 document. 

Other then believes, does anyone have any good reason for the two step approach?

Cheers,
Yousuf

-----Original Message-----
From: ext Ghyslain Pelletier [mailto:[email-masked]]
Sent: 12 November, 2002 4:52 AM
To: Liu Zhigang.C (NRC/Dallas); Saifullah Yousuf (NRC/Dallas)
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [rohc] Summary: draft-saifullah-rohc-tcp-early-comp*-00.txt

...deleted...

In this respect, the WG is not "postponing" any work, but rather going
with the approach as stated in D), and that the fullfilment of the
objectives of A) should not entail more than a rather small extension of
the principles behind context replication. I believe proceeding in this
order will help streamline the work, and this way will effectively speed
up the ROHC-TCP work.

Hopefully, this clarifies the various positions expressed during this
discussion, which lead to the way forward as summarized by Lars-Erik in
[M3].

Best regards,

/Ghyslain

References:
-----------
[M1]:
http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg00983.html
[M2]:
http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01003.html
[M3]:
http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01013.html

Ghyslain Pelletier

[email-masked] wrote:
> I saw Yousuf already gave some technical arguments for the "simultaneous"