Subject: [mobile-ip] Restarting Compressor on Mobile IPv6 Handover

From: James Kempf <[email-masked]>
Date: Tue, 27 Mar 2001 17:05:02 -0800 (PST)

Carsten & Mikael,

I came away from our discussion in the lobby of the Hilton on Thurs. nite of 
IETF with the impression that the design center of the ROHC work has
been IPv4. In mobile IPv4, the Foreign Agent strips off tunnel overhead
before the packet is sent over the air, so that the IP header remains the
same after the mobile node moves from one FA to another. As a result,
the compressor state can theoretically be moved from one FA to another without 
requiring any changes.

In IPv6, the mobile node handles the care of address itself. This means
that the header will change when the mobile node moves from one Access
Router to another because the care of address will change. As you requested
in our conversation on Thurs nite, I have appended an IPv6 header to this email 
describing what fields change when the mobile node moves (basically, it will be 
the destination address in the uplink direction and the source address in the 
downlink direction).

In addition to this simple case, the mobile IP group is also examining
designs for hierarchical mobile IP. A hierarchical design eliminates
signalling back into the wired network to the home agent when the mobile
node moves within a certain domain. Instead, the mobile node is
only required to report its new care of address to the hierarchical
agent once across the wireless link. Only when the mobile node moves from  one 
hierachical domain to another must signalling be done to the home agent, and any 
corresponding nodes if route optimization is in effect. This substantially
reduces the amount of signalling over the wireless link if the mobile
node has many corresponding nodes.

One of those designs (HMIPv6 extended mode) appends an additional 40 bytes
of tunnel overhead onto the basic mobile IP header. This tunnel header
will also change when the mobile node moves from one subnet to another,
as is the case for the care of address in the simple MIPv6 case, 
and it occurs on every packet that is processed by the hierarchical
agent (called a Mobile Access Point, or MAP). One of the authors of HMIPv6
is asserting that header compression will remove this tunnel overhead
and that restarting the compressor will be
possible by simply transferring context from the old Access Router
to the new, then updating the state with the new parameters, so that
there will be no need for sending any full headers across the radio
link.

Sending full headers across the radio link in either the simple or hierarchical 
case is to be avoided, because it would increase the latency in handoff. Any
increase in handoff latency is extremely undesirable.

I would be interested in hearing your opinion on this, as would, I think
the mobile IP working group in general. If you need more
data about what the headers will look like with the HMIPv6 tunnel
overhead, Hesham Soliman, one of the co-authors of the proposal (who
has been cc'ed on this email) can give it to you.

			jak
			
--------------------------------------------------------------------------------
Source address changes on handoff for downlink direction
Destination address changes on handoff for uplink direction

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version| Traffic Class |           Flow Label                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Payload Length        |  Next Header  |   Hop Limit   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                         Source Address                        +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                      Destination Address                      +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 28 Mar 2001 14:12:44 +0200

Just some clarifications below.

> the destination address in the uplink direction and the source address in the 
	=> It's actually the opposite. The destination address in the 
	down link and the source address in the uplink. We're talking about 
	the MN right ?

> agent (called a Mobile Access Point, or MAP). 
> 
	=> Mobility Anchor Point.

> One of the authors of HMIPv6
	=> Yes that's me. Based on some discussions with the authors of ROHC.

> there will be no need for sending any full headers across the radio
	=> Not me. I said (again based on some discussions with ROHC 
	authors) that restarting the compressor (if there is no context transfer)
	will take very few packets (3-4) with full headers first. 
	I made no statement on how it would work with context transfer, 
	because I don't know.

> has been cc'ed on this email) can give it to you.
	=> Sure. Of course there is always a Home Address option
	in the outgoing packets (from the MN) and it may also
	exist in the incoming (downlink) packets. But this option
	does not change.

	Hesham

---

From: [email-masked]
Date: Wed, 28 Mar 2001 15:38:00 -0600

Hi,

some comments on the thread. 

1. It has become clear to me that there is no clear consensus in rohc on how
many IR packets are needed for context establishment. In the presence of
high error rate, such as the conditions present across cell boundaries
during handover (as Zhigang pointed out), it appears to me that the only
safe approach to be sure that the context is established is if the
compressor receives an appropriate ACK. I am not saying that taking a guess
will not work, I am just not sure what the magic number (of IR packets) is
for the compressor to send. Again, considering the error conditions, it
appears to me that sending "several" packets, as the rohc draft proposes,
might be a good thing to do. 

In the approach that does not wait for an ACK, there is a clear trade-off
between how many IR packets are sent versus the penalty incurred due to
failure to establish contexts; fewer you send, larger the chance of context
establishment failure. If the context cannot be established quickly and
reliably, it will lengthen the initialization process and is not desirable. 

2. Context establishment has to be done for each unidirectional packet
stream. For voice, this means two streams. When you have multimedia, you
will have more streams. In summary, the overhead goes up as the number of
streams increases. 
In comparison, when you do context relocation, you can move all the contexts
over a higher-speed link across routers. Besides, for seamoby, you can
maintain "seamless" header compression across handovers. 

3. With MIPv6, the header overhead is 84 bytes for IPv6/UDP/RTP with Home
Address option! I guess voice payload would occupy about 20-30 bytes ? 
IPv6/TCP header size is also 60 bytes (without TCP options). 

4. For short-lived flows, such as web that get done in 10-20 packets, the
cost of context establishment with respect to flow longevity is a concern.
Thus, a mobile-ip mechanism that relies on header compression should address
this problem. 
I agree with James that there is a problem with changing CoA forcing context
initialization.  One way to address this in context relocation is to send
the new CoA along with the rest of the context. The MN MAY send an update
packet containing the new CoA subsequent to handover as well. I mentioned
this to James.

Regards,

-Rajeev

> -----Original Message-----
> From: ext [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, March 28, 2001 9:28 AM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover
> 
> 
> Hi,
> 
> I've been following this discussion for a while. Please see
> my comments below.
> 
> Br,
> Zhigang
> 
> > > (basically, it will be 
> > > the destination address in the uplink direction and the 
> source address
> in the 
> > > downlink direction).
> > > 
> I guess Hesham is right, if downlink == to the mobile node.
> 
> There are some guessing/assumptions behind the number (3-4).
> I'm not so sure that's always the case. The radio link condition
> before/after handover is likely be worse than normal condition.
> That may mean more packets could be lost (in this case, IR packets).
> That will has impacts on the guessing of the number.
> 
> Although we're talking about "very few" packets (be it 3-4 or 5-6), 
> they are LARGE (40+ bytes for RTP/UDP/IPv4 headers and 60+ bytes 
> for RTP/UDP/IPv6 headers). And most of the header fields are static. 
> That is the issue. With HC context relocation, there is no need to 
> send the static fields over the air. The reduced overhead means
> less pain (e.g. delay, possible stealing or blanking of voice 
> payload).
> 
> Note that smaller packets have lower chance to be hit by transmission 
> errors (even just one bit) and thus lost, assuming no link layer
> retransmission (which makes sense for real-time multimedia). 
>  
> This is another good reason for HC context relocation, as that 
> increase the weight of static header fields.
> 
> 
> > 	Hesham
> > 
> > > 
> > >    |                                                      
>          |
> > >    +                                                      
>          +
> > >    |                                                      
>          |
> > >    +                         Source Address               
>          +
> > >    |                                                      
>          |
> > >    +                                                      
>          +
> > >    |                                                      
>          |
> > >    |                                                      
>          |
> > >    +                                                      
>          +
> > >    |                                                      
>          |
> > >    +                      Destination Address             
>          +
> > >    |                                                      
>          |
> > >    +                                                      
>          +
> > >    |                                                      
>          |
> > ---
> > Mailing list for Robust Header Compression WG
> > Archive: http://www.cdt.luth.se/rohc/
> > 
> ---
> Mailing list for Robust Header Compression WG
> Archive: http://www.cdt.luth.se/rohc/
>

---

From: Claude Castelluccia <[email-masked]>
Date: Thu, 29 Mar 2001 09:39:33 +0200

Hello Zhigang,

I seems from your email that context relocation will be very useful for RoHC.
Is istalso the case if some packets are lost  when a MN moves from one base
station
to another one?

In this case it is better to restart the context or relocate it?
Do you know of any studies on this topic?

thanks a lot!

Claude.

[email-masked] wrote:

> less pain (e.g. delay, possible stealing or blanking of voice payload).
>

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 29 Mar 2001 19:02:42 +0200

Hello Zhiang, 

So it seems ot me that there is no clear consensus in ROHC
on context relocation. Is that because the need is not proven ?

I guess we need to know how bad a channel can be. I might 
be completely wrong here but if we're only talking about 
a couple of packets to sync the compressor, then context
relocation seems to be an overkill. However, if the amount 
of packets sent with full headers is significant, then I can 
understand the need. 
But either way it doesn't seem to be a problem since you 
said that context relocation (if needed) will solve this. Right ?

So I don't know why we (MIP WG) should be involved. 
It seems to be a ROHC/SEAMOBY issue. 

Regards,
Hesham

> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Friday, 30 March 2001 2:53
> To:	[email-masked]; [email-masked]
> Cc:	[email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Hi Claude,
> Context relocation is useful regardless of the loss of packets during 
> handover as the bulk of the saving (of bytes over the radio links) comes 
> from the static header fields. For example, the new compressor (for
> downlink) 
> can jump start in FO state in stead of going through IR state all over
> again.
> 
> We have been studying HC context relocation since spring 1999 (when we 
> started ACE). Khiem has proposed text to ROHC list in June 2000 
> (http://www.cdt.luth.se/robhc/msg00508.html). Unfortunately, that item was 
> not included in ROHC I-D, partially due to the urgency to finish the basic
> ROHC scheme (plus objections from some of the ROHC authors). 
> 
> Now, it's time we give it a serious look.
> 
> Br,
> Zhigang
> 
> From: ext Claude Castelluccia [mailto:[email-masked]]
> Sent: Thursday, March 29, 2001 1:40 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover
> 
> 
>   
> Hello Zhigang,

---

From: [email-masked]
Date: Thu, 29 Mar 2001 12:07:40 -0600

Just a quick addition: even if the packets are lost, a good compression
algorithm re-syncs itself with the successfully received packets. We have
done some experimental study on context relocation using ACE as the
compression algorithm (I believe it is used as the basis for the R-mode in
rohc) and ACE can continue in FO state. This study is currently under
submission, so I cannot provide the document. In any case, the summary is
that context relocation works even with reactive handovers such as the basic
MIPv6 ones. We believe that with fast handovers, it will get better. 

There is also the draft
 
http://search.ietf.org/internet-drafts/draft-koodli-seamoby-hc-relocate-00.t
xt

Sorry my quick comment took so long!

Regards,

-Rajeev

> Sent: Thursday, March 29, 2001 8:53 AM
> From: ext Claude Castelluccia 
> [mailto:[email-masked]]
> I seems from your email that context relocation will be very 
> useful for
> RoHC.

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 29 Mar 2001 21:00:02 +0200

Hello Rajeev, 

> I did not get this picture when reading Zhigang's e-mail. 
> 
	=> Well I got the picture from other emails though ;)

> I believe he said
> rohc had to attend the urgent matter of a draft for IP/UDP/RTP compression.
> I guess the focus was on coming with a scheme that described the functioning
> of an rohc compression mechanism that would also include context
> initialization! Mobility, handover was perhaps outside the scope..
> 
	=> Ok. I'm not active in ROHC so I can't really guess the reasons,
	what I'm observing though is that the ROHC experts 
	do not have consensus on this. But this is outside our scope.

> I agree that we need a reasonable number. The number of packets needed to
> initialize the context, it appears, can vary. I have heard 3 packets before,
> but not two! The key issue is the compressor has to have "sufficient
> confidence" according to rohc draft. The issue of confidence is critical
> because of error conditions prevalent on cellular links. These errors could
> be worse across cell boundaries during handovers. Furthermore, you have to
> do context initialization for _each_ packet stream!
> 
> Also, I don't agree that context relocation is an overkill when few IR
> packets are needed. Consider a channel optimized for sending 24 bytes of
> voice payload and 4 bytes of header. Such CBR-like channels are common in
> cellular, I gather. Now, if you have to send a header 84 bytes long
> (IPv6/UDP/RTP + Home Address option), that is 3 voice packets. One approach
> used to handle surges in bandwidth is to puncture bits in payload. If you
> were to do that, you need to effectively live with the drop of 9 voice
> packets (24 bytes of payload + 4 bytes of header) for 3 IR headers! This is
> user-perceived disruption _due to context initialization_. 
> 
	=> I'm neutral to the above. All I wanted to know was if there
	was a problem ? and can this problem be solved ? The clear
	answer I'm getting is yes for the second part and that's 
	all I wanted to know.

> Well, I think header compression context relocation is doable in seamoby. We
> need some help from rohc in defining what a context is, say e.g.,
> IPv6/UDP/RTP/voice-G.723.1. 
> 
	=> Good.

> I guess MIP list is cross-listed because HMIPv6 is relying on rohc to
> provide header compression support, which involves context initialization,
> which in turn could be avoided during handovers using context relocation!
> 
	=> No, I disagree. IP_deployment_in cellular networks relies 
	on ROHC. MIPv4/v6 in general relies on ROHC to be deployed
	in cellular networks. This is the reality. If you're sending complete
	IP headers in a VOIP call, then I'll just stick to my GSM phone.

	Hesham

---

From: [email-masked]
Date: Thu, 29 Mar 2001 17:40:20 -0600

Hi Mike,

Your concern is very valid and has been looked into by ROHC WG.
Just a few clarifications:

1) The compressed header size will likely be 1 byte most of the time
(>90%). Then, some first order headers (3~5 bytes). Then, few full
header. As you said, how to send the last two types of packets is
non-trivial. But it is doable. For example, very large headers can
be handled by segmentation either at link layer of by ROHC itself
(see section 5.2.5 of ROHC-09).

2) I guess you're referring to TDMA radio. My understanding is that
CDMA may have a better handle on (slight) VBR.

IMHO, ROHC has done a good job to achieve both robustness and
efficiency. Let me rephrase Carsten's question this way: if 
ROHC is not "appropriate on the air", do you have better approaches
in mind?

Br,
Zhigang

> From: ext Michael Thomas [mailto:[email-masked]]
> Sent: Thursday, March 29, 2001 5:02 PM
> To: Dr. Carsten Bormann
> Cc: Michael Thomas; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile
> IPv6 Handover
> 
> 
> Dr. Carsten Bormann writes:
>  > >  > (Side note: for hisorical and technical reasons, dealing with
>  > >  > realtime VBR over radio links is much a headache than 
> over wired
>  > >  > links. )
>  > >
>  > >    A-ha! That's one of the reasons I question whether
>  > >    ROHC is even appropriate on the air except in a
>  > >    very small subset of cases (usually long lived streams
>  > >    like RTP for which it was originally intended) As
>  > >    a general purpose tunnel/header compressor, I suspect 
> it is going
>  > >    to have severe thrashing with the way that radio
>  > >    resources are doled out by the AP.
>  > 
>  > I'm not sure why you are saying that (apart from the fact 
> that we haven't
>  > really done anything else but ROHC RTP yet).  How is ROHC 
> worse than
>  > uncompressed IP or 2507-compressed IP?
> 
> Carsten,
> 
> 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. DOCSIS
> cable is somewhat similar (with which I'm much
> more familar), and the fixed size slots cause
> variable rate coders like CRTP and ROHC much grief
> because the MAC scheduler does not have the
> ability to occassionally allow larger packets in
> real time on an unsolicited grant SID; if you
> start a session with packets every 20ms with 80
> bytes of payload, that's exactly what you get. If
> you occasionally need to send 81 bytes, you cannot
> send it on that traffic channel.
> 
> This presents a real problem for CRTP and ROHC
> when they need to send full headers or first order
> changes.  For this reason, the cable folks perform
> what they call Payload Header Suppression instead.
> Basically, it's just a first order compressor
> which is always on (sorry, if I've got your
> nomenclature mixed up). This obviously works, but
> is not as efficient. Also, I have no idea how it
> compares in robustness.
> 
> Now, it may be that the cellular MAC's and PHY's
> need some retooling in the long run in which case
> ROHC will work better, but if they work like I
> think they do, it's going to be problematic in the
> intervening time.
> 
> 		Mike
>

---

From: James Kempf <[email-masked]>
Date: Thu, 29 Mar 2001 16:14:52 -0800 (PST)

Zhigang,

>ROHC is not "appropriate on the air", do you have better approaches

I agree that ROHC has done a good job and I don't want to imply by the
following proposal that ROHC, perhaps modified to deal with context
transfer and parameterized restart in IPv6, could not handle the
problems with IPv6. This is just something I've been thinking about
that might work if modifying ROHC is too difficult, or if the ROHC
group has other priorities, like completing compression work on IPv4
algorithms. Maybe it is completely unworkable in the end.

Assume that the Access Router and the mobile node could set up a 
unique IPv6 flow label between them. This could also be done end to
end with the corresponding node, if one wanted to preserve end to end
semantics on the flow label.

Now, the Access Router can send exactly one packet with full header.
The mobile node records the header and notes the flow label, as does
the Access Router. After that, the Access Router strips the header and
substitutes the flow label. Similarly in the uplink direction from
the mobile node to the Access Router. If the flow label were negotiated end to
end, it might take more than one packet, but the negotiation only
needs to be done once, and not every time the mobile node moves.

Since the flow label is 20 bits, the Access Router might want to hash
the flow label to one byte rather than send the full flow label across,
since the Access Router knows the mobile node that is to get the flow.

When the mobile node moves to a new Access Router, the flow label/header
context is transferred via context transfer. The mobile node maintains
the mapping. The new Access Router performs the same stripping function, even 
though the care of address has changed, as does the mobile node. 

Note that the compressor would still be needed for UDP/RTP headers.

If one doesn't want to use the flow label, a separately computed tag
(like an MPLS label) could be used, based on the source address, but
this would have to be recomputed if the corresponding node were a mobile
node and was changing its care of address. A flow label would remain
constant.

Comments?

		jak

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 29 Mar 2001 17:20:54 -0800

Hello Carsten,

"Dr. Carsten Bormann" wrote:

> Rajeev,
> while this is only a rough overview of the information set, you might want
> to start with section 6.5 of the ROHC RTP document.  I tend to believe that
> for most applications, just transferring the static chain will be fine,
> though; this is resilient to race conditions and can simply use the data
> format already defined in section 5.7.7.
>

Ok. I agree this is a good start.

Regards,

-Rajeev

>
> One thing that needs to be defined as well is the signaling between the old
> compressor and the new decompressor (and v.v.) so they know context transfer
> is in use and contexts have been successfully transferred.  This may be
> implicit in the handover or explicitly signalled *).  This signalling may
> also be a good place to fix the apparent deficiency in ROHC that there is no
> good way to update an address in the outermost IP header (needed for Mobile
> IPv6).

> *) ROHCers: maybe we need to reserve some bit combinations for ROHC-over-X
> signalling...
>
> Gruesse, Carsten

---

From: [email-masked]
Date: Thu, 29 Mar 2001 19:36:03 -0600

Hi James,

Using the flow label (to identify a context) is certainly a good 
idea. I'm wondering if the ROHC CID (may need re-mapping during 
handover) can achieve the same goal. The former hinges on that the 
flow label is unique between the Access Router (AR) and the mobile 
node (MN) and remains constant when the MN attaches to a new AR 
(need re-negotiation if clashes with flow from other IP address?). 
The latter requires the mapping of old COA and the new one (details
unclear).

Somehow, I feel further thinking might be needed. On the other hand, 
they're not in conflict since the ROHC CID can be viewed as the 
result of hash function of the flow label. In addition, it could be 
a zero-bye CID (just for one flow) under the ROHC framework.

Br,
Zhigang

> From: ext James Kempf [mailto:[email-masked]]
> Sent: Thursday, March 29, 2001 6:15 PM
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]

---

From: [email-masked]
Date: Fri, 30 Mar 2001 09:59:13 -0600

> However, since 
> context transfer is out of scope for header compression 
> development (snip)
>  
> /L-E

Why do you say that? Context transfer requires some new
signaling between the new and old compressor (decompressor).
The logic of ROHC also needs to be amended. Do you think
all of those should not be part of the protocol and just
an implementation issue? How about interoperability?

(The emails from other people seems indicating just the opposite.)

Zhigang

---

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 30 Mar 2001 10:50:49 -0800 (PST)

Hesham,

> 	IP headers in a VOIP call, then I'll just stick to my GSM phone.

But the fact is that HMIPv6 draft is making an assumption that ROHC  is a 
pre-requisite to implement HMIPV6 support. 

So, from your above statement, it is clear that hmipv6 is only targeting
cellular systems that will have ROHC or rfc2507 HC implemented.

BTW, HMIPV6 draft talks about hierarchical networks in general, why do you
assume that ROHC will be implemented in all hierarchical networks. There
may be small  scale wireless networks which may not have header compression
at the access points.
Also, in regular netwroks, if I have a choice of saving
40 bytes, why don't I do that ?  The third mode proposal is not complex at all
and it does only destination address substitution once at MAP and once at MN, 
mobileIpv6 is doing similar mechanism at end nodes  with homeaddress option.
So may be 10-15 lines of additional code.

-Samita