Alex Conta wrote:
> There is little experience with IP QoS billing.
And that will continue until people figure out that a real-time
modification to an SLA structure is required for the end user
to perceive enough value to be willing to pay.
> But how about FR and ATM
> services, where PVCs do not give users any more control than Diffserv,
> and various levels of QoS and billing are available.
Hop-by-hop labeled circuit services are exactly what MPLS
provides, but Brian felt I was being unfair by characterizing
diffserv that way. If a user is going to bother to get QoS
from the Internet, it will have to provide more capability
than F/R or ATM, or it will have to be significantly cheaper.
Since I don't see the latter happening because diffserv is
too labor intensive, I can only expect we will get more
capability. If all you are offering is to match capability
Internet QoS will go nowhere.
> There is a basic, simple SLA/TCA, and the users pay today a basic
> monthly fee.
But there is no mechanism for the end user to say that he is
willing to pay Nx his normal rate *right-now* because it is
really important that this get done. It is also impossible to
sort between business use of an app vs. recreational use.
Strict diffserv has a limited domain of applicability, and as
I said before it is a providers fantsyland because it allows
the provider complete control without giving any mechansim
for input or negotiation from the person paying the bill.
> I see no reason, why that would not work with Diffserv, with a few QoS
> levels, and policing, and shaping, which would not be different
> conceptually from the FR or ATM model.
True; see above.
Tony
> -----Original Message-----
> From: [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 28, 2001 10:09 PM
> To: ALH-IETF
> Cc: Brian E Carpenter; ipng
> Subject: Re: a), b), c), d), or e)
>
>
>
>
> Tony Hain wrote:
> >
> >
> > How does it work if I am encrypting my traffic (independent of
> > protocol version)?
>
> In transport mode ESP, the BA part works, in fact better than
> Intserv.
> The MF part has the same issues as Intserv.
>
> In tunnel mode ESP, the MF Diffserv and Intserv face both the same
> problems.
>
> So it would seem that both Intserv, and Diffserv face
> problems with ESP,
> and so
> no QoS model gets a free ride, except Diffserv BA with transport mode
> ESP.
>
> > [...] A strict diffserv network is a
> > providers fantasy land. There must be a mechanism for the
> > endpoint to inject intent or there will be no reason to pay.
> >
>
>
> How about Internet access networks. A billing model existed
> and worked,
> when the Internet access was based on analog modems, and you had the
> choice between per minute charge or unlimited service charge. It works
> today when some of the Internet access is done with DSL, or
> Cable.
>
> > [..]
> > No, I base my thinking on the fact that for diffserv to work
> > there has to be a visisble set of immutable bits with well-known
> > end-to-end semantics. Otherwise each provider can't figure out
> > which PHB is appropriate.
> >
> > Tony
> >
>
> What you are saying is absolutely right.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
