Subject: RE: [mobile-ip] Final Agenda for Mobile IP WG meeting at IETF50

From: "Hemant Chaskar" <[email-masked]>
Date: Thu, 15 Mar 2001 00:58:05

The 01 version of the draft (draft-chaskar-mobileip-qos-01.txt) explicitly 
points out the performance problems with RSVP, when it is used in the mobile 
environment. The 00 version of the draft was presented in SD meeting. A 
question that was raised during that meeting was - how and why should it be 
different from RSVP? 01 version answers that question, and clearly shows 
that RSVP introduces unacceptable latency in the QoS programming after 
handover. In other words, the 01 version addresses what was not explicit in 
the 00 version, thus trying to clarify the situation from the performance 
angle. It will be apparent on reading the draft that a whole new section on 
the performance analysis of the two approaches (RSVP vs the hop-by-hop QoS 
object approach) is added in the 01 version. Thus, it is an appropriate 
sequel of 00 version discussion.

Also, the RSVP approach studied in the draft (for the case when CoA changes) 
in the SeaMoby WG (draft-thomas-seamoby-rsvp-analysis-00.txt) is not immune 
to the above performance problem. The author of that draft has observed this 
phenomenon as well.

>From the implementation standpoint, the draft 
(draft-chaskar-mobileip-qos-01.txt) is for Mobile IPv6. IPv6 deployment has 
not already taken place at the global Internet scale. Deployment of v6 
provides a clear transition phase for the implementation of new and better 
solutions. Thus, I do not see any big issue with implementation of CN's and 
core routers as far as the IPv6 deployment is considered.

Hemant

>From: Michael Thomas <[email-masked]>
>Reply-To: [email-masked]
>To: <[email-masked]>
>CC: [email-masked], [email-masked]
>Subject: RE: [mobile-ip] Final Agenda for Mobile IP WG meeting at IETF50
>Date: Wed, 14 Mar 2001 11:04:43 -0800 (PST)
>
>I understand that, but this draft in particular is
>positing a completely different way to perform
>signaled QoS admission control which has global
>implications: CN's and interior routers would need
>to implement this as well.
>
>As you may know, I've spent a fair amount of time
>trying to figure out what the implications of our
>current signaled QoS admission control scheme --
>RSVP -- are with MIP and I can tell you as a very
>quick summary that positing a completely different
>signaling scheme is *far* too premature. It would
>be much, much better to analyze what the current
>state of affairs is and compare that to MIP
>requirements before we decide whether a specific
>solution is in order. In fact, even if it is, I
>cannot imagine that the MIP WG is the right place
>to pursue this.
>
>I have volunteered to discuss my analysis (draft-
>thomas-seamoby-rsvp-analysis-00) and will do so
>again at this point, but even if you don't take me
>up on this, I cannot see what will be productive
>about discussing this draft for the second IETF
>in a row: all of the same arguments of scope
>and wholesale reinvention apply.
>
>	  Mike
>
>[email-masked] writes:
>  >
>  > Michael,
>  >
>  > > Can I ask why we are discussing solution space for QoS
>  > > when the requirements aren't even known?
>  >
>  > The requirements may not be explicitly stated as such.  The 
>requirements
>  > for QoS from a Mobile IP perspective are as follows:
>  >
>  > 1. If QoS has been established for a session between an MN and CN, how 
>do
>  > you
>  >     deal with it when the MN changes it's point of attachment, and as a
>  > result the path of the
>  >     packet flow changes
>  > 2. What are the implications on QoS for a session w.r.t fast handoffs.
>  > 3. More? I am not sure.
>  >
>  > -Basavaraj
>  >
>  > >
>  > > [email-masked] writes:
>  > >  >
>  > >  > Final agenda for the Mobile IP WG meeting at IETF50
>  > >  >
>  > >  > Thursday March 22nd - 9:00 AM - 11.30 AM
>  > >  > ----------------------------------------
>  > >  >
>  > >  > Agenda bashing					5 Mins
>  > >  > WG Doc Status					5 Mins
>  > >  >
>  > >  > MIP at Connectathon - Report			5 Mins
>  > >  >  - Alper Yegin
>  > >  >
>  > >  > Mobile IPv6 Discussion				30 Mins
>  > >  >  - Issues related to using IPSec
>  > >  >    for binding updates   Jeff Schiller 10 Mins
>  > >  >  - Discussion of draft-bradner-pbk-frame-00.txt
>  > >  >    Jeff Schiller 5 Mins
>  > >  >  - Discussion	 15 Mins
>  > >  >
>  > >  > Handoffs - Panel discussion			50 Mins
>  > >  >  - V6 handoff design team 20 Mins
>  > >  >  - V4 handoff design team 20 Mins
>  > >  >  - (draft-gwon-mobileip-l3mp-mipv4-00.txt)
>  > >  >    Youngjune Gwon 10 Mins
>  > >  >
>  > >  > Hierarchical Mobility Schemes			15 Mins
>  > >  >  - HMIPv6 (draft-ietf-mobileip-hmipv6-02.txt)
>  > >  >    Hesham Soliman 8 Mins
>  > >  >  - Comparison/Discussion with
>  > >  >    draft-malinen-mobileip-regreg6-01.txt 7 Mins
>  > >  >
>  > >  > Dynamic configuration of Mobile hosts		15 Mins
>  > >  >  - Sandy Thuel
>  > >  >    draft-thuel-mobileip-tt-01.txt 8 Mins
>  > >  >  - Steve Glass
>  > >  >    draft-glass-mobileip-agent-dhcp-proxy-01.txt 7 Mins
>  > >  >
>  > >  > QoS Discussion					10 Mins
>  > >  >  - draft-chaskar-mobileip-qos-01.txt
>  > >  >    Hemant Chaskar
>  > >  >
>  > >  > WG Charter review				10 Mins
>  > >  >
>  > >  >
>  > >  >
>  > >

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

---

From: Michael Thomas <[email-masked]>
Date: Wed, 14 Mar 2001 18:04:52 -0800 (PST)

Well, I'm the author of that draft. Even though
the draft points out a number of deficiencies with
RSVP as it currently stands, that should not give
the MIP WG free reign to create a new QoS
admission control protocol which is mainly aimed
at solving the narrow niche of mobile IP and
nothing else, and considering little else .

Question to the AD's and Chairs: does MIP WG
include in its charter the task of recreating RSVP
just because at first blush it's not clear how
RSVP will interact with MIP? I see that MIP has in
its charter that it needs to *consider* Intserv
and Diffserv QoS, but that is surely not the same
as free license to recreate QoS protocols and
semantics. If not, I suggest that this is an
inappropriate use of this time slot for QoS
discussions.

	  Mike

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Thu, 15 Mar 2001 12:44:02 -0500

It would probably be more helpful if that discussion would also first
take place in the next-generation signaling BOF at the IETF meeting.
There is a special list for the discussion of signaling issues in a
broader context, not just MIP. 

See http://lists.cs.columbia.edu/mailman/listinfo/siglite

(This activity is coordinated with the respective ADs, although they are
obviously not responsible for the opinions presented on the mailing
list...)
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Fred Baker <[email-masked]>
Date: Sun, 18 Mar 2001 10:35:18 -0800

At 06:04 PM 3/14/2001 -0800, Michael Thomas wrote:
>RSVP will interact with MIP?

Dumb question of the month - would RSVP not follow the source/destination 
routes involved, and potentially impose a reservation for the tunnel in 
question? The real problems should relate to service surrounding a change 
in COA or FA; one presumably is forced to trigger a reservation 
installation for the new route which may involve a temporary disruption 
surrounding a route which is already in place. One would like to re-use the 
reservation in place for the old to support the new route, up to the point 
where the two routes differ.

This is not dissimilar to the behavior of RSVP-TE for MPLS, in switching 
over between bandwidth-guaranteed routes. I should think we could re-use 
the concepts applied there.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 19 Mar 2001 15:07:35 -0800 (PST)

> where the two routes differ.

   The main problem is that the join point for the
   repaired reservation in the MN->CN direction is,
   in fact, the CN itself. Ie, not good. Life would
   be much better if the filter spec didn't need to
   change (which a changed CoA seems to imply). This
   could be done either by using the Home Address
   destination option as the source address filter,
   which would probably be pretty sucky for routers
   or by placing the home address in the source address
   which has RPF implications. 

   One other consideration which needs to be pointed
   out here is what is the implication of wireline
   (fixed) hosts behind a mobile router. Are they
   aware of their mobility or not? If not, they 
   will cluelessly put their home address into the
   source address tickling the RPF problem. Is this
   enough to tilt the balance? I don't know.

   I don't know whether you scanned my RSVP/MIP
   analysis draft, but there are a number of 
   considerations like these. Suffice it to say,
   I have a lot more questions than answers.

	    Mike

---

From: Fred Baker <[email-masked]>
Date: Mon, 19 Mar 2001 17:14:53 -0600

>    I have a lot more questions than answers.

I have not. What is its identifier?