Brian E Carpenter wrote:
>> ...
>> 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.
>
I am sorry, I did not intend to be vague. The proposed wording is intended
to be a precise definition for the field, and explicitly leaves out the
letters Q, o, & S.
> > 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.
>
My original statement here was poorly worded. Yes QoS handling is very
specific. My point was that the field is not strictly tied to QoS, and
therefore the interpretation of the field is a local administration issue.
> > 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.
>
Yes the mechanisms are different, but that does not mean they are exclusive.
It is not hard to imagine a site with rules for intserv use of the bits
which slightly reduce the randomness of the flow label in a way that the
traffic class field could be reconstructed by the destination site after
the ISPs randomize it. This would of course require the destination site to
know the rules the origin used, but nothing precludes that. Once
reconstructed the destination site could make decisions based on the TC,
while the origin used intserv based on the flow label.
> > 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
>
I didn't read the original message that way. In any case what I was
trying to argue is a), strictly worded as it is here without any mention
of QoS handling, or implication that 'microflow' means intserv. All the
originator is doing is telling anyone that cares to listen that the
set of packets with this marking are related.
> > 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).
>
It might also want to use that field to demux flows over port 443
to enable an application to work through a firewall. The point is
it is an end-to-end immutable field that the source uses to identify
a specific set of packets as a flow.
> > 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.
>
>From the viewpoint that the field is limited to use for QoS those are
hard relationships. My point was that QoS is not the only possible use
for the field. Overlaying a QoS interpretation is fine, but insisting
that all other interpretations are invalid is wrong.
> > 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.
>
I fail to understand how either would break if they simply intrepret the
flow label semantics as 'the source has identified this set of packtes
as related'. In either case there is an out-of-band mechansim to
translate the value to a router task. The place you appear to be
struggling is finding a standard mapping between a psuedo random value
and the Traffic Class field. Since the Traffic Class field is itself
a non-standard value (and effectivly psuedo random from an end-to-end
perspective) this seems pointless.
> > 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.
>
>From the above:
In a given network domain, there is a locally defined mapping between
DSCP values and PHBs.
Therefore my statement stands, there is no single definition of QoS
across administrative domains.
> Brian
Tony
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
