Subject: Question about use of RSVP in Production Networks

From: "Fleischman, Eric" <[email-masked]>
Date: Tue, 10 Aug 2004 08:09:50 -0700

I am aware of some use of RSVP in labs but I am not aware of any use of RSVP in production networks (i.e., real life networks people connect to the Internet with). Simultaneously, I am encountering I-Ds and other work planning to use RSVP. This possible disconnect concerns me. Therefore, I would appreciate being educated by anybody using RSVP in production settings. Would you please let me know how many devices, what applications, and how successful these deployments (if any) are? Thank you.

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

---

From: Pekka Savola <[email-masked]>
Date: Wed, 11 Aug 2004 14:58:29 +0300 (EEST)

On Tue, 10 Aug 2004, Fleischman, Eric wrote:
> I am aware of some use of RSVP in labs but I am not aware of any use
> of RSVP in production networks (i.e., real life networks people
> connect to the Internet with). Simultaneously, I am encountering
> I-Ds and other work planning to use RSVP. This possible disconnect
> concerns me. Therefore, I would appreciate being educated by anybody
> using RSVP in production settings. Would you please let me know how
> many devices, what applications, and how successful these
> deployments (if any) are? Thank you.

I'd be interested about this as well, but also in more general.

I'd be in favor of deprecating the IP router alert option completely.  
Effectively this affects RSVP and MLD *).  I'd want to similarly do
away with the IPv6 Hop-by-Hop options.  At the very least, I'd like to
prevent further standardization of these options.

The justification is simple: any "magic" packets which all routers on
the path must somehow examine and process seems a very dubious concept
when we want to avoid DoS attacks etc. on the core equipment which
must run on hardware: effectively this means that either these are
ignored in any case (nullifying the use of such options), or put on a
"slow path" (causing a potential for DoS).  IMHO, it seems just simply
bad protocol design to require such behaviour.

I'm interested what others think about this.. :)

*) MLD should be relatively straight-forward to re-design (just send
the MLD reports to a link-local address which the router is
listening), or just keep it as is for now.  RSVP can probably thrown
away without many tears.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 11 Aug 2004 21:23:00 +0900

> prevent further standardization of these options.

Multicast packets to RVP/Core are even more harmful.

							Masataka Ohta

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 11 Aug 2004 14:58:51 +0200

--On Mittwoch, 11. August 2004 14:58 Uhr +0300 Pekka Savola 
<[email-masked]> wrote:

| On Tue, 10 Aug 2004, Fleischman, Eric wrote:
|> I am aware of some use of RSVP in labs but I am not aware of any use
|> of RSVP in production networks (i.e., real life networks people
|> connect to the Internet with). Simultaneously, I am encountering
|> I-Ds and other work planning to use RSVP. This possible disconnect
|> concerns me. Therefore, I would appreciate being educated by anybody
|> using RSVP in production settings. Would you please let me know how
|> many devices, what applications, and how successful these
|> deployments (if any) are? Thank you.
|
| I'd be interested about this as well, but also in more general.
|
| I'd be in favor of deprecating the IP router alert option completely.
| Effectively this affects RSVP and MLD *).  I'd want to similarly do
| away with the IPv6 Hop-by-Hop options.  At the very least, I'd like to
| prevent further standardization of these options.

Hmm, NSIS protocol suite (new protocol that does path-coupled QoS signaling 
ala RSVP and firewall/NAT signaling) relies on the use of router alert 
options for the initial NSIS peer discovery process.  Is there any other 
proposal to get a discovery mechanism like router alert options without the 
disadvantages of this option?

  Martin

|
| The justification is simple: any "magic" packets which all routers on
| the path must somehow examine and process seems a very dubious concept
| when we want to avoid DoS attacks etc. on the core equipment which
| must run on hardware: effectively this means that either these are
| ignored in any case (nullifying the use of such options), or put on a
| "slow path" (causing a potential for DoS).  IMHO, it seems just simply
| bad protocol design to require such behaviour.
|
| I'm interested what others think about this.. :)
|
| *) MLD should be relatively straight-forward to re-design (just send
| the MLD reports to a link-local address which the router is
| listening), or just keep it as is for now.  RSVP can probably thrown
| away without many tears.
|
| --
| Pekka Savola                 "You each name yourselves king, yet the
| Netcore Oy                    kingdom bleeds."
| Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
|
|
| _______________________________________________
| Ietf mailing list
| [email-masked]
| https://www1.ietf.org/mailman/listinfo/ietf

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 11 Aug 2004 15:04:24 +0200

> bad protocol design to require such behaviour.

Well, think of it this way: by having this option, at least you know 
you DON'T have to look at all the packets that don't have this option 
in them. So that's a big fat optimization right there.  :-)

Obviously there can be DoS issues here, but these can be managed with 
rate limiting. Just as long as failure by the router to look at the 
option can be survived in some fashion by the protocol, there shouldn't 
be any problems.

Anyway, this is an operational issue. People who don't want their 
routers to potentially handle all packets in the slow path should have 
the option of disabling this feature. Removing existing specifications 
won't do much good here. (As it almost never does.)

---

From: Florian Weimer <[email-masked]>
Date: Wed, 11 Aug 2004 20:51:45 +0200

* Pekka Savola:

> when we want to avoid DoS attacks etc.

Any packet with IP options is more or less in that category right now,
so it's a very long way to go.[1]  IPv6 seems to make things even
worse. 8-(

1. Some platforms support dropping IPv4 packets with options.  As
   discussed before, existing contractual obligations with respect to
   source routing may prevent you from enabling such a feature.

---

From: Bob Hinden <[email-masked]>
Date: Wed, 11 Aug 2004 15:36:36 -0700

Florian,

>so it's a very long way to go.[1]  IPv6 seems to make things even

That's not quite correct.  Unlike IPv4, IPv6 has two types of options, 
hop-by-hop and destination options.  The destination options are useful 
because they are only looked at by the destination host and are not 
examined by routers.  Routers only have to look at the hop by hop options 
and their presence in the packet is easy to detect.  See RFC2460 for details.

I am not a fan of hop-by-hop options and am sympathetic to Pekka's 
suggestion, but I don't think it will be possible to prohibit their use.  I 
wouldn't object to discouraging their use and agree we should think very 
hard about defining any new ones.

Bob

---

From: Dean Anderson <[email-masked]>
Date: Wed, 11 Aug 2004 18:37:31 -0400 (EDT)

RSVP is a idea that doesn't cut the mustard in the real world. There are 
several show-stopper problems with RSVP.

1) somewhat like multicast, anyone using RSVP is vulnerable to others
mis-using or mis-configuring RSVP. ISPs several AS's away can really screw
up things for other ISPs. Because of this, it is unwise to deploy it
because it requires too much trust in other ISPs.

That relegates RSVP to the enterprise Lan, where it usually isn't needed.  
Remember, RSVP is only useful if you have a congestion problem and need to
choose which packets to discard.  If you have no congestion problem, then
you have no need of RSVP. However, having a congestion problem also opens
the question of the nature of the congestion and what is the best way to
deal that problem.  I was involved in a study done by Genuity and Cisco in
which the congestion problem was found to most often involve the tail
circuit--the link between the customer and the ISP.  The best solution for
this problem was found to be low latency queuing, not RSVP.

2) Unlike multicast, every hop end-to-end must use RSVP for it to be 
useful. An RSVP tunnel is useless.

3) RSVP doesn't detect certain kinds of problems that are important. For
example, a mid-span failure is not visible to RSVP.

While RSVP is important research, it is not a widely deployable
technology.

What I-D's are you encountering that depend on RSVP?

		--Dean

On Tue, 10 Aug 2004, Fleischman, Eric wrote:

> I am aware of some use of RSVP in labs but I am not aware of any use of
> RSVP in production networks (i.e., real life networks people connect to
> the Internet with). Simultaneously, I am encountering I-Ds and other
> work planning to use RSVP. This possible disconnect concerns me.
> Therefore, I would appreciate being educated by anybody using RSVP in
> production settings. Would you please let me know how many devices, what
> applications, and how successful these deployments (if any) are? Thank
> you.
> 
>

---

From: David R Oran <[email-masked]>
Date: Wed, 11 Aug 2004 08:50:21 -0400

> I'm interested what others think about this.. :)
If you can come up with another technique for doing path-coupled 
signaling which is less susceptible to abuse I'd drop RAO in a 
heart-beat. There are a bunch of very useful things that require (or at 
least work a heck of a lot better with) path-coupled signaling:
- figuring out where to install QoS state in complex topologies
- firewall and NAT traversal
- finding the thing furthest away from you (as opposed to closest to 
you) that performs a certain function, such as state-deaggregation for 
QoS or tunnel anchor for IPSEC tunnels.

It seems to me that the key is to be able to screen packets at wire 
rate, even if they must be looked at by the control plane of each 
router. that seems only loosely related to RAO itself.

> This message was passed through [email-masked], 
> which is a sublist of [email-masked]. Not all messages are passed. 
> Decisions on what to pass are made solely by IETF_CENSORED ML 
> Administrator ([email-masked]).
>
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Thu, 12 Aug 2004 15:53:14 +0300 (EEST)

Thanks for the responses so far.  Trying to answer in general...

On Wed, 11 Aug 2004, Martin Stiemerling wrote:
[Pekka:]
> disadvantages of this option?

I question the usefulness of path-coupled signalling beyond a certain 
point in the network.  Dean Anderson voiced them pretty well in the 
original thread about RSVP -- it just doesn't seem to make any sense 
beyond a very closed environment (like the first hop) -- and in that 
case, you should be able to use another kind of signalling as well.

If we don't learn anything of the mistakes we did with RSVP, we're 
bound to repeat them.

For example, has the design clearly restricted itself to the first or 
the last hop, or within the first couple of hops?

For that purpose, I'm not 100% sure if you would need a path-coupled
signalling.  You'll certainly want path-coupled signalling for
signalling with a much wider "span" (because it's the simplest way to
do it from the host's perspective), but I'm arguing (as Dean was) that
this isn't an interesting approach from the network operators'
perspective.

...

As for the alternatives:
 1) for first-hop only, there's really little need for a router alert, 
any protocol would do, as you already know who your routers are :-)
 2) for hops beyond the first-hop router, I'd consider setting up a 
single server which would be responsible for brokering the QoS 
capabilities, firewall holes, etc. You contact the server, and ask it 
to open a certain kind of hole, set up certain QoS between (source, 
destination), etc.  There are a number of options how you could 
discover this kind of system:
    a) a DHCP option
    b) a DNS lookup (e.g., SRV record based on your DNS search path)
    c) asking the upstream router using protocol learned in 1).

These kind of approaches essentially move the intelligence and
processing to specific nodes who are better capable of handling such
requests, having policy who can request what, removing the processing
and cruft from the routers.  And the hosts have have much easier time
figuring out whether requesting these capabilities is supported in the
network, instead of spewing a considerable amount of in-band
signalling attempts to the network.

---

From: David R Oran <[email-masked]>
Date: Thu, 12 Aug 2004 10:49:47 -0400

> If we don't learn anything of the mistakes we did with RSVP, we're
First, we have to agree on what the mistakes were :-)

> the last hop, or within the first couple of hops?
No. Here's one counter-argument. Enterprise networks tend to have 
dumb-bell topologies, where the bottleneck links are in the interior 
rather than at the edges (exactly the opposite of serivce provider 
networks). They have meshes of 100meg+ all over each site, but the 
sites are interconnected with some service (like MPLS VPN, frame relay, 
etc.) which is expensive and often with very limited bandwidth 
(sometimes sub-T1). These links are not necessarily all that easy to 
identify in the topology, because for reliability enterprises configure 
mulitple routers and backup links. There is strong demand for 
flow-granularity admission control on such links, and an end-to-end 
model works better because site-to-site flows can swamp both the uplink 
at one end and the downlink at the other end.

There are other useful examples which I can share if people are 
interested.

> this isn't an interesting approach from the network operators'
What about discovery of the furthest point. Do you not find that a 
persuasive use case?

>     c) asking the upstream router using protocol learned in 1).
This assume edge tree topologies, which are common but hardly 
ubiquitous.

> signalling attempts to the network.
This is hardly a neutral characterization of the tradeoffs.

Cheers, Dave.

David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: Melinda Shore <[email-masked]>
Date: Thu, 12 Aug 2004 11:18:28 -0400

> What about discovery of the furthest point. Do you not find that a 

There are actually a number of instances in which some kind of topology
exposure is necessary for some widely-used functions to work properly.
Certainly things like being able to discover the furthest tunnel 
endpoint
is a good example, but also things like being able to present the 
correct
address in a QoS or firewall pinholing (or, indeed, any kind of filter
description) request when there are NATs present.  Note that in this 
case
the topology information isn't presented to endpoints, but only needs to
be correct hop-by-hop (between nodes).

Melinda

---

From: Pekka Savola <[email-masked]>
Date: Fri, 13 Aug 2004 00:21:00 +0300 (EEST)

Inline..

> First, we have to agree on what the mistakes were :-)

Of course.  Then why this wasn't the first thing NSIS did after going
for on-path signalling, or didn't I just manage to find it?  

I really really hope that there has been a problem statement...

> There are other useful examples which I can share if people are 

Agreed, this seems like a possible use case; but again, this is within
a site, and the congestion points can be well-defined.  If it's not
the first hop, then it's a predetermined point (or points) in the
network.  Hardly something you absolutely need on-path signalling for.
 
> What about discovery of the furthest point. Do you not find that a 

Further point where you can use path-coupled signalling, you mean?  
Not really, as there seems to be something seriously broken if you
need set up priorization except in well-defined points in the network.  
And to achieve that, you could use a "bandwidth broker": either it's
able to set up the required bandwidth (it's in the same site, or at a
site your site has a roaming agreement with), or it isn't and the
approach is going to fail in any case, because the sites out in the
Internet don't want outsiders to request bandwidth allocations.

> This assume edge tree topologies, which are common but hardly 

I don't think I assumed edge tree topologies.  Please elaborate.
 
> This is hardly a neutral characterization of the tradeoffs.

(warning, could be flammatory)

True enough, I had my operator hat on ;-).  My mind just boggled when
I started to realize that some part of the IETF is still in denial on
why RSVP didn't go through, and is now in the process of reinventing
it .. wasting a lot of time and effort that could be much better spent
on making an operationally more feasible system to provide these
reservations in a well-defined, constrained points of the network.

What I can't figure why this is happening.  I guess the IESG must have
been asleep, or the most people just thought, "well.. let them waste
their energy on that.. at least they don't bother us while they are
bashing the heads in the wall.."

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 12 Aug 2004 18:00:50 -0500

Pekka

While it is clear your distaste for RSVP, you haven't stated anything other 
than handwave why RSVP is so bad ("in the first place"). You mention there 
were mistakes and a BB will fix them, but you don't list a set of mistakes 
RSVP made for folks to digest. I don't know if you think they are so 
obvious you don't have to state them or you don't want to list them for 
whatever reason.

Humor me (and a few others here) with a few listed mistakes you believe 
RSVP made in its design, with how you would redo them (either with a BB or 
just a better RSVP design).

Without this, you are just ranting without substance to me - as I cannot 
glean anything real from your messages other than your distaste of RSVP in 
favor of a Bandwidth Broker...

>bashing the heads in the wall.."

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 13 Aug 2004 08:52:46 -0700

> several show-stopper problems with RSVP.

Propagating clueless FUD does not result in progress. 

> because it requires too much trust in other ISPs.

Inter-provider trust is something the Internet has to deal with. The
self-proclaimed gods of the ISP world bluster about how much smarter they
are than the Bell-heads, but even the lowly Bell-heads figured this one out.

> choose which packets to discard.  

RSVP is a signaling protocol. The policy installed in the routers with
congested links is the one deciding what to discard, and it has the
opportunity to take hints from that signaling if it chooses. 

Despite rumors to the contrary, most complex enterprise networks include
non-LAN links, and even in the all-LAN case there are speed mismatches
between old and new segments.

> If you have no congestion problem, then
> you have no need of RSVP. 

Signaling is useful for more than QoS, though it is not clear that RSVP as
currently defined is useful for signaling non-QoS related policy. 

> However, having a congestion problem also opens

As you say it depends on the nature of the congestion, but also the nature
of the application in the face of congestion. Generalizing all complex
topologies to a congested uplink just leads to protocol decisions that are
useless in the real world. 

> useful. An RSVP tunnel is useless.

This is the type of BS that keeps useful tools out of the hands of those
that need them, but don't have enough time to figure out the reality. The
only points that need to pay attention to signaling are those where
congestive loss is likely to occur. Even then, a smart implementation might
only pay attention once a threshold has been crossed indicating that queues
are building. 

> example, a mid-span failure is not visible to RSVP.

WTFO! RSVP is a periodic signal, so it does detect and respond to mid-span
events. 

> While RSVP is important research, it is not a widely deployable

The reason the Internet has been successful is that each administrative
domain gets to decide which technologies are deployable. Your decision that
RSVP is not deployable does not automatically restrict if from wide
deployment. 

In answer to Eric's original question, the FUD being spread through
responses like Dean's have squelched what little RSVP had been deployed
several years ago. That does not remove the need for a signaling protocol,
as many WGs find they need to define new ones or variants. The bottom line
is that the lack of a trust model makes operators suspicious of any external
signal.

Tony