RE: [MIP-QOS] Re: MIP-QOS -- Scope of discussions

["ext James Kempf" <James.Kempf@sun.COM>]

Fred,

Re. RSVP v.s. Diffsrv, 	in cellular networks, the radio access network
is always oversubscribed because the air is always in scarce supply.
Thus there is a part of the network that has Intsrv like requirements
but these are not end to end. They are only in the access network.
Thus, I have some trouble seeing why RSVP is needed end to end, and
I think it is somewhat heavyweight even for the access network,
since the signalling in the handoff case is very subotimal (please
see Michael Thomas's draft on this). Note that I am not saying that
the IP QoS signalling should directly cause the radio QoS to
get established (that is a separate, and very interesting topic
on its own) but just simply that there needs to be signalling that
allows RSVP-like reservations hooked to the radio QoS mechanism.

In the core network, Diffsrv works fine, if the service provider
is willing to overprovision and give up the "all circuits are busy" message
that comes a part of end to end QoS. Most service providers seem
pretty tied to having end to end QoS, though reestablishing that
on handover is really costly.

So I think there are three separate issues here:

1) How to get signalling that is handover friendly and provides Intsrv
like properties in the radio access network without requiring the
entire network to be Intsrv?

2) How to match up the above with a DiffSrv like core, like Diff-edge?

3) How to do handover friendly, end to end QoS for those service
providers that don't want to overprovision and want to provide
the "all circuits" message?

		jak

>X-Sender: fred@mira-sjcm-2.cisco.com
>Date: Tue, 17 Apr 2001 16:53:57 -0700
>To: mip-qos@research.nokia.com
>From: "ext Fred Baker" <fred@cisco.com>
>Subject: RE: [MIP-QOS] Re: MIP-QOS -- Scope of discussions
>Cc: mip-qos@research.nokia.com
>
>I think you're going to find that there are several interesting variations, 
>and some subtle problems.
>
>I would strongly suggest that in the data plane you want to think about 
>diffserv technology. That means, in essence, that you are going to mark 
>traffic with specific marks (RFC 2474/2475) indicating how you would like 
>the traffic generally treated by the network. For elastic traffic 
>(TCP-based applications and applications that behave similarly), that will 
>mean essentially limiting delay by limiting queue depths. For voice, that 
>means limiting delay by using priority.
>
>To get predictable behavior out of the network, you need to know how much 
>traffic there is in the network and you need for network nodes to act 
>predictably (Parekh and Gallagher, Infocom '93). Diffserv is about getting 
>the network nodes to act predictably.
>
>TCP controls the amount of traffic in the network by responding to loss, or 
>if ECN is implemented, by responding to ECN. Since the latter is going to 
>proposed standard, and proposes to separate the concept of "congestion" 
>from the concept of "loss", I think mandating the use of RED and ECN 
>together in mobile environments to avoid gratuitous loss makes sense.
>
>Voice, however, doesn't respond to either ECN or loss - if it has 
>permission to send, it sends at a constant rate. I believe that 
>reservations of some form are necessary there. I would recommend looking at 
>draft-ietf-issll-rsvp-aggr-04.txt for a way to do that with RSVP in the 
>control plane and diffserv EF as a data plane.
>
>if you are using elastic applications (say "I-Mode" or "WAP"), QoS issues 
>along a path are manageable by a sufficiently on-top-of-things 
>administration, and is often a matter of statistical provisioning.
>
>If you are using reservations, when the path changes, you will find that 
>usually only part of the path changes - the remainder stays constant. 
>Therefore, one wants to have some form of session identifier that allows 
>you to say "this session and that session are the same session; apply the 
>same bandwidth to both of them." That allows you to set up a reservation 
>from the correspondent to the home address, replace it with something from 
>the correspondent to the first care-of address, and then set it up from the 
>correspondent to the next care-of address, all the while accounting 
>allocated bandwidth to each of the relevant sessions but allocating it only 
>once. You will find analogous issues in
>
>	draft-chang-mpls-path-protection-02.txt
>	draft-chang-mpls-rsvpte-path-protection-ext-01.txt
>	draft-owens-crldp-path-protection-ext-00.txt
>
>where the "failure" is what we would now call the motion of the mobile node.
>