Brian E Carpenter wrote:
> The flaw in this is that one of the IETF's two QOS models is
> *not* flow
> oriented - that is the entire reason why diffserv would need
> a flow label
> with defined semantics.
This appears to defy logic. The way I read it, we have a QoS
mechanism that by-design is not end-to-end oriented, so we MUST
define a way for the middle to interpret what the end points
are telling each other.?!? There is absolutly no reason to tie the
Flow Label field and the Traffic Class field together, which is
the only point of defining diffserv semantics for the Flow Label.
There is no more need for a diffserv host to use a structured value
for the Flow Label than there is for an intserv host to do so.
The field is an end-to-end identification of packet relationships,
nothing more. The Traffic Class field identifies PHBs, nothing more.
They both exist in the packet from the origin, so why is it required
that there be a relationship? The set of packets identified as a
flow will be the same with either QoS mechansim, so why is there
a need to have distinct semantics unless someone in the middle wants
to interpret them? Since the middle is supposed to be per-hop and
not end-to-end, why would it care what the endpoints are saying?
Basically, why is it suddenly required that we define end-to-end
semantics for a DSCP in the FL field, when the diffserv WG refused
to do so for the TC field? If diffserv needs end-to-end agreement
on the DSCP/PHB mappings (which I believe it does for non-technical
reasons) then the work should be done in the TC field.
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]
--------------------------------------------------------------------
