Subject: Re: [mobile-ip] QoS Work Item

From: "Hemant Chaskar" <[email-masked]>
Date: Fri, 30 Mar 2001 19:45:10

>
>Rajeev Koodli writes:
>  > Hello Gabriel,
>  >
>  > I did make my 3 minute presentation. FYI, following were the key 
>points.
>  >
>  > 1. Any mobility-aware signaling protocol must be able to limit the
>  > extent of signaling to only those nodes (in the packet stream path)
>  > affected by mobility.
>
>    This is a tautology though. I believe that the
>    desirable characteristic is that the QoS
>    reestablishment converges locally. If we need
>    to go clear back to the CN (which also fits
>    your definition), speed of light considerations
>    may produce unacceptible results.

I disagree with this speed of light consideration. Speed of light 
"limitation" applies to both signaling packet and data packet. So a smart 
signaling scheme will put QoS signaling trigger before any data packet to 
overcome the speed of light or satellite propagation delay limitation. This 
is exactly why we cannot live with schemes that involve one round-trip 
latency in QoS programming. However, it is definitely possible to achieve 
fast response time even if we need to go clear back to the CN, I just 
describe how!

>
>  > 2. It must be able to provide fast response time. This includes how
>  > quickly the protocol is able to detect that the mobile node has moved,
>  > as well as the how fast the protocol itself is.
>
>    I'll just throw out here that damping
>    mechanisms for route flapping are going
>    to be problem.

What is the probability that route flapping happens in the end-to-end path 
upon every handover? Also, modern techniques such as MPLS will greatly 
reduce route flapping. In modern QoS mechanisms such as DiffServ and MPLS, 
QoS signaling scheme will be insensetive to intra-domain route flapping. It 
is safe to assume that the ingress and egress routers of an intermediate 
network domain in the end-to-end path remain constant. So, it looks to me 
that fast signaling is still doable.

>
>  > 3. It should be able to make use of intrinsic IP mobility signaling.
>
>    This is a huge leap. In fact as it currently
>    stands, there is no need for a mobile to have
>    any mobility signaling local to its attachment
>    point. That, if anything, argues for just the
>    opposite: we should not explicitly link QoS
>    signaling to mobility signaling.
>
>		Mike

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

---

From: Michael Thomas <[email-masked]>
Date: Fri, 30 Mar 2001 12:44:57 -0800 (PST)

> fast response time even if we need to go clear back to the CN, I just 

   We've been through this before. Installing QoS
   state is always slower than forwarding. You have
   a built in race condition.

 > reduce route flapping. 

   Tell me: how do, at some interior node in the
   network, differentiate a "good" topology
   change (read: does not require flap protection)
   from a "bad" topology change (ie, requires
   damping)?

 > In modern QoS mechanisms such as DiffServ and MPLS, 
 > QoS signaling scheme will be insensetive to
 > intra-domain route flapping. 

   That's a pretty bold statement. Your sources for
   that are, what?

 > It 

   Um, no. Not by a long shot. This is trivial:
   within the same provider, I move from one AS to
   another AS communicating to another AS. My
   egress/ingress to the new AS will change. In
   fact, the paths may be arbitrarily different.

	     Mike

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 30 Mar 2001 14:03:53 -0800

> >    signaling to mobility signaling.

I don't follow you. Perhaps what I said was unclear. I said a mobile should be
able to make use of the natural point in time that IP detects mobility in order
to trigger and expedite the signaling process. I guess you are familiar with
our draft: there we make use of mobile IP signaling. What is this got to do
with a MN signaling to its local attachment point as you describe above ?

Regards,

-Rajeev