Brian,
In the scenario you provided (multiple instances of the standard PHBs, each
mapped to separate DSCP value), the mapping is reversible: the egress router
of that domain should be able to map back to the single instance of the
recommended DSCP value for the PHB in question. Therefore usage of the
recommended DSCPs intra-domain would seem to be sufficient.
I might be wrong, but it seems that unless there is a case where a locally
used DSCP value for a PHB cannot be mapped back to a standardized, PHB
definition recommended DSCP value at the domain egress, there is no need for
additional support from the flow label.
Also, mutability and standardized semantics would seem to be orthogonal
issues.
Jarno
> -----Original Message-----
> From: ext Brian E Carpenter [mailto:[EMAIL PROTECTED]]
> Sent: 29. elokuuta 2001 1:01
> To: [EMAIL PROTECTED]
> Cc: Steve Blake; [EMAIL PROTECTED]
> Subject: Re: Higher level question about flow label
>
>
> 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]
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
