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
How the routers treat that hint is a local administration issue, and
outside the scope of any specific QoS model. 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.
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
only one that may care is the destination host, so trying to invert
the non-transitive relationship between the flow label and QoS models
is simply wrong. The knowledge that the originator has related a set
of packets may be of some use in building a QoS model, 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.
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]
--------------------------------------------------------------------
