Subject: [seamoby] RE: CT dead??

From: "Gary Kenward" <[email-masked]>
Date: Thu, 11 Oct 2001 11:51:12 -0400

Madjid:
 
  I think that you and always have always been working towards a similar
if slightly different goal (differences are good). It frightens me that 
anyone would consider me an authority and in any way representing the 
opinions of Seamoby, if for no other reason then I have no idea what is 
going on. 
 
  If I am an impediment to CT progressing, then I will fall on my own sword,
and then hopefully the work can move forward.
 
  'nuff said. Indeed, more then enough said. Where is my claymore....
 
Gary

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: October 11, 2001 11:15
To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1;
[email-masked]
Subject: CT dead??

Gary,
 
I did appologize for not changing the subject.
I guess we both were victims of the electronic media.

As you rightly mentioned in your email to Rohc, the future of
CT heavily depends on detail feature (such as Rohc) work and 
 I do feel that such email coming from you as an 
authority in CT, would block any possibility for others
trying to collaborate with groups like Rohc,....

You know that celebrities live a life watched by many others :)

Just one thing, the list has been very quiet not for 10 months, but since
London and
that because people were waiting for the requirements, and maybe so many
other
 things that are going on in the industry now....
 
Now, if IESG has problems with the documents, I am interested to 
hear what these problems are.

Madjid

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Thursday, October 11, 2001 9:48 AM
To: 'Nakhjiri Madjid-MNAKHJI1'; [email-masked]
Subject: RE: [seamoby] FW: look at CT design team leader's email

First of all, the design team was disbanded many months ago, 
and I am not the leader of anything within Seamoby or the IETF. 

Second, I did make the classic brain-dead mistake of replying 
to your friend without checking the address list. I did not expect 
these comments to be posted on the list, nor, naively, to be forwarded. 
Even so, the language I used was too strong, even though it does 
capture what I basically feel about the state of ct. 

It's been 10 months, and the problem statement hasn't even 
reached the IESG. The requirements are up for last call, but 
no new work has commenced. The wg agenda is behind schedule, 
and items which I believe are necessary for the work to continue 
(and for which I believe there is at least moderate support - c.f. 
the IETF 51 minutes) have not been incorporated into the Seamoby 
charter. Items such as the requirement drafts for specific feature 
context, a framework draft, and the link layer events draft, have 
not been given homes. Please do not take any of the above observations 
as a criticism of Pat Calhoun or Allison Mankin. I believe the 
problems are partly circumstantial and partly due to our inability 
to progress in a clear and decisive manner. All of this may perhaps 
be the consequence of the complexity and ambiguity of the CT problem 
space. 

It's been 10 months, and the list is notably quiet. Perhaps Seamoby CT 
is not dead, but it certainly is comatose. Should it be killed? 
Well, if it takes 10 months to get the next wg draft out, then 
euthanasia may be the best option. 

Since you were so kind to cross-post this email, I am compelled to 
attach my clarification to the ROHC email list that I posted last 
night. 

Finally, please note that the group I work with has not stopped working 
on context transfer, micro-mobility and seamless mobility in general. As 
I stated in my response to Lars-Erik, I will revise the ROHC document if 
the problem statements and requirements drafts pass the IESG. 

Gary Kenward 

-----Original Message----- 
> From: Kenward, Gary [WDLN2:AN10:EXCH] 
> Sent: October 10, 2001 19:05 
> To: ROHC (E-mail) 
> Subject: FW: [rohc] ROHC context transfer 
> 
> 
> I need to clarify a few points about the email I X-posted accidentally to
the ROHC list. 
> I made the classic brain-dead mistake of not checking all the addresses in
the reply-field. 
> When I wrote this response I believed I was responding to Lars-Erik only. 
>  
> I want to make it clear that Dr. Bormann's was of great assistance to me
at IETF 51, and I appreciated 
> his help given the IETF was over, and he clearly had other appointments to
meet. When 
> I said in the email that "almost all of his comments were a matter of
miss-interpreting my text", 
> in most cases it was a result of my poor writing skills, and my attempts
to summarize a fairly 
> complex protocol. I still believe that this id should only try to
summarize ROHC and not 
> explain it, but clearly I need better words. Carsten helped me craft some
of those words, and 
> they sit on my computer, waiting for the next revision. 
> 
> Finally, concerning my frank comments concerning the life signs of context
transfer - well, 
> I might have said it differently on a wg list, but it's been 10 months and
there is still no 
> problem statement RFC. Some of us believed that we would have wg protocol
drafts out for 
> comments by now. Perhaps the idea simply isn't viable. Many of those
initially involved 
> are, I believe, moving on to other areas, or other venues. 
>  
> Of course, this is only my opinion, and I'm sure the wg chairs have
different views of 
> where this is all headed. The last call was made on the ct requirements
draft, and sometimes 
> work progresses in marked fits and starts. 
>  
> Regards, 
> Gary Kenward 

 -----Original Message----- 
From: Nakhjiri Madjid-MNAKHJI1 [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: October 10, 2001 19:15 
To: [email-masked] 
Subject: [seamoby] FW: look at CT design team leader's email 

Gary, 
  
A ROHC fellow  forwarded me this email. 
Would you care to explain why you think CT is dead? 
(or maybe it should be dead? ) 
  
We have been patiently waited for completion of the requirements!! 
  
Have a good day, 
Madjid 

 -----Original Message----- 
From: Gary Kenward [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Tuesday, October 09, 2001 11:26 AM 
To: 'Lars-Erik Jonsson (EPL)'; 'ROHC' 
Subject: RE: [rohc] ROHC context transfer 

Lars-Erik: 
  A number of attempts were made to engage people more familiar with 
ROHC in the Seamoby discussion. Indeed, CT suffers from a lack of
involvement 
of knowledgeable people in a number of areas. This is a fatal weakness in my

view, as the critical requirements for making CT work is the requirements
set 
by the feature itself, not on abstract protocol requirements. I have made
this 
point many times on the CT list, to no avail. 
  It matters not, perhaps, for as far as I can see, CT is dead. There is
next 
to no activity on this issue in Seamoby, and the problem statement lacks
approval, 
even though it was completed many months ago. We shall see, but I do not
intend 
to revise the ROHC CT document until the two outstanding WG I-Ds are sent to
the 
IESG. 
  I did sit down with Carson Bormann at IETF 51. He expressed similar
concerns 
as you, and we walked through my draft. Frankly, almost all of his comments
were 
a matter of mis-interpreting my text, and the changes requested were mostly
to 
make my draft more explanatory. I will do so, but frankly, this draft is not

meant to be a normative reference for ROHC. 
  As for the link layer dependencies: I find it curious that the IETF would
develop 
a protocol that is link layer dependent, don't you? 
  More comments below. 
  
  Thank you for your input. I will take it into account, if I revise the
I-D. 
Cheers, 
Gary 
> -----Original Message----- 
> From: Lars-Erik Jonsson (EPL) 
> [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: October 9, 2001 10:32 
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'ROHC' 
> Subject: RE: [rohc] ROHC context transfer 
> 
> 
> Hi Gary and others, 
>  
> I know that some people believe in context transfer, e.g. for 
> header compression, and I can not judge whether this might be 
> useful or not. Personally, I am skeptical to the whole idea 
> but I accept that others have a different opinion and I may 
> be convinced about the usefulness of header compression 
> context transfer for certain specific environments. However, 
> I strongly believe that at least for header compression, 
> context transfer is a link-technology dependent issue, and 
> would be implemented based on where/how header compression is 
> implemented in that specific link technology. 
>  
> Even if I really do not care about context transfer, I do 
> care about ROHC and that this work is not justified by, or 
> carried out based on, incorrect understandings of ROHC. 
> Previous discussions about this (in ROHC, SEAMOBY and 
> MOBILEIP) has shown a significant lack of ROHC knowledge from 
> those proposing context transfer (for ROHC!). Most 
> surprising, when ROHC authors have pointed out incorrect 
> statements about ROHC operation, this has even been 
> questioned by the context transfer proponents. This draft 
> (draft-kenward-seamoby-ct-rohc-reqs-00.txt) refers to 
> previous drafts that have made several incorrect statements 
> about ROHC. However, this time I will concentrate on the 
> draft "Context Transfer Considerations for ROHC". With ROHC, 
> I refer either to the ROHC WG or to RFC-3095. 
>  
> See comments below... 
>  
> Cheers, 
> /Lars-Erik 
>  
>  
> >>> Section 3 - Overview ROHC Context 
> 
> > ... 
> > The decompressor monitors the success of decompression of 
> > the IP packets, and acknowledges successful decompression 
> > to the compressor. The compressor attempts to compress the 
> > IP packets as much as possible, as long as the transmitted 
> > packets are acknowledged. 
>   
> LEJ: ROHC may operate in 3 different modes, U-, O-, 
> or R-mode. Operation always start in U-mode and transition 
> to O- or R-mode may later be carried out through feedback 
> from the decompressor. The above text is correct only for 
> ROHC R-mode operation. 
A matter of interpretation: in my view, U- and O- modes can be 
considered "fallback" modes for R-mode. In other words, R-mode 
is the preferred mode of operation, providing the most compression. 
U- and O- modes are provided to accomodate the unreliable nature 
of the channel. Thus, ROHC attempts to compress as well as it can 
(R-mode), but sometimes cannot (O-, U- modes). 
>   
> > ... 
> > What makes ROHC robust is the intrinsic bias of the state 
> > machines to return to a basic mode of operation where no 
> > compression is performed. 
>   
> LEJ: Here the conceptually orthogonal terms state and 
> mode are mixed. The correct wording here should be state 
> only. However, what makes ROHC robust, compared to earlier 
> compression schemes, is obviously not the descriptive state 
> machine concept. 
I would counter that this is semantics. Defining multiple "modes" 
in the end results in the same outcome: multiple states in an 
implementation. I will use the wording preferred by the ROHC wg, 
but personally, I see it as conotational slight of hand. 
> 
> > ... 
> > Simply because of the robust definition of ROHC, it is 
> > possible to handover the uncompressed packet stream from 
> > the SAR to the RAR without the integrity of the IP sessions 
> > being compromised. ROCH defines an uncompressed, or 
> > no-compression profile with an identifier value of 0x0000. 
> > Because of the semantics of the CID encoding, a regular, 
> > uncompressed IP packet, is interpreted as having a profile 
> > of 0x0000. 
> 
> LEJ: The no-compression profile is not about what this text 
> indicates. The no-compression profile is used for streams 
> that can not be compressed with the profiles supported by 
> a compressor and decompressor pair, to be used over links 
> where only ROHC packets can be transmitted (not e.g. PPP). 
> This is thus not the no-context-transfer alternative. The 
> alternative to context transfer is simply to restart header 
> compression in IR-state, as a new packet stream for the new 
> link. 
I understand the intent of the 0x0000 profile defined by ROHC. 
However (and I explicitly posted this question to the wg email 
list), if ROHC is to be robust for handovers, then using 0x0000 
as a fallback profile would not only be useful, it is a requirement. 
There is no way to gaurantee quasi-static context transfers for ROHC, 
thus a fall back mode is required. 
My perspective on this is to apply ROHC as a feature for packet
communications. 
It is also possible to treat ROHC as a circuit switched feature (i.e. put it

at the link layer), but, IMHO, this does not promote efficient packet
switching. 
> 
> > ... 
> > The cons for this approach include: 
> > 
> > - the RAR may not be able to re-establish compression for 
> >   traffic destined for the MN. The RAR would have no 
> >   direct method of determining that the stream was to be 
> >   compressed. 
> 
> LEJ: It would of course have to use the same method as any 
> node uses to determine if/how header compression can be 
> applied to new packet streams. 
If I understand you, the usual method involves signalling to/from 
the MN. This is always an option, but not an appealing one, as it 
does not seem conducive to a "seamless handover". Even if it were, 
it would consume precious bandwidth over the air. 
Handovers can be very serendipious, specially in pico cell environments 
in urban or indoor areas. Even one over the air message can be a 
significant overhead if there is lots of handovers occuring. 
One of the goals of Seamoby was to accomplish a handover with (ideally) 
no over the air signalling. I put it to you: how do you suggest one 
do this with ROHC? 
> 
> > ... 
> >>> Section 4.2 - Header Compression Profile Transfer 
> 
> LEJ: The heading itself indicates that something is not 
> correct here. A profile is nothing that can be subject to 
> transfer. A profile defines how a specific kind of packet 
> streams are compressed, i.e. basically the actual 
> compression protocol (in ROHC consistent with the framework). 
> Should it be "Context Transfer"? 
There are two issues here: a) do the CT source and destination 
share the same "profiles", if the answer is yes (hopefully), then 
a "profile transfer" would simply be a transfer of the profile id. 
If the answer is "no", then yes, it is argueable that there is nothing 
to transfer. I wanted to leave open the possibility of a "building block" 
approach to specifying profiles that might allow the receiver to 
"build" profile support. It's a complication that is, I agree, very 
difficult to realize, and therefore unlikely. 
> 
> > ... 
> > One issue with this approach is the reliance on the RAR 
> > having the same header compression profile. The IR packet 
> > conveys the profile ID and not the profile, and the RAR 
> > must match the received profile ID with one of the 
> > profiles in its local repository. 
> 
> LEJ: Once again, what is meant with "the profile"?. The 
> profile ID determines the profile, which is a compression 
> protocol, not a state. Also here, should it say "context"? 
To summarize, the context here is at least the profile id. 
It is likely nothing more. 
I should note, as I alluded to above, that CT can only be shown 
to work, IMHO, if we develope specific requirements and make 
some decisions on what to support and what not to. Unfortunately, 
the requirements for Seamoby span everything from cellular systems 
to 802.11, Bluetooth, and ad hoc networks. The latter two being 
completely unknown, and thus open to wild conjectures, like 
suppossed handovers between two dissimilar access routers. 
> 
> > ... 
> > Even if the RAR finds a matching ID, it is not clear that 
> > the profiles will match: e.g. for inter-technology 
> > handovers, say Bluetooth to 802.11, some of the link 
> > dependent aspects of the profile may change. 
> 
> LEJ: This just highlights the obvious fact that context 
> transfer for header compression is a link-issue. Two link 
> technologies might be supporting different profile sets, 
> or they might even be using different compression schemes 
> (not necessary ROHC). Further, inter-technology context 
> transfer would require inter-technology communication, or 
> higher layers to carry out the context transfer, which would 
> require higher layers to know about the lower layers. 
Well, no one can debate supposed link layer differences, certainly 
not in an IETF document. What you seem to be telling me is either that 
ROHC is a link layer protocol (which means it doesn't belong in the IETF) 
or that it relies heavily on link specific solutions, which means that is 
not an IP level solution (and doesn't belong in the IETF). 
As a side note: the intent is to define context transfer as a capability 
enabling protocol that might allow router manufacturers to transfer link 
layer state or whatever state they see fit. For many technologies, it will 
not be the appropriate solution. CT is fundamentally limited by being an IP 
layer soluton. 
> 
> > ... 
> >>> 4.3 - Static Compression Context Transfer 
> > ... 
> > The IR packet provides all the static context required 
> > to initiate the compressor and decompressor state machines. 
> > The first level of actual header compression for ROHC 
> > compresses the static and quasi- static fields. 
> 
> LEJ: The IR packet normally contains ALL header information, 
> both static and dynamic. I do not know what is meant with 
> quasi-static, only that it is not a term used by ROHC. 
It *at least* contains all the static context information, 
does it not? 
Quasi-static is a term I coined to apply to portions of the 
dynamic compression context. It applies to information that 
is dynamic, but changes slower then with every packet. 
It may be correct to simply send over all of the dynamic context, 
and let ROHC at the destination deal with the inconsistencies. 
I felt, and still do, that we could be smarter then this: 
i.e. build in a degree of robustness with ROHC that deals 
with handovers. However, this was presumptuous. 
> 
> > ... 
> >>> 4.4 - Dynamic Compression Context Transfer 
> > ... 
> > Dynamic compression context transfer will succeed for 
> > reactive context transfer only if the transfer can be 
> > completed between a packet arrival at the SAR and the 
> > first or second consecutive packet arrival at the RAR. 
> 
> LEJ: This is absolutely not true, ROHC is designed to be 
> robust against packet loss. It is true that there might be 
> problems like this with context transfer, if it is not 
> completed fast enough, but it is not true that ROHC can not 
> handle losses, as the above text indicates. 
You are looking at this from the perspective of ROHC. The issue 
is not whether ROHC can handle it, the issue is whether it is 
worth performing CT for dynamic state or not. If CT of dynamic 
context must rely upon ROHC robustness to recover, then it is not 
worth doing (reliance is, of course, a matter of frequency; clearly, 
if ROHC robustness is required to recover 90% of the time, then CT 
of dynamic ROHC context is not worth doing). 
Indeed, the proposal is to transfer only the static context, and 
let ROHC robustness do what it was designed to do. The question 
really is would CT of dynamic compression context really 
This section will be revised, if the draft is revised, to include 
dyanmic compression context. I believe I have someone from ROHC 
willing to contribute text. 
> 
> > ... 
> >>> 5.1 - ROHC Context for Header Profile Transfer 
> > It is assumed that the RAR and the SAR use identical header 
> > compression algorithms and header compression profiles. 
> 
> LEJ: As mentioned before, a ROHC profile can not possibly 
> be subject to transfer. In the same way, "header profile" is 
> not a term that makes sense either. A profile defines the 
> header compression protocol (algorithm) to be used. 
See above. There is a lot about ROHC which is in peoples heads, 
and not clear in the RFC (which would not be unusual for an IETF 
RFC *smile*). 
Thanks again for the comments. I certainly will keep them in mind 
if the draft is revised. I am very much open to comments, and hopefully, 
to contributed ideas/text. 
> 
>  
> 
> -----Original Message----- 
> From: Gary Kenward [ mailto:[email-masked]
<mailto:[email-masked]>  
> < mailto:[email-masked] <mailto:[email-masked]>
> ] 
> Sent: den 26 juli 2001 17:23 
> To: 'ROHC' 
> Subject: [rohc] ROHC context transfer 
> 
> 
> 
> Hello. 
> 
> I have submitted a draft to the Context and Micro-Mobility 
> Routing (Seamoby) 
> working group on "Context Transfer Considerations for ROHC". 
> ROHC is fairly 
> new to me, and I would really appreciate any feedback from 
> the ROHC wg. 
> 
> Regards, 
> Gary Kenward 
> 
> http://search.ietf.org/internet-drafts/draft-kenward-seamoby-c
<http://search.ietf.org/internet-drafts/draft-kenward-seamoby-c>  
t-rohc-reqs-00.txt <
http://search.ietf.org/internet-drafts/draft-kenward-seamoby-ct-rohc-reqs-00
.txt
<http://search.ietf.org/internet-drafts/draft-kenward-seamoby-ct-rohc-reqs-0
0.txt> > . 
title: Context Transfer Considerations for ROHC 
abstract: There is an interest in enhancing the performance of handover
between access 
routers through the transfer of forwarding context [2]. To clearly
understand the requirements 
for this transfer, it is useful to examine the requirements of specific
feature contexts. This 
document reviews the requirements for transferring the context associated
with RObust Header 
Compressions (ROHC [3]) in preparation for a handoff of the IP traffic being
compressed. 
author: Gary Kenward 
date: 07/12/2001 
id: draft-kenward-seamoby-ct-rohc-reqs-00.txt