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

From: "Mohamed Khalil" <[email-masked]>
Date: Tue, 17 Sep 2002 13:21:17 -0500

NO, the MN should obtain a nCOA immediately without any delay. Giving the
choice for the MN to defer constructing a new COA will complicate the
protocol unnecessarily. Also, it is undesirable to allow the MN to use the
oCOA for longer time  than it is necessary.

-----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: "Mohamed Khalil" <[email-masked]>
Date: Tue, 17 Sep 2002 15:00:53 -0500

I have voted mistakenly by NO, it should be YES. My vote is to remove this
feature of defering nCOA..  I hope that was clear from the reasons I
mentioned below.

-----Original Message----- 
From: Rajeev Koodli [mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Monday, September 16, 2002 8:37 PM 
To: [email-masked] 
Subject: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration 

Please respond 

Thanks, 

-Rajeev

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Fri, 20 Sep 2002 07:48:59 -0500

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
> > 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
> >
> >
> > 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.
> > >
> > >
> > > 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
> > > >
> > > > would potentially have to be supported across a series of
> > > > access routers for arbitrary periods of time.
> > > >

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 20 Sep 2002 15:37:40 -0700

n
> 
> >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.
> >
> 
> 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.
> 
This looks like a good idea. What does fast really mean ? 
Does it mean that it is faster than base spec ?  How does one really
decide that FMIPv6 is fast ? e.g. do some simulation on specific
link layer and show it is fast ? And how do you know that it is fast
for all other link layers ? Perhaps it might be possible to
address some basic issues like DAD etc. in base spec and do link
specific things in the link specific draft.

-mohan

>             jak

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Fri, 20 Sep 2002 17:49:29 -0500

Hello Basavraj,
Sorry for late reply. Lately I have been too busy 
to follow Fast handoff discussion. Please
find my inline replies to your comments.
Regards,
Ajoy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, September 20, 2002 10:01 AM
To: Ajoy Singh; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mobile-ip] Fastv6: Issue 2: Deferring new CoA
configuration

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).

AJOY-> But if we do not provide an option to defer care of address 
configuration, we end up in a situation where CoA must be performed 
in given time limit. This looks like imposing hard real time 
constraint on the best effort IP. BTW, I think this goes against the 
design principle of IP.  Please correct me if I misunderstood anything. 
On the other hand, due to advancements in the speed and processing
power of routing hardware, probably adding some 
extra host routes at the access routers may not be a big issue.
Anyhow, I would like to have an expert opinion about my assertions.

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 additional messages? Some sort of 
middle ground is required here. 

AJOY-> More than reducing the signaling messages, my priority is
to eliminate the signaling messages from the critical path of 
handoff. This can done by letting MN to decide the timing 
of care of address assignment upon the completion of handoff. 

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. 

AJOY-> I would not make such an assumption. Rather I would like to 
leave this upon the discretion of wireless vendors.

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. 

AJOY-> I agree. I am sure we will find more issues 
and further scopes for improvements when these
protocols get deployed in the field. But anyhow, 
we should not ignore the well known facts of the 
wide area access network such as low bandwidth
and high RTT. This is not going to change because 
of the deployment of fast handoff. 

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 accommodate the specific needs.

AJOY-> Yes, it can. But won't this beat the purpose of 
standardization. But I do agree some non-standard
optimization must be performed to accommodate the various
air interface technologies.  

-Basavaraj

> From: ext Singh Ajoy-ASINGH1 [mailto:[email-masked]]
> Sent: 20 September, 2002 07:49 AM
> To: 'Rajeev Koodli'; Alper E. YEGIN

---

From: Phillip Neumiller <[email-masked]>
Date: Wed, 25 Sep 2002 15:06:55 -0400

Hi James,

Having played around with a few commercial implementations of MIP,
all of them I have touch so far, do use L2 triggers!  Its just a 
matter of time before the concept is no longer so foreign to 
everybody.  I am confident that eventually people will see the 
value of cross layer design for MIP, QoS, security, etc.

Best regards,

Phil

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Wednesday, September 25, 2002 2:15 PM
To: Alper E. YEGIN; Behcet Sarikaya
Cc: Hesham Soliman (EAB); 'Singh Ajoy-ASINGH1 '; ''Rajeev Koodli' ';
[email-masked]
Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA
configuration

Alper,

I agree this case is important. It would help with 802.11 handover, for
example,
to have such a protocol. Unfortunately, some people view this as an L2
functionality. So it seems we can't even get agreement about the need for a
protocol, much less a collection of abstractions to expose L2 functionality
to
L3.

                jak

----- Original Message -----
From: "Alper E. YEGIN" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Behcet Sarikaya"
<[email-masked]>
Cc: "Hesham Soliman (EAB)" <[email-masked]>; "'Singh
Ajoy-ASINGH1 '" <[email-masked]>; "''Rajeev Koodli' '"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, September 24, 2002 8:44 PM
Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration

> >
> > Behcet,
> >
> > Unfortuantely, the L2 triggers work has not gotten a lot of traction in
> the
> > IETF. Outside of the mobile wireless arena, people are proposing using
> SNMP for
> > it, which completely misses the point. Others have complained that it is
> really
> > a specification for what goes on inside a box and has nothing to do with
> > observing protocol on the wire.
>
> With some of the discussions going on, I can see some people might
> think this is the only way triggers are generated and consumed. But
> don't they consider the case where an access point (i.e., wired2wireless
> bridge that can produce the trigger) is separated from the access
> router (i.e., the consumer of the triggers)? How is this case
neglected...?
>
> > There is also a question about what usefulness
> > it would have ultimately, since link layer designers generally do their
> own
> > thing. So unless there is some interest on the part of groups dealing
with
> > mobile and wireless to take on the work, it seems likely that it will
not
> be
> > continued.
> > From: "Behcet Sarikaya" <[email-masked]>
> > To: "James Kempf" <[email-masked]>
> > Cc: "Hesham Soliman (EAB)" <[email-masked]>; "''Alper E.
> YEGIN'
> > '" <[email-masked]>; "'Singh Ajoy-ASINGH1 '"
> <[email-masked]>;
> > "''Rajeev Koodli' '" <[email-masked]>;
> > Sent: Monday, September 23, 2002 9:53 AM
configuration
> >
> >
> > > Jim,
> > >   The problem in public cellular network links vis-a-vis Mobile IP is
> > > that IP starts at GGSN/PDSN which is a core network node and
everything
> > > below SGSN, PCF, UTRAN is the link layer. As such the cell size for
MIP
> > > becomes large and thus the layer 3  handoffs are not so frequent.
There
> > > are other things such as GTP, let's not talk about them.
> > >   I agree that we should not develop drafts for each wireless link.
What
> > > is really needed is the definition of an abstract wireless link layer
> > > interactions and making FMIPv6 protocol to work on it.
> > >   I think that your idea of L2 triggers (was it initiated by you?) is
a
> > > good starting point, however I find the term L2 trigger to be misnomer
> > > for this, maybe we should call it the wireless link layer indications.
> > > Maybe these indications must be revisited and redefined in order to
use
> > > them effectively together with a handover protocol. The protocol could
> > > be defined such a way that the wireless link layer indications become
> > > the API for FMIPv6.
> > >   The above could be a way out of FMIPv6 being defined for a single
> link.
> > > My 2 euro cents.
> > > Regards,
> > >
> > >
> > > James Kempf wrote:
> > >
> > > >>UMTS people are defining different types of signalling
> > > >>channels to accomodate SIP signalling for example. This
> > > >>can be reused, why not?
> > > >>
> > > >>
> > > >>
> > > >
> > > >If the channels are available and 3GPP is can be convinced to get rid
> of GPRS
> > > >and use Mobile IP, why not? :-) Maybe we could also convince them to
do
> true
> > > >make-before-break, like Flarion's flash-OFDM, so that a special fast
> handover
> > > >protocol wasn't necessary.
> > > >
> > > >To me, what this argues for is standardizing drafts that specify how
to
> do
> > fast
> > > >handover on specific link layers. Maybe there is too much diversity
in
> how
> > > >handover is done to write an optimization draft for a generic fast
> handover
> > > >protocol.
> > > >
> > > >Alternatively, perhaps we could section the fast handover draft into
> > techniques
> > > >(anticipated care of address change, tunnel-based routing fixup) that
> could
> > be
> > > >applied to specific link layers with their own particular signaling.
> This is
> > > >somewhat how we did the FMIPv4 draft.
> > > >
> > > >            jak
> > > >
> > > >
> > > >
> > >
> > > --
> > > Behcet
> > >
> > >
> > >
> >
> >
>
>
****************************************************************************
This e-mail is intended only for the addressee named above and may contain
confidential, proprietary or privileged information. If you are not the
named addressee or the person responsible for delivering the message to the
named addressee, please inform us promptly by reply e-mail, then delete the
e-mail and destroy any printed copy. The contents should not be disclosed to
anyone and no copies should be made. We take reasonable precautions to
ensure that our emails are virus free. However we accept no responsibility
for any virus transmitted by us and recommend that you subject any incoming
e-mail to your own virus checking procedures.