Subject: RE: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration

From: [email-masked]
Date: Fri, 20 Sep 2002 10:00:40 -0500

Ajoy,

Defering the CoA configuration may result in extended tunnels
and host routes at the leaf nodes. Hence its a good reason to
configure the CoA expeditiously. And this can be accomplished
if you have advanced knowledge of handoffs (via L2 triggers).

Limiting number of signaling messages is important but is the
overhead of managing extended tunnels and host routes at edge
routers greater than a few additonal messages? Some sort of 
middle ground is required here. 
I think the applicability of the fast-handoff immediately may
well be 802.11 networks in which case we really should not be
too worried about number of messages. The implementation and
deployment experience will definitely help guide any changes
and enhancements to the protocol that would make it more 
applicable for the wide-area cellular networks. Trying to get
the protocol perfect and suitable for all kinds of networks 
that may exist in the future is difficult. The idea of extending
the baseline FMIPv6 draft for specific L2s in separate drafts
will be able to accomodate the specific needs.

-Basavaraj

> -----Original Message-----
> From: ext Singh Ajoy-ASINGH1 [mailto:[email-masked]]
> Sent: 20 September, 2002 07:49 AM
> To: 'Rajeev Koodli'; Alper E. YEGIN
> Cc: Singh Ajoy-ASINGH1; [email-masked]
> Subject: RE: [mobile-ip] Fastv6: Issue 2: Deferring new CoA
> configuration
> 
> 
> Hello Alper/Rajeev,
> I respectfully disagree with your opinion. 
> We want to design a protocol that should 
> work in present as well as future wireless technologies. 
> Otherwise, we are not designing protocol that can be 
> used in most of the cases. BTW, 
> please read RFC 3243 that seems to make good case
> for 0 byte header compression. I think some 
> of the argument will be still valid for 
> our discussions. 
> Regards,
> Ajoy
> 
> 
> PS: Alper, my concern is not ablout sending signaling message.
> But I do not want to make signaling message as time critical message.
> If we design protocol that can work without impacting the performance
> of user even if signaling messages are delayed, we should be fine.
> This is what we will get by deferring care of address configuration.  
> 
> -----Original Message-----
> From: Rajeev Koodli [mailto:[email-masked]]
> Sent: Thursday, September 19, 2002 6:55 PM
> To: Alper E. YEGIN
> Cc: Singh Ajoy-ASINGH1; [email-masked]
> Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA
> configuration
> 
> 
> 
> I tend to agree with Alper in general. We should
> assume that a link layer will accommodate IP
> address configuration! If the channel allocation
> is such that there is delay, then performance
> tuning is necessary. We cannot predicate something
> like IP address configuration (for our protocol design
> purposes) on how _each_ link layer carries frames.
> I am not saying that it is unimportant, but it has
> to be done some place else.
> 
> -Rajeev
> 
> 
> "Alper E. YEGIN" wrote:
> 
> > Ajoy,
> >
> > My point is, designing a network that can barely
> > accomodate an ongoing multimedia session and not
> > even few additional packets once in a while is not
> > practical. Therefore, "IP address conffiguration
> > messages blocking real time traffic" should not be
> > a concern here, IMHO.
> >
> > alper
> >
> > ----- Original Message -----
> > From: "Singh Ajoy-ASINGH1" <[email-masked]>
> > To: "'Alper E. YEGIN'" <[email-masked]>; "Singh 
> Ajoy-ASINGH1"
> > <[email-masked]>; "'Rajeev Koodli'" <[email-masked]>;
> > <[email-masked]>
> > Sent: Thursday, September 19, 2002 7:43 AM
> > Subject: RE: [mobile-ip] Fastv6: Issue 2: Deferring new CoA 
> configuration
> >
> > > I don't quite understand your comment. My point was to 
> avoid signaling
> > > from the critical path. MN can always send or receive 
> signaling when
> > > high bandwidth channel is allocated or when no voice frames are
> > > being sent over dedicated channel.
> > > Regards,
> > > Ajoy
> > >
> > >
> > > -----Original Message-----
> > > From: Alper E. YEGIN [mailto:[email-masked]]
> > > Sent: Wednesday, September 18, 2002 8:43 PM
> > > To: Singh Ajoy-ASINGH1; 'Rajeev Koodli'; 
> [email-masked]
> > > Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA
> > > configuration
> > >
> > >
> > >
> > >
> > > I still don't understand how we can ensure smooth
> > > operation using this dedicated channel which cannot
> > > even accomodate few additional IP packets.
> > >
> > > For example, what happens if some of those
> > > real-time packets needed to be fragmanted? Maybe this
> > > doesn;t apply to voice packets since they are small,
> > > but any larger packet can be pushed over the edge due
> > > to tunneling overhead of Mobile IP based protocols. Now
> > > you have more packets....
> > >
> > > If accumulative bandwidth is an issue, well then additional
> > > extension headers (e.g., routing header) and one or more
> > > encapsulation can consume more bandwidth than we
> > > have provisioned for the dedicated channel.
> > >
> > > Also, how does the network decide which packets can take
> > > the dedicated channel? In the presence of IPsec encryption
> > > and changing source and destionation addresses via Mobile IP,
> > > filtering of those packets is not practical.
> > >
> > > What I'm trying to say is, before 2 packets of mobility signaling,
> > > I think this system has some other problems to deal with....
> > >
> > > alper
> > >
> > >
> > >
> > >
> > > >
> > > > Ajoy, under what conditions sending few extra packets
> > > > is an issue? If we have such delicate conditions, how do
> > > > they perform when a router sends an unsolicited router
> > > > advertisement, or some other node sends a neighbor solicitation,
> > > > or user of the mobile node wants to browse the Internet
> > > > simultaneously, etc.. (many reasons to send/receive
> > > > packets at the same time...)
> > > >
> > > > Ajoy->
> > > >
> > > > This question is difficult to answer unless I use
> > > > a specific air interface technology. For example, in CDMA
> > > > 2000 access network, each mobile is allocated a low
> > > > bandwidth dedicated pipe and a high bandwidth shared
> > > > pipe. The high bandwidth pipe is shared among multiple
> > > > users for obvious reason. The high bandwidth pipe is allocated
> > > > when an MN has enough buffered data to send or receive. 
> Moreover,
> > > > the access time of this channel is very high, hence
> > > > it is not suitable for carrying any real time
> > > > voice or Fast Mobile/IP messages. Typically the shared 
> channel won't
> > > > get allocated for low bandwidth voice over IP or
> > > > say Mobile/IP signaling message. In this case, the Mobile/IP
> > > > messages will have to compete with VoIP traffic for low
> > > > bandwidth channel. On the other hand, the bulky traffic 
> (e.g., FTP)
> > > > are buffered until the high bandwidth channel is available for
> > > > communication. This is ok for non-real time traffic because
> > > > the users don't care about the buffering delay associated with
> > > > these packets. BTW, the one solution of this problem is
> > > > to allocate high bandwidth dedicated channel to each
> > > > users which is very expensive and not done so far.
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Alper E. YEGIN [mailto:[email-masked]]
> > > > Sent: Wednesday, September 18, 2002 1:54 PM
> > > > To: Singh Ajoy-ASINGH1; 'Rajeev Koodli'; 
> [email-masked]
> > > > Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA
> > > > configuration
> > > >
> > > >
> > > > > Hello Rajeev,
> > > > > I have not read all the emails exchanged about this
> > > > > issue. BTW, I would like to have the option to defer
> > > > > new care of address configuration.
> > > > > Following are a few advantages of this approach:
> > > > >
> > > > > 1.Avoid the possibility of blocking real time traffic
> > > > > by the signaling traffic.
> > > >
> > > > Ajoy, under what conditions sending few extra packets
> > > > is an issue? If we have such delicate conditions, how do
> > > > they perform when a router sends an uncolicited router
> > > > advertisement, or some other node sends a neighbor solicitation,
> > > > or user of the mobile node wants to browse the Internet
> > > > simultaneously, etc.. (many reasons to send/receive
> > > > packets at the same time...)
> > > >
> > > > alper
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > 2.Provides mechanism to remove header compression
> > > > > context transfer or re-negotiation out of critical path
> > > > > of handover. Similarly, provides mechanism to remove PPP
> > > > > context transfer or or re-negotiatio (if PPP is used)out
> > > > > of critical path of handover.
> > > > >
> > > > > If we keep context transfer as well as the handover signaling
> > > > > in the critical path of handover, I do see 
> possibility of call drop
> > > > > which will beat the purpose of fast handoff. BTW, in 
> order to support
> > > > > above feature (2,3), we need a mechanism to tunnel
> > > > > compressed IP packet or PPP frame.
> > > > >
> > > > > Regards,
> > > > > Ajoy
> > > > >
> > > > > -----Original Message-----
> > > > > From: Rajeev Koodli [mailto:[email-masked]]
> > > > > Sent: Monday, September 16, 2002 8:37 PM
> > > > > To: [email-masked]
> > > > > Subject: [mobile-ip] Fastv6: Issue 2: Deferring new 
> CoA configuration
> > > > >
> > > > >
> > > > >
> > > > > Issue: Should a Fastv6 MN be required to have the
> > > > > option of deferring its new CoA configuration until
> > > > > a "convenient" time ?
> > > > >
> > > > > Background: In version 04, a MN can defer new CoA
> > > > > configuration until it finds, for instance, suitable
> > > > > radio resources (See Section 3.5.2). This would mean
> > > > > that the MN would be required to suppress RS and
> > > > > Router Advertisement every time it changes access routers
> > > > > until a convenient time. This also means the previous CoA
> > > > > would potentially have to be supported across a series of
> > > > > access routers for arbitrary periods of time.
> > > > >
> > > > > The proposal is to remove this restriction on new CoA
> > > > > configuration.
> > > > >
> > > > > Please respond
> > > > > - YES if you agree to remove the restriction
> > > > >     of deferring new CoA
> > > > > - NO otherwise. Indicate a brief reason
> > > > >
> > > > > Thanks,
> > > > >
> > > > > -Rajeev
> > > > >
> > > > >
> > > >
> > >
>

---

From: "James Kempf" <[email-masked]>
Date: Fri, 20 Sep 2002 10:13:56 -0700

Raj,

> middle ground is required here.

There is no need to have extended tunnels. The 04 draft describes a 3 party
tunnel handover protocol that does not require tunnel chaining. We've
implemented this protocol, and it works fine (i.e. we have running code). 3
party handover accommodates many possible applications, including the ones that
Ajoy has mentioned.

The basic design philosophy should be for the network to the support MN choice
in when it configures its CoA. Mobile IP has always left the ultimate decision
about when to configure the CoA with the MN, though up until the fast handover
work, it has not included any network support for explicitly fixing the short
term routing failure caused by handover. Now that we are putting in that
support, I think we should make sure that we maintain the same basic design
philosophy with respect to CoA configuration, even if it requires additional
support in the network side. Of course, the spec can make recommendations about
what is most appropriate.

> well be 802.11 networks

I'm not so sure. In a recent paper by Bill Aurbaugh, U. Maryland, he measured L2
blackout times of 120-400 ms for 802.11 handover in infrastructure mode. With
those kinds of L2 blackout times, the Mobile IP handover will be in the noise.
It may be necessary to put the card and APs into infrastructureless mode, and
actually define a complete IP access point protocol rather than use the 802.11
infrastructure mode handover. I think infrastructureless handover is about 5 ms,
but there are definitely questions about whether the host can handle beacon
management  without firmware support when there are lots of hosts in the cell.

> in which case we really should not be
> too worried about number of messages.

I strongly disagree with this. There is no QoS on 802.11 currently, so the MIP
signaling messages will end up contenting with all others. Enough MNs in a cell
and the MIP signaling could be delayed by link contention. Just because this
link protocol has 802 in its name doesn't mean that it behaves like wired
Ethernet.

Also, as a general design principle, I think it is a good idea to look for
protocols that are not chatty. IKE is an example. Now, the IKE WG is looking at
"son of IKE" because there are perceived to be too many messages in IKE main
mode (among other problems). I'd prefer not to have to look at "son of FMIPv6"
in a couple years, it is timeconsuming enough to have to do it the first time.

>The implementation and

I certainly agree that having drafts for specific L2s will ground the protocol
in reality, but I disagree about cellular application being in the far future. I
think it would be wise to apply the same exercise currently being done with
802.11 to cellular, 3GPP2 would be good. As you know, there are some important
differences between cellular and wireless LAN protocols that could end up
influencing the design. There are a number of members of the MIP WG who have
expertiese in cdma2000 that could undertake this exercise.

Another possible alternative would be to halt the current work on a generalized
fast handover protocol, or take it to informational or experimental, as is being
done with the FMIPv4 work, and focus instead on standardizing fast handover for
particular link layers. I'm not sure I am in favor of this, but I really do want
to avoid speculative talk about "separate signaling channels for Mobile IP
signaling" and "not worring about low bandwidth channels because, in the future,
everybody will have a 1 Mbps dedicated link." This will simply not be the case.
Even with 802.11, hosts get only a percentage of the bandwidth depending on the
number of hosts in the cell.

            jak

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Fri, 20 Sep 2002 14:19:04 -0700

> those kinds of L2 blackout times, the Mobile IP handover will be in the
noise.

It seems like we are omitting the DAD cost here. Regular Mobile IP requires
DAD on the new link, and that can cost even more than the L2 handover
itself.
Unless IP address configuration is taken care of somehow, or until if and
when
optimized DAD solutions are developed, regular Mobile IP handover over
802.11 is a concern.

> link protocol has 802 in its name doesn't mean that it behaves like wired

The MIP signaling will be on the same ship with the rest of the traffic,
including
the real-time traffic we are trying to save. So, any QoS solution will help
both the signaling and data, and lack of it will hurt both.

alper