Subject: RE: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compresso r on Mobile IPv6 Handover

From: [email-masked]
Date: Fri, 6 Apr 2001 17:32:45 -0500

Hi,

> 
> 
> [email-masked] writes:
>  > >  > > From: ext Michael Thomas [mailto:[email-masked]]
>  > >  > If there is no compression state at the old router, why 
>  > > would you try to
>  > >  > relocate it ? 
>  > > 
>  > >    There's compression state there, but not the 
>  > >    compression state that matters: when I'm 
>  > >    receiving packets from the old AR during the
>  > >    FMIP transition time, there will be a *new*
>  > >    IP header appended toward the MN. This is
>  > >    because those packets will have to be tunneled to the
>  > >    MN. This means that it is a *new* compression
>  > >    context, not an old existing one.
>  > >  
>  > I don't have sufficient details to comment..
> 
>    and then this:
> 
>  > You can't justify your claims. So, before you raise issues
>  > (related/unrelated), try to make an effort to understand 
> the work done by
>  > others. 
> 
>    I don't know what you would like me to do. I've
>    brought up an issue, and you've brushed it
>    aside assumedly as irrelevant. I've been paying
>    attention to this thread, and as far I can
>    tell, nobody has answered my question. 
>    

I was not meaning to brush aside your issue, I was simply saying I didn't
have sufficient details in your e-mail. Let me try to address your issue
based on my understanding of your point above.

Let's assume that context has been relocated from old AR to the new AR. The
new AR receives a packet tunneled to the MN. The new AR can now compress the
inner packet. What you do with the outer IP packet ? You could only send
required fields, e.g., you can compress src and dst addresses (32 bytes in
IPv6). What you need is an rohc packet format that indicates that this is a
packet belonging to an old context with *some* new information (such as the
Next Header field being IPv6). This *indication* bit should provide the
logic to demultiplex into the correct (existing) context. 

This is solution space, and needs work. I hope we can focus on requirements.

BTW, what is FMIP ? :-)

>    Also: you are also telling me that I have to
>    prove negatives of the form "tell me why we
>    _shouldn't_ do XYZ." That is a logical fallacy.
>    You may not like my message, but it does not
>    give you free reign to ignore reality. It is
>    in nobody's interest to design a protocol 
>    that does not work in the areas where it would
>    be most useful.
> 
> 

I don't wish to work on a protocol knowing that it is not going to be
useful. At this point however, my apprehensions, if any, are unnecessary. 

-Rajeev
 
	   Mike

---

From: "Gary Kenward" <[email-masked]>
Date: Tue, 10 Apr 2001 10:36:07 -0400

Well put!

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, April 06, 2001 4:44 PM
> To: [email-masked]; [email-masked]
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting 
> Compressor
> on Mobile IPv6 Handover
> 
> 
> Hi,
> 
> I have been too busy to comment on all these mails, but I 
> just want to say a
> couple of things.
> 
> I'm afraid that it
> >    is your place to prove that context transfer
> >    of header compression state in the face of all
> >    of these extenuating circumstances is still
> >    worthwhile.
> 
> There have been many mails pointing out the merit of doing header
> compression context transfer. To repeat them: 
> continued, seamless compression/decompression, higher compression
> efficiency, and minimization of degradation on the user 
> media. This last
> point is the most important in my mind. At this stage, the 
> link technologies
> where header compression is going to be used are primarily 
> cellular links.
> In the cellular environment, handoffs (or handovers) are 
> events that happen
> in normal operation, and therefore a very significant design 
> effort is spent
> to minimize the impact of HO on performance. In particular, 
> one wants to
> minimize the duration of the break. If brute force header compression
> reinitialization is done, one would have to send a certain 
> number of 40-60
> byte or more IR headers, instead of the usual 1 byte header. This big
> bandwidth demand surge will put a strain on the link. Some 
> links will cope
> with it by blanking out the user data to make room to carry 
> the IR headers.
> When such blanking takes place, the user media (voice, etc.) will be
> unavoidably affected. The impairment caused by the handoff is 
> thus extended,
> compared to the case where header compression is not present.  
> 
> In the current and 3G cellular technologies, the break is 
> about 100-150
> msec, without header compression. This already translates 
> into the loss of
> 5-6 20 msec packets. If some IR headers have to be sent by 
> blanking out the
> user data, the break will be significantly longer. For 
> example, if 3 (an
> optimistic value) IR headers are sent, the resulting break is 
> increased to
> 8-9 packets worth.
> 
> I also want to point out that minimization of the break will help in
> futureproofness.  Applications that will be introduced in the 
> future may be
> even more sensitive to the break (or the threshold for user perceived
> degradation may be lower) than the currently known ones. For 
> example, if a
> packet is generated every 10 msec, the number of packets 
> affected will be
> doubled.
>    
> The only way to minimize the break is to do header compression context
> transfer.  
> 
> 
> Khiem
> > -----Original Message-----
> > From: Koodli Rajeev (NRC/MtView) 
> > Sent: Friday, April 06, 2001 1:13 PM
> > To: 'ext Michael Thomas'; Koodli Rajeev (NRC/MtView)
> > Cc: Le Khiem (NRC/Dallas); [email-masked]; 
> > [email-masked];
> > [email-masked]; [email-masked];
> > [email-masked]; [email-masked]; 
> [email-masked]
> > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor 
> on Mobile
> > IPv6 Handover
> > 
> > 
> > > 
> > > 
> > >  > > Can somebody explain to me how this has any
> > >  > > possible applicability if you are using FMIP
> > >  > > during the transition? FMIP requires a new tunnel
> > >  > > for which there will be no compression state in
> > >  > > the old access router.
> > >  > > 
> > >  > 
> > >  > > All of these interactions with MIP, FMIP, HMIP
> > >  > > etc, etc make it look to me like this is a losing
> > >  > > situation. It may be the better part of valor to
> > >  > > say that fast/smooth handoffs are inherently more
> > >  > > bandwidth consumptive and that one of the
> > >  > > casualties is header compression state in the mean
> > >  > > time. 
> > >  > 
> > >  > Can you justify your claim above ?
> > > 
> > >    I can't prove negatives. I'm afraid that it
> > >    is your place to prove that context transfer
> > >    of header compression state in the face of all
> > >    of these extenuating circumstances is still
> > >    worthwhile.
> > > 
> > 
> > (related/unrelated), try to make an effort to understand the 
> > work done by others. 
> > 
> > As far as I am concerned, how about all the e-mail discussion 
> > during the last two weeks ? Please take a look!
> > 
> > >  > >Trying to extend a point to point L2
> > >  > > compression mechanism across an arbitrary internet
> > >  > > is just *bizzare*. L2TP is bad enough.
> > >  > > 
> > >  > 
> > >  > You are compressing IP and transport headers! This should 
> > > work on ANY link.
> > >  > That's why you try to CT header compression state. Get it ?
> > > 
> > >    Oh sure, I get it... I "get" VoMPLS too, but
> > >    that doesn't make it any less bizarre.
> > > 
> > 
> > If you got it, you would probably re-think! If you were to 
> > re-think and understand the issues, you would probably 
> > question yourself what's bizarre, and then write. 
> > 
> > -Rajeev
> > 
> > > 	    Mike
> > > 
> > 
>

---

From: Kulwinder Atwal <[email-masked]>
Date: Tue, 10 Apr 2001 20:59:50 -0400

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Tuesday, April 10, 2001 8:35 PM
> To: Kulwinder Atwal
> Cc: 'Michael Thomas'; Gary Kenward; 'seamoby'; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting
> Compresso r on Mobile IPv6 Handover
> 
> 
> Kulwinder Atwal writes:
>  > >    Fine. You said that it looked like a problem with
>  > >    FMIP and it should be fixed there. What leads you
>  > >    to that conclusion and what would you have them do?
>  > 
>  > What lead some of us to that conclusion are two things:
>  > 
>  > 1. Your statement below in a previous emial:
>  > > All I'm asking here is how CT would interact with
>  > > FMIP. I believe that FMIP is very likely to be a
>  > > very important part of handoffs and as such, I
>  > > would like to know whether CT for header
>  > > compression state will help, hinder or be of no
>  > > benefit at all. From what I can tell, there is
>  > > indeed a problem and it is not clear whether there
>  > > is a solution, or whether the solution would be
>  > > worse than the original problem given the high
>  > > likelihood of race conditions, etc.
> 
>    I fail to see how this supports your argument.
>    You can't run ROHC end to end either. That 
>    doesn't imply that IP is broken.
> 

Rather than me just repeating what Gary K said in his emails today, please
re-read his emails. Ditto.  

Before responding, please read Rajeev's enlightenment on how to do ROHC CT
for FMIP.

- Kulwinder.