Tony Hain wrote:
>
> Brian E Carpenter wrote:
>
> > > There is RFC2996 to fix this problem...
> >
> > That only works up to the first diffserv domain on the traffic path.
> > As the packets enters a 2nd, 3rd etc. diffserv domain, the problem
> > reappears. By the way, the absence of signalling is a virtue, not a
> > problem, from the scaling viewpoint.
>
> The absence of signalling is not the virtue, limiting the points where
> the signalling is interpreted is. Removing signalling explicitly kills
> any hope that the endpoint is capable of expressing its willingness to
> pay for enhanced services. Basically there can't be a sustainable QoS
> business model that is strictly based on diffserv, because the person
> with the cash has no means to control which packets get which level of
> service.
Absolutely untrue. The customer's SLA drives the provider's QOS policy
configuration which drives the classifiers. There is a direct impact
of customer money on this. And it should recurse from ISP to ISP, assuming
every bilat inludes an SLA.
It is of course at the granularity of traffic aggregates, not flows.
> The whole diffserv effort was so overbiased by the provider
> viewpoint of limiting abuse that it forgot that there has to be some
> means for the originator to state intent and see value in return.
It's just as much the destination as the source, but the intent is
expressed in the SLA. Also, I agree with you: host marking is a Good Thing
and I could name some products that do it. Consistent SLAs allowing consistent
use of code points are also a Good Thing. But for scenarios without
these Good Things, I would like a pragmatic solution.
>
> > Because the diffserv architecture requires the option to
> > reclassify traffic, because that's what the ISPs say they need.
>
> But have they got any paying customers for that service? Or for that
> matter any hope of having any?
I don't know what customers ISPs have, but I do know that diffserv
capability is getting into many products and management systems.
What I certainly don't know is whether people are signing diffserv-
savvy SLAs.
>
> > I don't like the word "usurp". If the flow label was already
> > standardised and in habitual use, it would be appropriate,
> > but then we wouldn't be having this conversation anyway. Since
> > it is not standardised, there is nothing to usurp.
>
> I will grant you that we have no Standards in this space, but to
> the status of 2460 I believe it is standardized as:
>
> A flow label is assigned to a flow by the flow's source node. New
> flow labels must be chosen (pseudo-)randomly and uniformly from the
> range 1 to FFFFF hex.
>
> All packets belonging to the same flow must be sent with the same
> source address, destination address, and flow label.
That's Appendix A, which the Area Director has stated is non-normative.
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]
--------------------------------------------------------------------
