Christian,
I might be wrong, but it seems that a downstream (operator) router CANNOT
use end-to-end immutable information. If the policer in the 1st operators
domain concludes that the customer is not paying enough for the treatment
he's asking, the "treatment indicator" needs to be downgraded. If that is
not allowed, the only other option would be to drop the packet altogether.
Jarno
Christian Huitema wrote:
> > > There are no stupid questions. Some of the pushback is
> > > simply based on the fact that the diffserv model of QoS
> > > is inherently broken because there is no end-to-end
> > > immutable set of bits for local decisions to be based on.
> >
> > This is a very unfair comment. Diffserv is just fine in the
> > case of unencrypted traffic. It has a problem (and so does
> > intserv I suspect) with tunnel or transport mode ESP.
>
> ESP is just one of the cases in which "looking at the port
> numbers" does
> not provide sufficient information to make an informed decision. There
> are many examples that do not involve ESP, e.g. an audio stream can
> carry different levels of hierarchical encoding on successive
> ports, an
> HTTP transaction can carry a medical transaction just as well as
> recreational content, a file transfer may be a virus update or a virus
> propagation. At some point, the classification decision has to rely on
> information provided by the source.
>
> In fact, there is no contradiction between the "immutable" requirement
> that Tony is advocating and Brian's "diffserv handle" requirement. In
> the diffserv model, the actual classification is based on the 6
> classifier bits; there is no context that this can be mutable, since
> ISPs must be authorized to reclassify traffic. The reclassification is
> based on information carried in the packet, part of which is the label
> affixed by the source; making that label immutable is a good thing,
> since it prevents intermediaries from removing the
> information that can
> be used by a downstream router.
>
> -- Christian Huitema
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
