Tony Hain wrote:
>
> Alex Conta wrote:
>
> I am not trying to exclude diffserv, just make the point that
> diffserv already has a field to work with
The DSCP field and its numbering space is not sufficient for everything
that one may want
Diffserv for.
Diffserv has two types of classifiers, the B-A, and M-F. For good
reasons, each achieving different purposes.
Intserv can use addresses, and ports as filter_spec(s) in both IPv4, and
IPv6.
Diffserv can use addresses, ports, and protocol IDs, for M-F
classifiers, in both IPv4,
and IPv6.
Intserv can use addresses and IPv6 flow labels in IPv6, where the flow
labels are replacing
ports.
Diffserv could use addresses and IPv6 flow labels in IPv6, to replace
ports and protocol
IDs in M-F classifiers.
> and is finding that it can't get the job done without taking over another field
> with imutable properties.
It can get the job done, but less efficient than in IPv4, and that is
not because
work done by the Diffserv WG.
If Intserv can take advantage of the flow label, and be more efficient,
since it can use
the functions that were designed for this in IPv6, why should Diffserv
not take advantage as well? You oppose that only because it has to share
the flow label space with Intserv?
If the flow label were to be used ala RFC 2460, the entire space from
00000 ot fffff would
be allocated to Intserv.
If my customers, or just people in general, do not choose to use
Intserv/RSVP, but want to use Diffserv, with M-F classifiers, for them,
the flow label and its numbering space is a waste.
>
> Since the network can't possibly know if there is significance
> downstream (say at the end host), the field has to be imutable.
>
Your assumption is wrong. The network can know, through various means,
which of course
include signaling.
Ad absurdum, if the routers in a domain, do not know, or there is no
mechanism to know,
but they can have a use of a mutable flow label, then they would work
together, and have the egress restore the original value when packets
leave the domain.
My making the flow label an absolute immutable field, you would lose
this capability, as
well as potential for future development.
> > > The point is they are simply a hint from the originator that packets
> > > between the src/dst pair are related as far as it is concerned.
> >
> > This is an oversimplification, and vagueness, with no
> > practical benefit.
>
> There is nothing vague about that.
It is vague in its final practical purpose. A definition devoid of
purpose makes little sense. It is like saying we define the TCP, and UDP
ports just for the sake of having some ports in the header.
> > At this stage, I do not think, we can afford that.
>
> At this point what we can't afford is redefining a field simply
> because the diffserv WG refused to create a set of end-to-end
> consistent bits.
You are missing the point.
The Intserv, and Diffserv have not created sets of bits to be used for
Intserv classifiers, or Diffserv M-F classification purposes with IPv4.
IPv6 has the flow label, which is defined and advertised as an important
(QoS)
diffentiator. In reality besides being a differentiator, it is used to
compensate for the inefficiency introduced by the IPv6 "extensibility".
For people that do not want to use Intserv/RSVP, without adding flow
label support
for Diffserv, that advertized differentiator is just smoke, it does not
exist, while they pay the efficiency penalty of the "extensibility".
On one hand, you suggest this vague, no final purpose, definition of
flow labels, which
is practically a waste of the bits, and on the other hand you oppose a
good practical use of those bits, just because there is an attempt to
structure them in a certain way.
> It is no surprise that people are finding it
> difficult to build hardware that will make consistent decisions
> when all the bits in the header are random. Since the diffserv
> mechanism is the one that needs a consistent set of bits for
> hardware acceleration, that WG should have provided them.
That working group does not standardize the IPv6 headers.
> [..]
> and we are being asked to redefine another set of bits
> to provide the necessary end-to-end consistency since the
> diffserv WG refuses to.
That "another set of bits" is already there. You just give them a use
for which they are there for, which is QoS, and a structure.
>
> Tony
Alex
S/MIME Cryptographic Signature
