Subject: [NSIS] Comments on draft-greis-rsvp-analysis-00.txt

From: Ashok Narayanan <[email-masked]>
Date: Fri, 7 Dec 2001 18:10:50 -0500

Hi. I have a few comments on sections 2.2 through 2.4 of
draft-greis-rsvp-analysis-00.txt. Please see inline.

-Ashok

> 2.2.  Complexity 
>
> It has been argued that RSVP is complex to implement, and that it
> may be too "heavy" especially for low-end terminals. As an example,
> one of the features which may lead to a high complexity is the
> handling of multicast reservations, which implies the need for
> proper merging of multiple reservations in a multicast tree.

Specifically, you don't need to do too much work merging multicast
reservations on an endpoint terminal; this is a problem only on
transit hops.

More generally, the issue of RSVP complexity has been raised multiple
times in the past, on both endpoints and routers. I view the
complexity issue from two directions:

- Systems: What systems do we have to implement this on, and what are
their constraints? e.g. an IP phone doesn't have too much CPU/mem but
it is only an endpoint. In this case the two major kinds of systems we
seem to care about are endpoints and transit hops. The real
implementation complexity bottleneck appears to be on endpoints, where
you don't want to use up too much memory, but you don't have too many
states to deal with. On midpoints (e.g. routers) you have more memory
and more states, but you want to reduce CPU cycles. I'm in the process
of gathering some numbers on this, so will defer comment till later.

- Applications: What are you trying to achieve QoS for? Unicast
point-to-point communication (e.g. a VoIP call)? Multicast
distribution from a single server to a set of receivers? A general
conference with an arbitrary number of senders and receivers? The
ability to select which senders you wish to listen to?

Part of the complexity of RSVP comes from the fact that the protocol
is designed to support *all* the above applications; so you end up
with receiver-driven QoS, multicast, and support for FF, SE and WF
reservations. If you limit the application, you can limit the features
and thereby reduce the complexity. Perhaps one approach here is to
produce a set of limitation guidelines on what is required of RSVP in
certain scenarios. Whatever the result of this effort, be it RSVP enhancements
or a new protocol, could probably take a similar approach in limiting the
application and thereby limiting the required feature set. But by definition,
if the aim of the WG is to come up with a general protocol for all
applications, complexity seems a must. The second law of thermodynamics
applies here as well.

> 2.3.  Unidirectionality
>
> RSVP has been designed to set up resources only in one direction
> (from a sender to a receiver or a set of receivers). While this is
> sufficient for streaming applications, it increases the complexity
> for conversational applications, which require resources in both
> directions between two end points, as both end points would have to
> send Path and Resv messages.

For multicast, I don't see how this could be avoided in any case,
because multicast forwarding is inherently unidirectional. Even if QoS
is requested for unicast traffic, there is no guarantee in an unknown
IP cloud that routing for the two flows would indeed travel over the
exact same set of links; without this, bidirectional reservations
cannot work.

For unicast traffic with guaranteed symmetric routing, the problem is
easily solved, and in fact has been solved in multiple situations
where these constraints exist. Symmetric routing can be guaranteed by:

- Somehow controlling the routing of traffic (e.g. MPLS);
bidirectional RSVP to set up MPLS tunnels has been defined. This
works because the packet routing for traffic on a tunnel is laid down
by MPLS. 

- Running in a specific sort of topology: RSVP for DCS (PacketCable
signalling protocol for VoIP on Cable networks) defines extensions for
bidirectional QoS installation in a single RSVP session. This works
because it was developed for a one-hop topology across a single cable
link between a cable modem and a CMTS; so there's no possibility of
asymmetric routing.

Short of this sort of niche application, how would bidirectional RSVP
work?

Further, I'm unclear as to the extra complexity you allude to in your
point. Presumably any conversational endpoint would have the ability
to initiate and terminate calls; in which case, if you had
bidirectional RSVP you would still have to build the *ability* to send
both Path and Resv messages into every endpoint. One immediate benefit
apparent to me is that the number of states that need to be managed
gets divided in half; but is this really a problem at endpoints? Short
of this, the only extra complexity I can see is that the endpoints now
have to wait for two messages to confirm QoS is available (Path and
ResvConf) instead of just one.

> 2.4.  Soft State
>
> RSVP is based on a soft state concept, i.e. it is necessary to
> refresh RSVP-related state periodically to keep the soft state from
> expiring. While this is advantageous especially for networks where
> routing changes may occur frequently or for cases where an end-point
> loses connectivity without being able to tear down an existing
> reservation, this may not be acceptable in environments where
> bandwidth is scarce and expensive, e.g. cellular and other wireless
> environments.

There are two immediate benefits soft-state provides us:

* Recovery from initial message loss (session doesn't stay down
forever)

* Recovery from silent failure of the node or link (session doesn't
stay up forever). 

The "down-forever" problem (and the related problem of state changes)
is solved to a certain extent using the Reliable Messaging extension
in RFC2961 (although there remains the issue of timeout consistency
across the devices in question). But you still need refreshes to solve
the "up-forever" problem, and indeed RFC2961 explicitly states that
the use of any refresh reduction technique must not cause the refresh
timers to become larger than they otherwise would have.

If you have only one QoS-requesting session (likely on a mobile
device?), summary refresh reduces the net bandwidth used, but not the
total number of messages. For multiple sessions, summary refresh will
reduce the number of messages as well, but not the metronomic
frequency of refreshes. You could back off the refresh timers to
reduce the total number of messages, and pay the cost of having stale
state hang around longer in the network.

Hard state can work well when you have a well-defined, provisioned
network (which is why I guess it has worked well for SONET networks in
the past with telcos). If you have uncontrolled devices (especially
mobile ones), I don't see how you can eliminate the soft-state
requirement. We need to know when the neighbour has gone down or away.

One possibility is to tie the RSVP state maintenance to some other
protocol state maintenance across the bandwidth-constrained links.
Perhaps the wired end station could say that if it has received any
sort of packet at all from a wireless node, then assume that all RSVP
sessions are up. The problem to be solved here is how to determine if
the wireless node has reset and lost its end of the connection
(especially if the wireless end is the connection initiator). Sending
a refresh will figure it out quickly; summary refresh has an epoch
mechanism to resolve this problem. But if the refresh timeout is
large, this may not be the solution.

--- Asok the Intern ----------------------------------------
Ashok Narayanan
IOS Network Protocols, Cisco Systems
250 Apollo Drive, Chelmsford, MA 01824
Ph: 978-497-8387.  Fax: 978-497-8513 (Attn: Ashok Narayanan)

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis