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

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

Michael:

   It *may* be the case here that FMIP is deficient in supporting context
transfer for header compression state. FMIP does not define the problem 
space. Kheim has done a fairly eloquent job of describing a real world issue
with wireless handover. To say that FMIP won't support it is to say that
FMIP
is broken, not that the problem should not be solved.

  So let's get on with solving the problem. If there is a requirement to
change
FMIP, I'm sure the MIP group would be interested in our input. After all,
that is one of the reasons Seamoby was chartered.

Gary

"When your only tool is a hammer, all your problems tend to look like nails"

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Friday, April 06, 2001 5:15 PM
> To: khiem.le
> Cc: [email-masked]; [email-masked]; 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
> 
> 
> Kheim, 
> 
> I sorry to be so argumentative here, but I'm sure I
> could come up with a long laundry list of the benefits
> of quantum teleportation too. What obviously must be
> done beyond wanting such a thing is to see:
> 
> o if it can be done at all
> o whether it would still be a benefit once we
>   had done it.
> 
> For example, if we could do quantum teleportation
> but the only way we could figure out how to
> teleport a person resulted in them dying, I'm sure
> you'd agree that we ought to reevaluate the
> benefits.
> 
> 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.
> 
> 	   Mike
> 
> [email-masked] writes:
>  > 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
>  > > 
>  > > 
>  > > > 
>  > > > 
>  > > > [email-masked] writes:
>  > > >  > > From: ext Michael Thomas [mailto:[email-masked]]
>  > > > 
>  > > >  > > 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.
>  > > >  > > 
>  > > >  > 
>  > > >  > 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..
>  > > 
>  > > >  > > 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.
>  > > > 
>  > > 
>  > > 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. 
>  > > 
>  > > 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: Michael Thomas <[email-masked]>
Date: Tue, 10 Apr 2001 08:36:38 -0700 (PDT)

> is broken, not that the problem should not be solved.

   I find it hard to fault FMIP here; it's just setting up
   a tunnel between the old AR and the MN. There's nothing
   "broken" about that. The alternative is not
   exactly very pretty either and could lead to
   some bizarre and unforseen side effects (though MIPv4
   may have a handle on them). There's a lot to be 
   said about preserving transparency when ARnew
   and ARold have no relationship with one another.

 > that is one of the reasons Seamoby was chartered.

   The requirement belongs on CT, not FMIP. It may
   also be a bogus thing to do given the way that
   ROHC/CRTP works.

		Mike