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

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

Hemant.Chaskar@nokia.com writes:
 > 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.
 > 
 > [HC] What is that I have said in the draft to make it IntServ centric?

   Well, that's how it reads to me. For example,
   one way to do diffserv is to statically
   provision an SLA for certain traffic flows
   (<= 5-tuple based, code point based, etc) in
   the access router and police to that SLA. In
   the wireline world, that may mean changing the
   router's config script. Mobility begs the 
   scalability question there. As in, it's not
   likely to be a scalable solution. So the
   question is, how can we make diffserv networks
   friendly to mobile nodes? What are the
   requirements? I think there's quite a bit
   of ground to cover here, since it may impact
   COPS-PR, AAA, signaled diffserv, etc. 

 > Actually, I have been careful even not to use the word "QoS signaling" and
 > have stuck to the wording "QoS mechanism" instead, so as to avoid even
 > indirect reference to IntServ. 

   Actually, I think that direct reference rather than
   oblique reference where appropriate is more concise.
   RSVP is the IETF control plane signaling that we have
   today, so if there are specific difficulties with it,
   we should point them out. Since we're not the ones 
   ultimately who will decide whether to create a new
   protocol, revamp RSVP, both or neither, it really
   doesn't hurt to just list the problems with what
   we currently have to work with. The QoS folks will
   ultimately decide whether they are structural or
   band-aid kinds of problems.

 > 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?
 > 
 > [HC] It is very difficult to go in more details because details imply
 > solution to some extent. Don't you think so?

   I'm just looking at this from the point of
   view of somebody who understands QoS, but
   doesn't have a very good grasp of MIP. Since
   I've been through this exercise myself, I can
   state pretty confidently that some explaination
   of the problems are necessary before they will
   buy into any new requirements :-)

 > [HC] Also, before I go over inline comments, I would like to point out that
 > if you are suggesting (in the inline comments) that RSVP does this all, then
 > that's great. If you can prove that RSVP satisfies all these requirements,
 > RSVP is the QoS protocol for MIP. I have nothing against RSVP.

   No, I'm not saying that RSVP solves all of the
   problems. I'm just saying that we shouldn't put
   requirements in here that are not actual
   problems because it weakens the requirements
   statement. That's why I say that we need to
   be more specific. Marc's mail may be a good
   example of something that may be a deficiency
   with the current RSVP TEAR's, the damping I've
   brought up is another.

 >   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).
 > 
 > [HC] As you have said this is not going to wreak just MIP, but is a general
 > problem. Hence, it may be outside the scope of this draft. Also, some of the
 > route damping may be taken care of internally by the QoS schemes, e.g., MPLS
 > restoration.

   I don't think so: the hold down time is to
   prevent flapping. MIP's topology changes are
   purposeful whereas RSVP expected them to be due
   to link failures, and transients. This is new,
   as far as I can tell.

 >  > 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.
 > 
 > [HC] It means that it should not happen that the QoS solution fails if fast
 > handover is used or context transfer is used or regional registration is
 > used with basic mobile IP. On the other hand, QoS solution may make use of
 > the above complementary mobility protocols for optimizations, but at the
 > same time it cannot fail if they are not used.

   Well, I think we need to define "fail". With 
   FMIP, for example, if you did nothing the
   packet would be forwarded to the old AR, and
   potentially be tunneled through the new AR with
   best effort QoS. Is this a failure? That's not
   how the QoS folks will view this: you haven't
   done anything to reestablish QoS on that path
   after all. Thus if there's a problem or
   inadequacy with doing that (ie, doesn't meet
   "fast" fast enough), we need to be explicit
   with what the actual problem is, and what the
   new requirements are.

 >    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.
 > 
 > [HC] I will try to elaborate on it in the draft. The essence is that, if the
 > QoS scheme can be generic enough that the mobile node does not need to know
 > about the details of the network side QoS, rather only know what it wants
 > from the network. It will be desirable if the network nodes can use the
 > information provided by the mobile node in a way that is consistent with the
 > QoS scheme that their network uses. 

   Actually, I think that we are actually fairly
   close to being able to accommodate this. For
   example, there is a new RFC which allows the
   routers to tell the host which DSCP to use
   via RSVP (ie, the exchage is: "I want x
   bandwidth to Joe" -> "OK, use DSCP 6"). This
   MAY be sufficient to do what you're getting at,
   but I'm not sure. In any case, we should
   probably figure out whether there are any
   new problems/requirements.

> This way, mobile node does not have to
 > first check what the QoS specification is that the AR understands before
 > handing over. For example, suppose there is a QoS scheme where MN marks DSCP
 > on the packets. Now it is handed over from DiffServ access to IntServ
 > access. In the above scheme, new AR needs to tell MN to use RSVP signaling
 > after handover. DSCPs won't work in the new access network. Same will occur
 > from IntServ to DiffServ handover. DiffServ access network will transport
 > RSVP messages transparently and consequently cannot provide any QoS. So now
 > MN will need to stop RSVP and start marking DSCP again.

   Right, but I think we need to first determine
   what the requirements of static diffserv is
   for MIP (indeed, whether it even makes any
   sense to do anything at all).

 >    Er, RSVP requires that the MN participate since
 >    it's end to end. I really don't understand what
 >    this requirement is requiring.
 > 
 > [HC] If you think that RSVP satisfies these requirements then RSVP is the
 > protocol for MIP. I have nothing against RSVP. At the same time, I cannot
 > directly see how RSVP satisfies all  these requirements. So, I will look
 > forward to your draft in NSIS.

   No, I'm not saying that, I'm saying that I
   don't understand what that paragraph is
   requiring.

   Also: I'm just the messanger here. If there
   are problems and/or shortcomings of the RSVP
   signaling plane, we need to be a lot more 
   specific because the QoS folks will just 
   dismiss them as being uninformed, thereby
   throwing the baby out with the bath water.

 >    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?
 > 
 > [HC] Generic specification of these requirements is next to impossible. It
 > is a job of protocol designer to evaluate his protocol and give the numbers
 > you are asking for. 

   I'm not asking for numbers, I'm asking how they
   would know if they've satisfied the
   requirement. For example, how much is too much
   signaling load? RSVP, provides most (all?) of the
   things you mention above, so is there a problem
   with what currently exists?

 >    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.
 > 
 > [HC]I am in the same fix. So some help from the participants will be useful.

   I think everybody is. Cross realm X is one of
   life's generic Hard Problems.

		  Mike