[MIP-QOS] Draft version of MIP QoS Requirements Draft

["ext Michael Thomas" <mat@cisco.com>]

One general comment: this is very Intserv-centric. 
I think we need to explore the diffserv side a lot 
more too, especially with discovery and policy. 
 
Also to Phil: what keeps striking me as I comment
on these is that we have a lot of pretty vague
requirements documented here, but no problems to
show why the requirements are necessary. If we'd
already been through that endlessly on the list,
I'd feel a lot more comfortable, but I don't think
we've done that exercise. Wouldn't it be useful to
have some sort of problem statement too?
 
I have some inline comments too: 

Hemant.Chaskar@nokia.com writes:
 > IETF Mobile IP Working Group                          Hemant Chaskar
 > INTERNET-DRAFT                                                Editor
 > Expires: November 2001                         Nokia Research Center

  [...]

 >    2. Localize the QoS (re)programming to the affected parts of the
 >    packet path in the network:
 > 
 >    In many cases, handover affects only a small segment of the
 >    end-to-end path of MN's packet stream. Then, the QoS mechanism
 >    MUST limit the extent of QoS (re)programming to the affected
 >    segment of the end-to-end path only. This will reduce the volume
 >    of QoS signaling traffic (if any) as well as decrease the QoS
 >    interruption. Of course, if the end-to-end path changes at large
 >    after handover, the programming for QoS forwarding MAY be done on
 >    end-to-end scale.

  As stated, RSVP already does this. This doesn't
  quite capture what the real problem is with mobile
  IP which mainly centers around that the filter
  specs would need to change when the CoA is changed.
  I know I'm not being especially helpful with what
  should be there, but I think we need to be more
  explicit about what the current crop of problems
  are with RSVP when it's paired with MIP than just
  saying that RSVP needs to converge locally.

  One thing that I don't see here is the problem
  with route damping that I've brought up on a number
  of occassions. The 2 second suggested hold down
  time is going to wreak havoc with mobility (and
  not just MIP).
 
 >    3. Releasing after handover the QoS state (if any) along the old
 >    packet path: 
 > 
 >    The QoS mechanism MUST provide some means (explicit or
 >    timer-based) to release any QoS state along the packet path before
 >    handover, that is not required after handover.

   RSVP already does this with soft state and TEAR.

 > 3.2 Interoperability requirements
 > 
 >    1. Interoperability with mobility protocols:
 > 
 >    The QoS mechanism MUST coexist with other mobility protocols
 >    related to Mobile IP that are already defined or that may be
 >    standardized in future in the Mobile IP working group. Examples
 >    are Fast Handover [4, 5], Regional Registrations [6], Hierarchical
 >    MIPv6 [7], Context Transfer [8] and Reverse Tunneling [9]. It MUST
 >    be possible to use the QoS solution with or without the
 >    above protocols.

   I think it's our job to say what that means. As 
   in, if there are additional requirements
   because of [A-Z]MIP, we need to enumerate them.

 >    2. Interoperability with heterogeneous QoS paradigms:

   Lose paradigms... it's so 90's marketspeak :-)

 >    The new end-to-end path of MN's packet stream may encounter
 >    network domains employing a variety of QoS paradigms, such as
 >    IntServ, DiffServ and MPLS. The QoS mechanism for Mobile IP MUST
 >    be able to program appropriate QoS forwarding treatment for the
 >    MN's packet stream in these QoS-heterogeneous network domains in
 >    the end-to-end path.

   I understand (and agree) what you mean, but
   If I were a protocol developer given this 
   requirement, I wouldn't know what would
   satisfy the requirement. Again, I think we
   need to be more specific. Also: this sort
   of strikes me more as a SEAMOBY CT requirement
   than a MIP requirement. When moving without 
   CT, you'd expect that the MN would re-instigate
   QoS on the new AR and that it would somehow
   know what to do.

   Maybe one of the requirements for QoS/MIP is
   that the RA's be able to inform the MN what
   QoS policies/treatments are available at 
   registration time? If so, this is half in
   MIP (mipv4) and half in IPNG which really
   makes this a mess.

 >    Further, it will be a useful feature of the QoS solution if it
 >    does not require the MN to have an explicit knowledge of the QoS
 >    mechanism deployed in the access network as well. This is because
 >    there may be scenarios where the MN initiates a QoS-sensitive call
 >    when it is attached to, say, DiffServ access network, and is later
 >    handed over to, say, IntServ access network.

   Er, RSVP requires that the MN participate since
   it's end to end. I really don't understand what
   this requirement is requiring.

 > 3.4 Miscellaneous requirements
 > 
 >    1. After MN undergoes handover from one access router to another,
 >    potentially, there could be multiple paths over which MN's packet
 >    may propagate. Examples of these path are: route-optimized path
 >    between the MN and its CN, triangle route via Home Agent (HA),
 >    temporary tunnel between old and new access routers etc. A QoS
 >    mechanism SHOULD be able to support QoS along the different
 >    potential paths. 

   I believe that this is already taken care of
   by RSVP and/or network design. Basically,
   anything that involves topology changes is
   something that RSVP can do natively. Much
   more interesting is whether they require end
   to end trips and/or meet timing requirements.
   This is fertile ground for new requirements.

 >    2. The QoS mechanism MAY provide some information to the link
 >    layers for them to support the required QoS. This is essentially a
 >    wireless link-specific feature, but a vast number of devices using
 >    Mobile IP will indeed be connected to the Internet via wireless
 >    links. An example scenario will be two UDP streams requiring
 >    different levels of error protection at the link layer. For such
 >    cases, an IP-layer QoS mechanism may indicate some generic
 >    parameters such as acceptable IP packet loss rate to link layers.

   I believe that this is also supported with RSVP
   and the mappings that the issll folks are
   working on. If there's something missing, we'll
   need to be more specific.

 > 3.5. Obvious requirements
 > 
 >    The QoS solution for Mobile IP MUST satisfy obvious requirements
 >    such as scalability, security, conservation of wireless bandwidth,
 >    low processing overhead on mobile terminals, providing hooks for
 >    authorization and accounting, and robustness against failures of
 >    any Mobile IP-specific QoS components in the network.

   I think these need to be fleshed out more. How
   do I determine, say, if I've conserved enough
   wireless bandwidth? What's satisfies
   scaleability?

   One thing I've been meaning to bring up is that
   the current RSVP policy RFC's (2749, 2752) as
   far as I can tell are extremely vague about 
   how you do cross realm authentication/authorization.
   While it's true that wireline QoS may need to
   cross AD's, mobile wireless *really* begs the
   question, and adds new requirements that policy
   be able to contend with mobile nodes which are
   visiting. I'm just not sure how to write a 
   "please tell us how cross realm policy works"
   requirement though.

		Mike