[[ I was hoping there would be more follow-ups on this thread, but
apparently not... ]]
Combining two messages in one:
On Thu, 12 Aug 2004 18:00:50 -0500 "James M. Polk"
<jmpolk(_at_)cisco(_dot_)com>:
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).
Well, here's a couple -- hope it helps. Correct me if I'm mistaken:
- RSVP doesn't have "network indication of support": the nodes keep
spewing RSVP messages to the network even if every router is happily
ignoring them, and the destination node does not support them.
Possible fix: have the signalling engine contact the local network
administrator with a protocol to confirm if it supports the
reservations or not.
- path-coupled messages require significant processing at the
routers. This probably needs to happen in "slow path", in software.
A draft mentioned an implementation being able to support a whopping
(NOT!) 7000 sessions. That works for the first hop, and possibly
even to a degree inside an enterprise where you can have software
based routers and not too many hosts, but it's not a useful model for
larger routers, deployed at more central places in the network.
Possible fix: instead of on-path processing, contact a node off-path,
which performs all the processing, checks the policies, etc., and
ensures that appropriate QoS metrics are configured at the appropriate
routers (these could be bulk DiffServ guarantees, more specific
reservations and whatever).
- the policy checks are distributed to all the routers: the real
policy, within an administrative domain, is however made in a
centralized fashion, so it would be useful not to have to distribute
the policy to every router, but rather just process it in one place.
Possible fix: BB model provides this capability.
- doing anything that crosses administrative domains for bandwidth or
other reservations requires that the operators have incentive to
provide these capabilities to outsiders, and hence the applicability
is restricted to a single administrative domain or the first hop.
But when you operate inside a single domain, path-coupled signalling
does not seem necessary in the first place, you could just contact an
entity which would be trusted to make the reservations on your behalf.
The only alterntive is if significant amounts of money is transferred
based on the reservations, but that would make the mechanism a
non-starter for the users.
Possible fix: do signalling just inside an administrative domain, and
using a path-decoupled mechanism (whether a direct messaging with the
1st hop router or BB depends on the deployment).
- the model where hosts or apps can reserve bandwidth or other
characteristics doesn't sit well with the operational models of ISPs.
Such a reservation by definition eats from the shared resource;
multiple reservations result in fewer people being use the the
originally shared resource. On the other hand, the reservations
aren't useful unless sufficiently large about of BW is allocated to
them, and then the rest will suffer. So, this would only be feasible
as a premium paid service. But to achieve that, one could set up more
static resource allocations as well, or use other form of signalling.
Clarification needed: is the signalling protocol envisioned to be used
for paid premium service only? If so, it may have some marginal use,
but I doubt the users are willing to pay for it so it would be
marginal. If not, the protocol needs to be highly resistant to
users/apps requesting too large reservations (consider a
virus-infected host requesting very large reservations), security
models, etc.
- if an operator would provide paid "premium" service, it would have
to acknowledge that its regular service is bad. The competitors just
state that all of their service is equally good (than the premium
service) due to sufficient over-provisioning. And if your own regular
service is good enough, the customers have no incentive to request
better service and pay you. Hence, a model where the customer has to
pay extra to get quality doesn't seem to cut it in general.
- the first-hop only case is considerably easier because the user can
just shoot himself (not the others) in the foot. I.e., it allows the
user to manage *his* traffic preferences on the link, i.e., he cannot
reserve from the bandwidth used by others.
.....
A local administrative domain could allow the local hosts to set up
reservations, yes. But in most cases, these networks are already
over-provisioned except for a few special links (e.g., between the
geographical sites, or the first hop) -- a well-defined environment
which wouldn't require path-coupled signalling.
Remote administrative domains (including the ISPs) don't want
"foreign" nodes to request any reservations, unless they get direct
income from allowing that. A free service just doesn't work, as the
Internet users are greedy by definition. Best effort service is the
fairest service available under such circumstances.
And if you constrain yourself to just solving the problem for premium,
paid service (so that the users would not have incentive to request
special treatment unless they want to pay big bucks for it), it won't
attract sufficient economic interest (because if it would have, we'd
have RSVP already deployed and used widely already). The
economic/operational tradeoffs to both the ISPs and the users just
aren't right.
So, I think the main point is that a model which requires payment
doesn't fly economically, and a model which doesn't require payment
doesn't fly operationally or technically because then everyone would
send in reservations and the result would be worse than best effort
because there wouldn't be enough for everyone. The reason why BB model
is better is because it centralizes the processing and policing, and
makes it easier to allow adopt QoS because it's less costly
(considering state, processing, etc.) in the routers than path-coupled
signalling.
On Fri, 13 Aug 2004, John Loughney wrote:
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?
NSIS was specifically charged to by the Transport ADs to work on
on-path signaling.
That'll certainly focus the work, but the question is whether that
focus is useful or not.
I really really hope that there has been a problem statement...
Why? I've generally found that problem statement documents have
limited usefulness.
That might help in understanding the problems better. One part of
that is identifying what problems the earlier solutions aimed to
solved and why they did not succeed (at least to certain
expectations). I saw some analysis in
draft-ietf-nsis-signalling-analysis-04.txt when I quick read it, but
it seemed to be lacking real, operational input about the operational
and deployment problems, and was looking just the issues with the
protocol on its own.
Based on the direction where NSIS seems to be heading, the result is
likely going to be a slightly fancier version of RSVP .. which isn't
going to be terribly useful, except for those few who are already
using RSVP.
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.
As you know from IPv6 discussions, people's view of what constitutes
a site is very different. It is not a well defined term.
I don't see why it would need to be well-defined, all you'd need to do
is ask a "bandwidth broker" at your site, by finding out its address
using one of many option (you don't need to know the actual definition
of the site to do that, or the span of the site).
NAT & FW traversal is very difficult, especially for signalling
incoming connections. We have documentation, if you are interested.
Why would the administrator of the firewall trust the user or an
application running on the user's laptop to "behave well", i.e., punch
holes in the firewall?
NAT traversal is more trickier esp. inbound, but we already have a
large number of solutions aiming to achieve exactly that, among them
ones which provide non-encumbered IPv6 connectivity through the NATs,
and then the problem would be fixed automatically.
Also, there is no standard bw broker. Hoping that there was doesn't
help. Currently deployed bw brokers have scalability problems,
especially if they are meant to scale Internet-wide.
I don't know if there are ones, but that certainly wouldn't be a
show-stopper if there was a decision that this was the way to go.
All the approaches have scalabililiyu problems, especially if they are
meant to scale Internet-wise .. especially RSVP-like path-coupled
techniques. That's the point. Any design which you'd like to scale
Internet-wise is probably broken, and especially so if it requires
processing at the intermediate nodes.
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.
Interestingly enough, there are operators involved in the NSIS
discussions.
I wasn't referring to 3GPP operators ;-) (who are probably interested
in this for the first hop purposes, or for the first+last hop
purposes, where other methods might work nicely as well)
--
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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf