Tony Hain wrote:
>
> [...] 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.
I hate to say it, but your conclusion is grotesquely false.
The Diffserv QOS model is not broken at all - I don't know
how, where, and why you got that.
For IPv4 M-F classification, Diffserv can use the well-known 5-tuple.
src, dst addresses, src, dst ports, and protocol ID.
For IPv6, it can use the same 5-tuple. However, using the same tuple
presents a number of problems, which the use of the flow label
alleviates.
That is in a similar fashion to the Intserv use of filter_specs, with
addresses,
and ports, and addresses and flow labels.
> What we have on the table is a proposal to take over
> part of another field to create that set of bits, but
> even that contains the argument that the bits should be
> mutable.
These are false conclusions. This is ignoring or ignorance, of some
basic facts.
First the FLOW LABEL WAS DEFINED WITH MUTABILITY IN MIND - the
checksum calculation (IPv6), and the IPv6 IPsec authentication skip the
flow label
field, on purpose to allow en-route changes.
You assume that the flow label MUST be immutable, because you base your
thinking on an absolute model. An absolute model is closed, and
unnecessarily restrictive, not allowing future development or
enhancements. As the value of the flow label can change
as long as the meaning is preserved, the model can be relative, and thus
be opened for future development.
> As soon as that is deployed and proven
> inadequate they will be back for another set of bits.
This is a grotesque ignoring of facts, and misleading statements.
The flow label value space is there (00000-fffff).
If Intserv is using the flow label ala RFC 2460, than the entire label
space is given to Intserv.
If Diffserv is using the flow label, and that is as legitimate as the
use by Intserv, it has to simply share the same label space.
A simple way is to keep a static separation, and divide it in two.
> The diffserv WG should have defined a set of PHBs with
> global context and mapped a set of DSCPs to those. It
> chose not to, and now to make products work people are
> looking for another set of bits. That is the wrong
> process. The diffserv WG should go back and fix the
> immutability problem they created.
>
> Tony
What are you talking about? This seems to be a grotesque
random mixing of things, and getting to false conclusions and
misleading statements.
Alex
S/MIME Cryptographic Signature
