Preamble: this is getting pretty far away from the core of the debate.
I'd like the chairs to make some consensus calls, because
we are going round in circles.
Tony Hain wrote:
>
> Steve Blake wrote:
>
> > I agree with your conclusion, but I disagree with the assumptions
> > you are making about diffserv (for the sake of argument, say).
> I assume you are talking about the WG not the protocol. :)
>
> > RFC2475 was built on the assumption of bilateral agreements between
> > peering providers, because that was the only model that had a hope
> > of being deployed.
> But bi-lat's don't necessarily require mutability of the TC field. That
> was simply a concession to those who wanted knobs to make it more
> difficult for the less skilled. Now we have a mechanism that only has
> a hope of being deployed, but is operationally useless on a global
> scale because it lacks any context.
I think that is quite unproven. Specifically (apart from a few researchers)
the kind of thing I expect major ISPs to do with the flexibility is
to implement multiple instances of the standard PHBs, which requires them
to use additional DSCP values for the multiple instances. The context will
be provided by a QOS policy management system and their SLAs.
> > The Diffserv flow-label proposal is trying to
> > invent an end-to-end, in-band QoS "signaling" mechanism to operate in
> > parallel with the hop-by-hop DSCP "signaling".
> Basically the hop-by-hop decisions have to be based on consistent
> end-to-end semantics of a set of bits, but the TC field was allowed
> to be randomized so it is currently useless for that purpose. This
> is still fixable by locking down the PHBs and matching DSCPs, so
This is a dream. It isn't going to happen. I went through
denial/anger/acceptance on this three years ago.
> there is no need for taking additional header bits.
Abolish IPSEC and I will agree with you.
>
> > The only additional
> > in-band information that would be remotely useful for Diffserv would
> > be a credit card account number.
> Not if the proposed new end-to-end signaling is left as mutable. There
> will be a never-ending series of requests for bits until it is accepted
> that what is required is an end-to-end immutable set that the origin
> node uses to identify its intent for the packets, (in or out of band).
There is no request for a new mutable field. On the contrary, diffserv
classification needs something that is globally unique.
> The intervening networks will always make local decisions based on
> those bits, so there is no need to rewrite them at every domain boundary.
> All the TC field is used for now is an embedded MPLS type tag, so why is
> it embedded?
That's a *complete* mischaracterisation. It doesn't resemble an MPLS
tag in any shape or form. It's in the IP header becasue it is used to
drive schedulers for queues of IP packets.
> Shouldn't it be the end-to-end consistent set of bits and
> let MPLS do the tagging it will undoubtedly do for TE purposes anyway?
MPLS is not the e2e protocol in the Internet, and is probably only
a passing phase anyway. Diffserv traffic will get mapped onto a variety
of hardware layers; but diffserv is about IP packet scheduling, not about
lower layer frame scheduling.
Brian
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
