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

From: Pete McCann <[email-masked]>
Date: Tue, 3 Apr 2001 13:31:52 -0500 (CDT)

Hi,

I think there is a simpler solution to this problem that most people
are overlooking.

It should be possible to keep the compressor/decompressor state at the
old access router and to tunnel the already-compressed packets to and
from the new access router.  Then the MN and new access router can
renegotiate header compression state from scratch and take as long as
they want to do so, because the MN is still getting service in the
meantime.

Someone earlier asked about support for ROHC on IP tunnels and I think
this would be a good application for that.

We are trying to move the mountain to Mohammed and I don't see why we
can't do the reverse instead.

-Pete

---

From: [email-masked]
Date: Tue, 3 Apr 2001 20:39:49 -0500

Hello Tmima,

some comments below.

Regards,

-Rajeev

> -----Original Message-----
> From: ext Tmima Koren [mailto:[email-masked]]
> Sent: Tuesday, April 03, 2001 6:19 PM
> To: [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile
> IPv6 Handover
> 
> 
> I wonder if it's possible to do both:
> The new router sends a request for context transfer, but continues to 
> forward the compressed packets to the old router, AND queues 
> a copy of the 
> packets he forwarded. Once he receives the context, the new 
> router applies 
> the necessary changes to the context from the queued packets. Now his 
> context is good and he can continue decompressing.
> Tmima
> 

It may be possible to do both, perhaps should not be necessary. One of the
requirements for seamoby will be to meet a fast response time requirement
that would mean that the context has to be present at the new router when
compressed packets arrive. In your proposal, I also see the need for
synchronizing (more than one) compressed buffered packets with the context
that arrives later. This may be non-trivial. 

Regards,

-Rajeev

> At 07:58 PM 4/3/2001 -0500, [email-masked] wrote:
> > > -----Original Message-----
> > > From: ext Pete McCann [mailto:[email-masked]]
> > > Sent: Tuesday, April 03, 2001 5:30 PM
> > > To: [email-masked]
> > > Cc: [email-masked]; [email-masked];
> > > [email-masked]; [email-masked]
> > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting 
> Compressor on Mobile
> > > IPv6 Handover
> > >
> > >
> > >
> > >
> > > Yes, you would need to re-initialize the context over the 
> air, but I
> > > don't think the bandwidth usage is high enough to matter.  In a
> > > wide-area cellular environment IP handoffs will be relatively
> > > infrequent.  The important consideration is the "glitch" 
> experienced
> > > in voice traffic at handoff time, and this can be minimized by
> > > temporarily anchoring the compressor.
> > >
> >
> >I don't agree with you comments that you could ignore 
> bandwidth usage and
> >assume infrequent handovers.
> >
> >a> 84 bytes of IPv6/UDP/RTP headers with Mobile-IPv6 Home 
> Address option for
> >a voice payload of 20 - 30 bytes. Several such packets sent 
> per each stream.
> >
> >b> With fast user mobility, each BTS/AP being a router, I can imagine
> >frequent handovers.
> >
> >In any case, context relocation addresses a>, does not 
> assume infrequent
> >handovers, as well as attempts to provide "glitch-free" 
> voice. When the
> >context is already present at the target router before the 
> MN starts sending
> >compressed packets, the application should not see the glitch.
> >I know there is work to be done here, so let's try to focus on that!
> >
> >Regards,
> >
> >-Rajeev
> >
> >
> > > -Pete
> > >
> > > [email-masked] (rk) writes:
> > >
> > > rk> Hi,
> > >
> > > rk> How does this avoid the core problem of context
> > > rk> _re-initialization_ ? You would still need to send IR 
> packets (to
> > > rk> new access router over the air interface) subsequent 
> to handover
> > > rk> in order to start a new context..  Anchoring it at 
> the previous
> > > rk> router may buy you some time, but not the bits.  I reckon
> > > rk> anchoring will bring its own set of problems.
> > >
> > > rk> Regards,
> > >
> > > rk> -Rajeev
> > >
> > >
> > > >> -----Original Message-----
> > > >> From: ext Pete McCann [mailto:[email-masked]]
> > > >> Sent: Tuesday, April 03, 2001 11:32 AM
> > > >> To: [email-masked]
> > > >> Cc: [email-masked]; [email-masked];
> > > >> [email-masked]
> > > >> Subject: RE: [seamoby] RE: [rohc] RE: Restarting
> > > Compressor on Mobile
> > > >> IPv6 Handover
> > > >>
> > > >>
> > > >>
> > > >> Hi,
> > > >>
> > > >> ---
> > > >> Mailing list for Robust Header Compression WG
> > > >> Archive: http://www.cdt.luth.se/rohc/
> > > >>
> > > rk> ---
> > > rk> Mailing list for Robust Header Compression WG
> > > rk> Archive: http://www.cdt.luth.se/rohc/
> > >
>

---

From: "Martin, David P" <[email-masked]>
Date: Wed, 4 Apr 2001 07:27:22 -0400

>In any case, I believe the context transfer (whether RCLS or RDLS) is
>doable, and the advantages over brute force reinitialization over the
>wireless link outweigh the costs.
>
>Khiem

Why shouldn't the protocol support both methods and let the implementors
choose the approrpriate solution for their networks?

---

From: "Gary Kenward" <[email-masked]>
Date: Wed, 4 Apr 2001 09:46:47 -0400

Many real time context synchronization problems can be solved 
through "bi-casting", which is, I believe, the essence of what you
describe.

Gary

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, April 04, 2001 12:16 AM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Your idea is very similar to the one I had some time ago (refer to
> http://www.cdt.luth.se/robhc/msg01274.html).
> 
> Essentially the idea is to relax the timing constraints and 
> allow some time
> to establish the context at the new compressor/decompressor. 
> During that
> context establishment time, the packets transit through the new
> compressor/decompressor, but also transit through the old 
> which continues to
> do compression/decompression. Once the context is 
> established, the new can
> take over the compression/decompression process. 
> 
> The old compressor/decompressor helps the new compressor/decompressor
> establish its context by sending some context information. 
> One way (as you
> described, correct me if I am wrong) is to take a snapshot of 
> the context
> and send it. To maintain context synchronization between the 
> old and new,
> the new may do some update of the received context snapshot 
> to account for
> the fact that the context may have been updated by the old 
> after it took the
> snapshot. However, the problem is that packets may be lost 
> when sent from
> the old to the new. So the new may do a context update based 
> on packet j,
> but that update was not done by the old, since packet j was 
> never received
> by the old. One way to solve this problem is to modify the 
> mechanism to send
> the context information from old to new. Instead of sending a context
> snapshot, the old sends the context-related information in 
> pieces, so the
> new can gradually build up its context. This corresponds to the
> Relocation-deferred-after-Link-Switching (RDLS)scheme in
> http://www.cdt.luth.se/robhc/msg01274.html. You can look at 
> it for details.
> 
> The case where the old takes a snapshot of its context and 
> sends to the new
> for immediate transfer of compression/decompression role 
> corresponds to
> Relocation-concurrent-with-Link-Switching (RCLS).
> 
> RDLS addresses the timing problem in a very reliable manner, 
> but is more
> complex than RCLS. It also requires a higher capacity 
> connection between the
> old and new. So each approach has its pros and cons.
> 
> > Sent: Tuesday, April 03, 2001 8:19 PM

---

From: [email-masked]
Date: Wed, 4 Apr 2001 11:39:49 -0500

Hi,

One of the main points of my proposal (RDLS case) is that the
compression/decompression process in the MN is absolutely not affected by
handoff. Actually it is not even aware handoff happened. So one compressor
in the MN is enough.:-)

Khiem

> From: ext Phil Neumiller [mailto:[email-masked]]
> Sent: Wednesday, April 04, 2001 3:57 AM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile
> IPv6 Handover
> 
> 
> Of coures I like make-before-break and Moore's law and run two
> compressors in the MN and discard one when I no longer need it.
> 
> -pdn ;-)
> 
> ----- Original Message ----- > Hello Tmima,
> >

---

From: Michael Thomas <[email-masked]>
Date: Thu, 5 Apr 2001 12:12:11 -0700 (PDT)

Dr. Carsten Bormann writes:
 > > > My understanding about cellular traffic channels
 > > > -- and I would be happy to find out differently --
 > > > is that they do not deal well with variable rate
 > > > traffic well. This is unsurprising since they are
 > > > heavily optimized for voice traffic which has very
 > > > regular periodicity and payload sizes.
 > >
 > > This basically means that these links are not that capable of
 > > handling IP traffic.
 > 
 > Actually, they are.  They are just not good at handling traffic whose
 > payload already maxes out the link.
 > 
 > If the objective is to use only exactly as much capacity as is needed for
 > the payload, my humble advice would be not to run IP over the link.
 > 
 > (Oh, and one aspect often forgotten about wireless links is that you can
 > often play with the channel coding.  This gives you *some* form of VBR --
 > combined with variable BER, unfortunately.)

   I certainly can't disagree with your general 
   sentiment -- there's obviously a bandwidth
   price to be paid with packetization. However,
   there are certain MAC layers which are not
   friendly to variable rate compression schemes.
   DOCSIS cable is one of them given the way 
   you'd like to transport RTP (eg using
   unsolicited grants at the MAC layer).

   I hope that you don't consider me as being
   antagonistic to ROHC (or CRTP) because that
   is not the case. My questions here were mainly
   a sanity check as to whether the places people
   want to do ROHC will actually be on a MAC layer
   which is friendly to ROHC. My sense is that 
   some or all of the important ones (cellular)
   will not which is an important consideration 
   when it comes down to priorities and making
   a good case to get this through the IESG.

	  Mike

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 6 Apr 2001 14:29:33 -0400

Khiem:

  You are right, it is not bicasting. I misunderstood. However, the approach
is
the same, with the complication that now you have a triangular route to
clean
up. Is there an advantage?

Gary

> Sent: Friday, April 06, 2001 11:53 AM
> To: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Hi Gary,
> No this is not bicasting. The path taken by the packets 
> (during the context
> establishment at the new compressor/decompressor) is as follows:
>  
>  
> -------> Old compressor/decompressor ----------> New 
> compressor/decompressor
> -------------> MN
>  
> <------ Old compressor/decompressor <---------- New 
> compressor/decompressor
> <------------- MN
>  
> Khiem
> 
> From: ext Gary Kenward [mailto:[email-masked]]
> Sent: Wednesday, April 04, 2001 8:47 AM
> To: [email-masked]'; [email-masked]; 
> Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor 
> on Mobile IPv6
> Handover
> 
> 
> 
> > From: [email-masked] [ mailto:[email-masked]
> <mailto:[email-masked]> ] 
> > http://www.cdt.luth.se/robhc/msg01274.html
> <http://www.cdt.luth.se/robhc/msg01274.html> ). 
> > 
> > http://www.cdt.luth.se/robhc/msg01274.html
> <http://www.cdt.luth.se/robhc/msg01274.html> . You can look at 
> > it for details. 
> > 
> > > From: ext Tmima Koren [ mailto:[email-masked] 
> <mailto:[email-masked]>
> ] 
> > > > > From: ext Pete McCann [ mailto:[email-masked]
> <mailto:[email-masked]> ] 
> > > > > >> From: ext Pete McCann [ mailto:[email-masked]
> <mailto:[email-masked]> ] 
> <http://www.cdt.luth.se/rohc/>  
> > > > > >> 
> > > > > rk> --- 
> <http://www.cdt.luth.se/rohc/>  
> > > > > 
> > > 
> > > --- 
<http://www.cdt.luth.se/rohc/>

---

From: [email-masked]
Date: Fri, 6 Apr 2001 16:48:14 -0500

Hi Mike,

> From: ext Michael Thomas [mailto:[email-masked]]
> Sent: Friday, April 06, 2001 4:15 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> 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.

KL: At the least, and correct me if I am wrong, what you are saying is, at
this stage, we should at least consider and investigate context transfer,
before jumping to any conclusions that it should not be done. I agree. 
> 
> 	   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
>  > > 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]
>  > > > [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: Kulwinder Atwal <[email-masked]>
Date: Mon, 9 Apr 2001 22:04:32 -0400

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Friday, April 06, 2001 5:15 PM
> To: [email-masked]

Just becuase it doesn't work for FMIP does not mean we should stop.  If it
doesn't work for FMIP then change FMIP.

- Kulwinder.

---

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

> Sent: Friday, April 06, 2001 1:46 PM
> To: rajeev.koodli
> Cc: [email-masked]; [email-masked]; Kenward, Gary 
> [WDLN2:AN10:EXCH];

Sounds like a problem with FMIP to me.

Gary