On Tue, 24 Aug 2004, Iljitsch van Beijnum wrote:
- 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.)
Well, I have seen no evidence of that, but of course this may be
different with some who provide e.g. VoIP services across their
backbone (I just don't know).
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.
Certainly, but that presumes there is sufficient capacity to begin
with. Why exactly would you need to do an explicit,
application-specific reservation then?
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.)
Seems awfully close to something what DSCP's are for.
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.
I see tendency towards another direction: ISPs implement rate-limiters
or traffic quotas to the heavy bandwidth users, for all of their
traffic.
An alternative, and IMHO probably more workable solution than
providing "premium service" is going towards another direction; you've
probably heard of academic networks' less-than-best-effort and
scavenger diffserv schemes, where the users can mark their traffic to
be discarded if necessary.
Let's assume that the traffic which would be marked by the user as
"discard if needed" would not be counted towards bandwidth quotas or
rate-limits, but would still be allowed. Then the users could get
high quality for their regular traffic, get the available quality and
resources for their bulk traffic they don't care much about (specific
apps), or not mark any of it (and get rate-limited, or billed for
extra, or whatever). That would make the users *care* about their
environment, or be forced to worse quality.
If it's several high-bandwidth bulk transfer apps that are causing
problems, why not fix the traffic (non-)reservations for *them*, not
for the rest of the traffic?
- 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.
Certainly not, but consider that in the context of e.g., 3GPP or 3GPP2
wireless (constrained) link which the customer might want to
police/prioritize in some manner. The operator really doesn't care
how the user prioritizes its own traffic, but the user might. But we
need no RSVP-like model to achieve that.
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.
Certainly, but unless you get big bucks from the user (so that the
next people in the chain get more than just a couple of cents), the
ISPs won't bother to set it up. And if it requires the user to pay
big bucks, the users won't bother, and the few who would be willing to
pay are not a sufficiently large user base for the first-hop ISP to
set up their infrastructure, so nothing gets done. This is the state
we've been with for 10 years or so, since IntServ model was
introduced..
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.
Small pipes have their problems of course (where a different set of
tools could be used rather than RSVP or path-coupled signalling), but
that's not an interdomain problem that needs to be fixed. Just
rate-limit all the traffic of the bulk transferers, and provide a
means for them to mark their bulk traffic so that they can get better
quality for their non-bulk transfer.
--
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