Steve Blake wrote:
>
> Jarno Rajahalme wrote:
>
> > Steve Blake wrote:
> > > 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.
> >
> > Has this changed? Would there be hope for non-locally-mappable DSCP
> > deployment NOW? I've understood the standardized values already exist
(the
> > PHB definition recommended DSCP values).
>
> Not to my knowledge. I fail to see much use for privately defining the
> DSCP->PHB mapping for the standardized PHBs, but I also don't see any
reason
> why someone who wanted that feature would be willing to give it up, and I
> don't see any mechanism by which they could be forced.
>
I have in earlier messages proposed "giving up just a little": map
intra-domain DSCP back to a standard recommended DSCP at the domain egress.
Next ingress would understand the standard values, and could then again map
to it's own intra-domain DSCP->PHB mappings.
Brian's answer to this was that this cannot be forced on the operators.
> > > 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".
> >
> > I can see this to be useful, IF DSCP cannot be made non-mappable, and
the
> > proposed flow label usage would be mutable.
>
> Why would it be useful?
Intra-domain egress would have an idea of what PHB the packet needs (that
the next ingress understands).
>
> > > The only additional
> > > in-band information that would be remotely useful for Diffserv would
> > > be a credit card account number.
> >
> > Assuming that the flow label usage would be immutable. The first
operator
> > that doesn't see the transitive out-of-band credit card should re-mark
the
> > flow label to '00000'.
>
> I don't get your point. The flow label is in-band. A
> mutable flow label
> is just a 20-bit DSCP. Why would we want that?
>
Well, maybe 16 or just 6 bits depending on the allocation, but non-locally
mappable. An alternative would be to get the diffserv WG mandate use of
standard recommended DSCP->PHB mappings only. "Intserv" flow label would get
to keep 19 bits.
What I meant with the remark above is that if the ingress can't associate
the "diffserv" flow label with a "payment" should value in the flow label to
indicate "best effort" (if not drop the packet). There would be no sense to
give preferential treatment for a packet that is not being paid for and then
have the operator pay the next operator for preferential treatment. As soon
as the money (originating from the packet originator) stops flowing, any
preferential treatment should stop.
Jarno
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
