Tony,
Tony Hain wrote:
>
> Alex Conta wrote:
>
> > The flow label has a QoS purpose, which means precisely Intserv, and
> > Diffserv.
>
> While the original purpose of the proposal for the flow label may have
> been QoS, there is nothing restricting it to that usage. Brian's original
> note tainted this discussion by including intserv and diffserv in the
> list. I would argue that options b & c be replaced with:
>
> an end-to-end immutable field which may provide a hint to the routers
> that the sequence of packets with this marking are related
I have to disagree very strongly with this. The proposal on the table
is much stronger, is directly based on the IETF's two QOS mechanisms,
is specific, and doesn't "taint" anything at all. Your text is vague, and
it prejudges the "immutability" which is more a consequence of the intserv
and proposed diffserv usages than a precondition.
> How the routers treat that hint is a local administration issue, and
> outside the scope of any specific QoS model.
Not at all. Our two QOS mechanisms are specific. There will be local
configuration issues for both diffserv and intserv, but the mechanisms
are universal and specific.
> The routers in the same
> administrative domain of the originating host may treat those as
> intserv bits, while an intermediate ISP may ignore them, and at the
> same time the destination administrative domain may have enough
> information to treat them as modifiers to a diffserv infrastructure.
No. There is no meaningful way that the same flow label can serve both
intserv and diffserv. The mechanisms involved are just plain different.
> 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. The
Thet are actually more than a hint. In the proposal on the table,
there are three very specific statements that the flow label may make:
a) this {source address, flow label} identifies a specific microflow
b) this {flow label} identifies traffic requiring a specific per-hop bahavior
c) this {flow label = 0} identifies no QOS requirement
> only one that may care is the destination host,
No, the destination host is the least likely system to care (although it might
do some inbound queue handling based on the flow label, this is certainly
not a baseline requirement).
> so trying to invert
> the non-transitive relationship between the flow label and QoS models
> is simply wrong.
This statement defeats me. In the intserv case the flow label is an arbitrary
number and in the proposed diffserv case it is in a 1:1 relationship
with the QOS service class - that is why we chose the PHB ID option.
It's as transitive as they come.
> The knowledge that the originator has related a set
> of packets may be of some use in building a QoS model,
Which QOS model? We have two, and they are different and require
different flow label semantics to work.
> while the fact
> that there is no single definition of QoS across administrative domains
> means that it is impossible to use any single set of bits to create
> that definition.
See RFC 3140.
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]
--------------------------------------------------------------------
