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

From: "Louis-Nicolas Hamer" <[email-masked]>
Date: Mon, 10 Dec 2001 17:15:23 -0500

Bob, Marc,

I have to echo the comments made by Bob. I think Bob raised a very good
point with
RFC 2998. Unfortunately, too many people have not actually read the relevant
literature and
only repeat what they have heard from others. I've seen it happen in the
3GPP standards group: 
a lack of knowledge combined with lots of confusion around the non-issues,
resulted in not standardizing RSVP
as a mandatory signaling protocol.

Anyhow, I would encourage all NSIS enthusiasts to read RFC 2998. Hopefully,
this will ensure we never ever
hear again that RSVP does not scale well because it installs state in
routers in the core network.

Instead, I hope to hear people acknowledge that the DiffEdge model scales
well because RSVP signaling
is used to signal the application's QoS needs to the edge of the network
(along with admission control purposes) 
and that the QoS in the core (backbone) is based on DiffServ. State only
needs to be kept at the edge of the
network (usually in the access network).

I am perfectly ready to help properly document the strong points and
not-so-strong points of RSVP and set straigth
all of the "nonsense". Let's wait and see what's next for NSIS and if deemed
necessary, 
we can work together writing a more complete analysis.

Cheers,
Louis-Nicolas

-----Original Message-----
From: Greis Marc (NRC/Dallas) [mailto:[email-masked]]
Sent: Monday, December 10, 2001 3:18 PM
To: ext Bob Braden; [email-masked]
Subject: RE: [NSIS] An analysis of "Analysis of the RSVP Protocol"

Hi Bob,

> Of course I am partisan about
> RSVP, but this Draft heaps on more of the nonsense that has been
bandied
> about. 

Believe it or not, but I actually agree with this statement to a large
extent. The main purpose that I see in this draft is to actually write
down the "nonsense that has been bandied about" so that there is a
chance to refute it.  Until now, many of the (unjustified)
concerns/complaints about RSVP exist merely as hearsay. I thought it
would be benefical to gather these rumors to make it easier to extract
the truth from them, as small as it may be.

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

I agree again. This is currently mostly a "What is said to be wrong"
draft, rather than a full analysis. When I claim to be unbiased, I am
only unbiased in that respect that I added points to the draft that I
don't agree with, simply to allow the WG to shoot these points down.
That may seem strange, but as I stated before, I see it as an
educational exercise of sorts. In the end, I'll leave it to the WG chair
to decide if that educational exercise is useful or a waste of time.

I can see how the content of the draft does not seem to match the title
at this point. That is supposed to change, as the considerable strengths
(and I do agree that they are considerable) are intended to be included
at a later stage.

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

To ensure that it is dead. If I find out that it's not necessary to beat
the horse any further, I'll be happy.

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

The idea was to start out from RFC 2205 and then to throw in the rest of
the "RSVP extension suite" later. Note that this draft is intended to be
a starting point, not the end of all wisdom. It is after all a draft.

> 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!"

Well, first there has to be a consensus that a new (or in this case, I
would rather say extended) service model is needed. I prefer to identify
the need before jumping in with a conclusion. If everyone agrees that a
new/extended service model is needed for certain networks, then I think
we have made one step towards finding the solution.

There are several of your comments which I did not directly reply to, as
my answer would have been close to "I agree" in most cases. However,
this is the kind of comments I was actually looking for, i.e. what in
this draft would have to go, what is just incorrect, what needs to be
extended.

Marc

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

---

From: "Greis Marc (NRC/Dallas)" <[email-masked]>
Date: Mon, 10 Dec 2001 16:45:13 -0600

Louis-Nicolas,

I have to echo the comments made by Bob. I think Bob raised a very good
point with 
RFC 2998. Unfortunately, too many people have not actually read the
relevant literature and 
only repeat what they have heard from others. I've seen it happen in the
3GPP standards group: 
a lack of knowledge combined with lots of confusion around the
non-issues, resulted in not standardizing RSVP as a mandatory signaling
protocol.  

I've seen it happen as well, and it was exactly this experience that
lead me to write this draft. In the end, the goal of the draft is not to
deride RSVP, but rather to give us a chance to do exactly the opposite
in a rather formal manner. I see now though that I probably should have
made that clearer. The title of the draft alone is confusing enough. Mea
culpa.

I am perfectly ready to help properly document the strong points and
not-so-strong points of RSVP and set straigth all of the "nonsense".
Let's wait and see what's next for NSIS and if deemed necessary, 
we can work together writing a more complete analysis.  

That's the goal. I do realize of course that RSVP is more than just RFC
2205, but writing a complete analysis of RSVP plus it's "extension
suite" plus perhaps even external efforts is a multi-person effort. My
intention was to kick off discussion  and to provide an admittedly (and
intentionally) provocative starting point. 

Thanks,
Marc

---

From: [email-masked]
Date: Tue, 11 Dec 2001 09:12:24 -0000

Louise Burness
IP Mobility
BTexact Technologies

e-mail: [email-masked]
tel: (+44) (0)1473 646504
fax: (+44) (0)1473 646885 
                                
Rigel House, B28/pp2b, Adastral Park,
Martlesham, Ipswich IP5 3RE, UK

BTexact Technologies is a trademark of British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ 
Registered in England no. 1800000 

This electronic message contains information from British Telecommunications
plc which may be privileged or confidential. The information is intended to
be for the use of the individual(s) or entity named above. If you are not
the intended recipient be aware that any disclosure, copying, distribution
or use of the contents of this information is prohibited. If you have
received this electronic message in error, please notify us by telephone or
email (to the numbers or address above) immediately.

-----Original Message-----
From: Bob Braden [mailto:[email-masked]]
Sent: 10 December 2001 17:39
To: [email-masked]
Cc: [email-masked]
Subject: [NSIS] An analysis of "Analysis of the RSVP Protocol"

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

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

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

  *> 
  *> 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.
[louise] Re seamless handover:
 I think it is possible to develop RSVP to overcome some of these problems
rather than start from scrach. RSVP local path repair give a reasonable
starting point? This can be initiated as a result of a routing change -
which is what handover is essentially.  Things get easier if we assume a
context transfer protocol as is being considered in SEAMOBY. If that can
carry the RSVP context information, any reservations over a wireless can be
installed immediatly, and the new access routers could even co-ordinate the
reservation repair, thus preventing excess communications over the wireless
link. Explcit tear messages would help to remove resverations rather than
letting them time out.

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

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

---

From: "Greis Marc (NRC/Dallas)" <[email-masked]>
Date: Tue, 11 Dec 2001 09:07:05 -0600

Hi,

I admit that I did not think the draft would elicit such a negative
response (though like I said, a certain provocative factor was
intended). It was my feeling after experiences like the one described by
Louis-Nicolas that such an approach may be beneficial, but If it's the
general feeling of the group that we should take another approach to
discussing existing signaling protocols, I am certainly not overly
attached to this draft. In any case, our time is probably better spent
on discussing the requirements at this point in any case (IMHO).

Marc

> From: ext Michael Thomas [mailto:[email-masked]]
> Sent: 10 December, 2001 6:53 PM
> To: Greis Marc (NRC/Dallas)
> Cc: ext Bob Braden; [email-masked]
> Greis Marc (NRC/Dallas) writes:
>  > Hi Bob,
>  > 
>  > extent.
>    FWIW, I read this draft in pretty much the same
>    light as Bob. That is, it dredges up all kinds of
>    things that RSVP does already, and makes it look
>    as if they are problems. I don't really think our
>    job here is myth destroyers or evangelicals. Relisting
>    all of the requirements, regardless of motiviation,
>    does have a good chance of being misinterpreted for
>    one, and excruciatingly overwrought for another.
>    Crispness is our friend.
> 
> 		MIke
>