Alex Conta wrote:
> ... snip ... It is some of the Intserv
> supporters that try to keep Diffserv out (excluded).
I am not trying to exclude diffserv, just make the point that
diffserv already has a field to work with and is finding that
it can't get the job done without taking over another field
with imutable properties.
> Requesting "immutability" makes sense only when a group of routers on
> the path, in a routing domain for instance, are not capable of
> preserving the meaning from ingress to egress of that domain, when and
> if that
> meaning is significant further downstream. If the routers are
> capable of
> preserving the meaning, or there is no significance downstream, then
> "mutability" is a non-issue.
Since the network can't possibly know if there is significance
downstream (say at the end host), the field has to be imutable.
> > 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. The originator is identifying
a set of packets as related. It would only be vague to a middle
box that has no context. In fact in many cases there is practical
benifit in preventing the middle boxes from acquiring context.
> 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. 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. Instead
the DSCP is effectively a random set of bits with no global
context, 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.
Tony
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
