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

["ext Fred Baker" <fred@cisco.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.