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

[marc.greis@nokia.com]

Mike,

I pretty much agree with most of the points you brought up. I just have some
additional comments.

[Some parts are cut from Mike's mail just to keep this short]

> -----Original Message-----
> From: ext Michael Thomas [mailto:mat@cisco.com]
> Subject: [MIP-QOS] Draft version of MIP QoS Requirements Draft
>  >    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.

I think the point was that the old QoS state (i.e. between former point of
attachment and crossover router) should (must?) be removed immediately after
the handover, i.e. we shouldn't have to wait for the RSVP soft state to time
out. Perhaps the requirement needs to be reworded.

>  >    2. Interoperability with heterogeneous QoS paradigms:
>    Lose paradigms... it's so 90's marketspeak :-)

Nah, in 90's marketspeak, it would have been "Leverage heterogeneous QoS
paradigms". ;) (SCNR)

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

I agree, but I think that is covered in the draft by requirements 1 and 2 in
3.1. Perhaps this part should be made more explicit?

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

I'm also still not convinced that we should get into the "wireless domain".
We are trying to set up requirements for a QoS mechanism that inherently
covers the whole path between MN and CN, but the wireless link will be
always only a part of the whole path, i.e. the traffic between MN and CN may
traverse a lot of different link layers. So what does it mean if the
application is able to express link layer specific requirements which are
actually end-to-end requirements? Do these requirements always only apply to
wireless links? How do we assign e.g. "error ratio budgets" to link layer
segments along the path to satisfy an end-to-end requirement like the packet
loss rate? A simple scenario which already gives me a headache would be the
case where both the MN and the CN are connected over a wireless link. If the
MN requires a maximum packet loss ratio of 10^-3, what do we tell to the
wireless links on both sides? If we have a packet loss ratio of 10^-3 on
both wireless links, the MN is going to see a packet loss ratio that is
higher than what it requested. There may be a simple solution, but I fail to
see it.

>  > 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?

That's quite tough to define more clearly. I think that these requirements
should probably be seen as comparative requirements, i.e. if we have two
mechanisms which do exactly the same but only differ in the required
bandwidth over the wireless link, then we take the mechanism that is more
efficient. I think what nearly all of the requirements in point 3.5 have in
common is that you can not have enough of them, i.e. a mechanism can not be
scalable enough, secure enough, you can never preserve enough wireless
bandwidth, etc., the result being that you can not quantify these
requirements, but you have to choose the mechanism which fulfils them most
efficiently.

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

I doubt though that this is within our scope, though I agree with your
concern. Does this mean that we need QoS extensions for Diameter?

Marc