On 24-aug-04, at 14:29, Pekka Savola wrote:
[[ I was hoping there would be more follow-ups on this thread, but
apparently not... ]]
Be careful what you wish for...
First of all, allow me to emphatically NOT support your quest for
removal of the router alert option. While I agree with many of your
points, removing something that is both in use now (however localized)
and may be beneficial to have in the future is not the right thing to
do.
I think that if you want to provide better / more scalable QoS across
the internet, it's better to start from scratch rather than try to cram
RSVP into a completely new architecture.
- the model where hosts or apps can reserve bandwidth or other
characteristics doesn't sit well with the operational models of ISPs.
Things change. ISPs are used to that. (They may whine, though.)
Such a reservation by definition eats from the shared resource;
That's certainly not a given. If I make a phone call, my 64 kbps isn't
taken from anyone else using the phone network, but from the pool of
available unused capacity. You could do the same in an IP network, and
you probably should or your regular customers will walk away.
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.
That's not necessarily true either. Sure, there are applications that
want/need huge amounts of bandwidth that they will want to reserve. But
there are also applications that need a certain amount of low-delay,
low-jitter bandwidth, where the problem isn't the amount of bandwidth,
but making it low-delay and low-jitter (which you can't do for ALL your
bandwidth if you run close to capacity for even conservative
definitions of "close"). (And remember: there is always a bottleneck.
Always.)
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.
What we see today is that average home users eat a lot of bandwidth.
Even with today's prices that gets expensive. The problem is that users
REALLY don't like to pay for volume or be restricted in any way. An
interesting approach here would be to allow users to use as much
capacity as the network can support (yes, at 100% utilization) so the
file sharers are happy, but at the same time provide a premium service
that bypasses the thus created congestion. This doesn't have to be a
paid-for thing: you could simply make the first 100 kbps that a user
uses premium and everything on top of that bulk.
This would require per-user policers (probably several) but we really
need those anyway (and smart versions too) to be able to do something
about denial of service.
(We also need to work on the "packet loss is congestion" assumption
though, as even a little packet loss (unavoidable for a bulk service)
kills TCP. Having to over-provision just because congestion management
is too stupid is sub-optimal.)
- 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.
But having whatever the access speed happens to be as your limit is
often not the best choice.
Remote administrative domains (including the ISPs) don't want
"foreign" nodes to request any reservations, unless they get direct
income from allowing that.
Well, every network in the path between two arbitrary endpoints is
always directly or indirectly paid by one of the endpoints. So if both
endpoints want this service, their respective ISPs (and ISPs of ISPs)
have an incentive to provide it.
Best effort service is the fairest service available under such
circumstances.
Life isn't fair. :-) You REALLY don't want to do something
interactive on a small pipe that you share with some p2p file sharers
and have everyone receive "fair" packet loss percentages and delay.
I do agree that it only makes sense to implement all of this QoS stuff
if and when different service levels make sense. For a while, it looked
like it didn't, but I don't think over-provisioning can go on forever,
especially now that we have both more bulk traffic and traffic that
really wants QoS constraints.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf