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.
>
There is little experience with IP QoS billing. 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.
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. There
is a basic, simple SLA/TCA, and the users pay today a basic monthly fee.
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.
> [..]
> 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.
S/MIME Cryptographic Signature
