Re: hop-by-hop and router alert options

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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf