Tony,
Tony Hain wrote:
>
> 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.?!?
The endpoints in diffserv don't tell each other anything;
diffserv is an entirely hop-by-hop model. Each hop may choose
to look at the entire packet header in order to reclassify it.
> 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.
No, the point is to provide partial replacement of the {port, protocol}
semantics that are hidden by ESP. There is no tying together of
Traffic Class and Flow Label. They remain orthogonal.
>
> 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.
Wrong (see previous point).
> The field is an end-to-end identification of packet relationships,
> nothing more.
That was the old (non-normative) definition. We are proposing
to change it.
> The Traffic Class field identifies PHBs, nothing more.
It contains a code point value that identifies PHBs *within a given
administrative domain*. It is not an e2e value.
> They both exist in the packet from the origin, so why is it required
> that there be a relationship?
There is no relationship. The DSCP is a per-domain value and the proposed
PHB ID version of the flow label is an e2e value. Whether or not they
coincide depends on local diffserv configuration in each domain the
packet passes through.
> 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?
Diffserv is blind to microflows; there is no flow identification.
However, diffserv classifiers in the middle *do* need to (re)interpret
packet headers. That is how diffserv works.
> Since the middle is supposed to be per-hop and
> not end-to-end, why would it care what the endpoints are saying?
Because reclassification may occur per-domain. That is how diffserv works.
>
> Basically, why is it suddenly required that we define end-to-end
> semantics for a DSCP in the FL field,
It is *NOT* a DSCP. Please read RFC 3140. There is fundamental difference
between DSCP values (locally mappable) and PHB IDs (globally unique).
> when the diffserv WG refused
> to do so for the TC field?
We did what the ISPs wanted: locally mappable semantics.
> If diffserv needs end-to-end agreement
> on the DSCP/PHB mappings
It doesn't; again see RFC 3140 and reread the diffserv architecture.
> (which I believe it does for non-technical
> reasons) then the work should be done in the TC field.
That is precisely what the ISPs told us not to do, from the
beginning of diffserv.
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]
--------------------------------------------------------------------
