Subject: [NSIS] An analysis of "Analysis of the RSVP Protocol"

From: Bob Braden <[email-masked]>
Date: Mon, 10 Dec 2001 17:39:15 GMT

There is a lot to dislike about this Internet Draft.  I do not think it
adds very much to the discourse of the NSIS WG, and it contains a number
of questionable or misleading statements.  Of course I am partisan about
RSVP, but this Draft heaps on more of the nonsense that has been bandied
about.  Let's at least start from reality.

Bob Braden

  *> 
  *> Internet Engineering Task Force                               Marc Greis
  *> INTERNET-DRAFT                                                     Nokia
  *> draft-greis-rsvp-analysis-00.txt
  *> Date: November 2001
  *> 
  *> 
  *>                      Analysis of the RSVP Protocol
  *>                    <draft-greis-rsvp-analysis-00.txt>
  *> 
  *> 
  *> 
  *> Abstract
  *> 
  *>    The purpose of this document is to describe commonly known problems
  *>    with RSVP as a basis for future work on RSVP, which may result in an
  *>    improved version of RSVP.
  *> 
  *> 

Hmmmm.  The title is "Analysis...".  An "unbiased summary" of RSVP
would include its strengths, which are considerable, as well as its
purported weaknesses.

Much of the material here (except for wireless considerations) has
already been discussed in RFC 2208, which is not referenced here.

  *> 
  *> INTERNET-DRAFT        Analysis of the RSVP Protocol        November 2001
  *> 
  *> 
  *> 1.  Introduction
  *> 
  *>    This document summarizes the most commonly discussed problems with
  *>    the RSVP protocol as a basis for future work on improving RSVP. Note
  *>    that this document deals only with the signaling aspects of RSVP, but
  *>    not with the "service provisioning" aspects of the IntServ
  *>    architecture.  Also note that the issues listed here do not
  *>    necessarily reflect the author's opinion, but are meant to provide an
  *>    unbiased summary of the most frequently discussed "complaints" about
  *>    RSVP. Future versions of this document will have to contain a more
  *>    detailed discussion of the different issues to determine which of
  *>    these problems need to be solved or which issues have already been
  *>    solved or do not need to be solved.
  *> 
  *> 
  *> 
  *> 2.  List of Issues
  *> 
  *>    Please note that the list below is unsorted and does not imply any
  *>    prioritization.
  *> 
  *> 
  *> 2.1.  Lack of Scalability
  *> 
  *>    RSVP is generally not considered to be scalable due to the fact that
  *>    QoS signaling with RSVP is performed on a per-flow basis, which can
  *>    lead to a large amount of signaling state in the core of the network.
  *> 

As a complaint against RSVP this is simply nonsense, for several
reasons.  RSVP was never intended to be used in the core of the
network, where scalability is a serious issue.  Intserv over diffserv
in the core is what was intended, and it is now defined (although you
have no reference to it.)  Why must we keep beating this horse?

Besides, I will be surprised if the NSIS WG comes up with any signaling
protocol that is NOT per flow.  That's really the point, isn't it?

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

Yes, multicast QoS is inherently complex.  But relative to RSVP
complexity, have you looked at SS7 or Q2931 or OSPF lately??

Subsets and proxies for low end terminals might be reasonable
engineering, however.

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

No, it decreases the complexity, and it handles inherently asynchronous
paths as well as multicast.

  *> 
  *> 
  *> 
  *> Greis                                                           [Page 1]
  *> 
  *> 
  *> 
  *> 
  *> 
  *> INTERNET-DRAFT        Analysis of the RSVP Protocol        November 2001
  *> 
  *> 
  *> 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.
  *> 

So, send explicit teardowns.

  *> 
  *> 2.5.  Slow Reservation Mechanism
  *> 
  *>    To request QoS with RSVP, at least one round-trip time between sender
  *>    and receiver is required, as it is necessary for the sender to send a
  *>    Path message before the receiver can respond with a Resv message. It
  *>    is not possible to perform "forward reservations" with RSVP.
  *> 

I look forward to the NSIS signaling protocol that operates in less
than one RTT.

  *> 
  *> 2.6.  End-to-End vs. End-to-Edge/Edge-to-Edge
  *> 
  *>    RSVP is inherently an end-to-end protocol. It is not clearly defined
  *>    how or if end nodes can use RSVP to request QoS from edge nodes or
  *>    how edge nodes can use RSVP to communicate with each other without
  *>    involving end nodes.
  *> 

The proxy draft is not clear to you?  (It isn't clear to me, either,
I must admit).

  *> 
  *> 2.7.  Mobility
  *> 
  *>    RSVP as it is does not interwork well with Mobile IP. One important
  *>    point is that RSVP processes would run above IP in the end nodes,
  *>    i.e.  they would not be aware of Mobile IP. However, the IP addresses
  *>    are encapsulated in objects within the RSVP messages, which may cause
  *>    discrepancies between the addresses used within the network (which
  *>    would be the nodes' care-of addresses) and the addresses used to
  *>    identify reservations (which would be the nodes' home addresses).
  *> 
  *>    Furthermore, it is not clear how RSVP can efficiently support handoff
  *>    from one access point to another, by both removing the old
  *>    reservation immediately and by setting up the new reservation as
  *>    quickly as possible.
  *> 

Agreed,  these are open issues.

  *> 
  *> 2.8.  Security
  *> 
  *>    While RSVP already contains security features, it may need to be
  *>    examined if any location privacy issues may arise from having to
  *> 
  *> 
  *> 
  *> Greis                                                           [Page 2]
  *> 
  *> 
  *> 
  *> 
  *> 
  *> INTERNET-DRAFT        Analysis of the RSVP Protocol        November 2001
  *> 
  *> 
  *>    exchange RSVP messages directly between end-points.

!!??  If the end points are communicating, then every data packet
carries the same addresses.

  *> 
  *> 
  *> 2.9.  QoS Parameters
  *> 
  *>    The commonly used QoS parameters in RSVP messages are based on the
  *>    IntServ model which is targeted at specifying flow requirements based
  *>    mostly on bandwidth requirements as well as queueing delay

... primarily on bandwidth and burst size...

  *>    requirements (for Guaranteed Service). However, this may not be
  *>    sufficient for cases where a host in a wireless network may want to
  *>    use RSVP to signal QoS requirements to other devices or network
  *>    nodes, as there is no means for deriving wireless-specific
  *>    requirements (e.g. acceptable error ratios) from the IntServ-specific
  *>    parameters.
  *> 

So, you need a different service model; define it.  (There is a
tendency for people to wave their arms and insist on "QoS" without
undertaking the hard intellectual work of defining a service model.
"And then QoS magic happened... everything got better!"

  *> 
  *> 
  *> 3.  Possible Solutions
  *> 
  *>    This document is not intended to give a thorough analysis of
  *>    potential existing solutions for the different issues discussed here.
  *>    However, some of the most important drafts and RFCs which address
  *>    some of these issues are listed below (in no particular order). The
  *>    intention of this list is simply to acknowledge the fact that there
  *>    is an "RSVP extension suite", which will have to be taken into
  *>    consideration in future discussions.
  *> 
  *> 
  *>    -  "Aggregation of RSVP for IPv4 and IPv6 Reservations" [1],  RFC
  *>       3175
  *> 
  *> 
  *>    -  "RSVP Proxy" [2], draft-ietf-rsvp-proxy-02.txt (Work in Progress)
  *> 
  *> 
  *>    -  "RSVP Refresh Overhead Reduction Extensions" [3] RFC 2961
  *> 
  *>    Note that this list is not only incomplete from the IETF point-of-
  *>    view, but it also ignores "outside work" (e.g. packet cable additions
  *>    to RSVP).
  *> 
  *> 
  *> 
  *> 4.  References

How about RFC 2998???

  *> 
  *> 
  *>    [1]       Baker, F., et al, "Aggregation of RSVP for IPv4 and IPv6
  *>              Reservations", RFC 3175, September 2001
  *> 
  *> 
  *> 
  *> Greis                                                           [Page 3]
  *> 
  *> 
  *> 
  *> 
  *> 
  *> INTERNET-DRAFT        Analysis of the RSVP Protocol        November 2001
  *> 
  *> 
  *>    [2]       Gai, S., et al, "RSVP Proxy", draft-ietf-rsvp-proxy-02.txt,
  *>              Work in Progress, July 2001
  *> 
  *>    [3]       Berger, L., et al, "RSVP Refresh Overhead Reduction
  *>              Extensions", RFC 2961, April 2001
  *> 
  *> 
  *> 
  *> 5.  Author's Address
  *> 
  *> 
  *>      Marc Greis
  *>      Nokia Research Center
  *>      6000 Connection Drive
  *>      Irving, TX 75039
  *>      USA
  *>      Phone: +1 972 374 0629
  *>      Email: [email-masked]
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> Greis                                                           [Page 4]
  *> 
  *> 

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

---

From: Xiaoming Fu <[email-masked]>
Date: Wed, 12 Dec 2001 15:11:47 +0100

Hi Bob,

I read your interesting lines regarding complexity and multicast. 
However I don't think it will be an aim for NSIS signaling 
to develop only one protocol to serve for all kinds of applications 
and must support multicast. Maybe we can modularize a solution for 
multicast, then those problems caused by complexity and 
uni-directionality will could be resolved by this solution, but 
other applications/users who do not favor multicast could deploy 
other signaling mechanism(s). 

Kind regards,

Xiaoming