Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover

From: [email-masked]
Date: Fri, 6 Apr 2001 15:44:25 -0500

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: "Phil Neumiller" <[email-masked]>
Date: Fri, 6 Apr 2001 16:02:45 -0500

This arguments seems completely bogus to me or I am missing something
really fundamental here.  Are not both 3GPP and 3GPP2 CDMA?  This
whole discussion falls apart and dies on the floor than.

----- Original Message -----
From: <[email-masked]>

> where header compression is going to be used are primarily cellular links.

1).  Based on what evidence?  So far we have WAP, iMode, and iDen.
Are you ignoring other possible edge and infrastructure technologies like
wirelesss PANs, WLANs, ad hoc networks for any particular reason?

> minimize the duration of the break.

In post-modern cellular systems there is no break!  Wake up!  Qualcomm
won the war a long time ago, I just can't get it why you guys are still in
this "break" mind set.  3GPP and 3GPP2 use CDMA!!!!  ITS MAKE BEFORE
BREAK.  THE SOONER PEOPLE START LEARNING HOW TO DEAL
WITH IP PACKETS OVER CDMA w/ soft handover THE SOONER the
MIP list will finally mature to where it needs to be (i.e. like OBAST :-)!!!

> if brute force header compression reinitialization is done, one would have to send
> certain number of 40-60
> bandwidth demand surge will put a strain on the link.

Please quantify this purported bandwidth demand surge and it origination.

> Some links will cope
> unavoidably affected.

Yes but why would we use MIPv6 over TDMA systems?  I just don't get
this argument at all????

>The impairment caused by the handoff is thus extended,

What it impairment, its a SOFT handoff?

> msec, without header compression.

The break will be 0 ms in 3G systems (only when a hard handover is forced)
is that what you are designing for the error leg cases?  Again this argument
seems rediculously TDMA.

I feel like Rip Van Winkle, did I wake up and everything went back to
TDMA?  Why are we discussing this with reference to IPv6 handovers??

Regards,

Phil

---

From: Michael Thomas <[email-masked]>
Date: Fri, 6 Apr 2001 14:15:17 -0700 (PDT)

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

---

From: Zoran Kostic <[email-masked]>
Date: Fri, 06 Apr 2001 17:52:02 -0400

In response to the assumptions about soft-handoff by Phil Neumiller.

  * Soft-handoff is used and works well for VOICE in CDMA systems
  * All versions of data-carrying CDMA systems get away from
     soft-handoff - that includes Qualcomm's HDR, 3GPP Downlink
     shared channel, 3GPP High-speed downlink shared channel...

Phil Neumiller wrote:

> ---
> Mailing list for Robust Header Compression WG
> Archive: http://www.cdt.luth.se/rohc/