Now that I read the draft-conta-ipv6-flow-label-02.txt again in the context
of this discussion, few remarks:
- The draft discusses "diffserv MF-classifier" use for the flow label, while
what really is proposed is a diffserv behavior aggregate (BA) classification
based on standard, non-mappable PHB identifiers. Since DSCP is mappable to a
local convention (for whatever political reasons), now the flow label is
proposed to replace the DSCP field on the domain boundaries.
- RFC 3140 defines PHB-ID as 16 bits, out of which 6 bits are used in the
"standards action" defined PHBs. These 6 bits are the recommended bits for
the DSCP field by the PHB definition (that can be mapped locally to
different set of bits). If there is no local mapping (but the domain routers
are configured to understand and use the recommended DSCP values for each
supported PHB), the 6 bits in the PHB-ID are the same as the 6 bits in the
DSCP in the Traffic Class field. The other variant (*experimental* and
*local use*, e.g. intra-domain) use more of the 16 bits.
- Since the PHB-ID carries only 6 bits of information between diffserv
domains, it would seem entirely reasonable, that at diffserv domain egress,
all DSCPs are mapped to the equivalent recommended DSCP values, that will
then be understood by the receiving diffserv domain. The egress could base
the mapping to whatever MF-classification or just map from locally used
DSCPs.
So, as an alternative to make the IPv6 flow label NOT identify flows, I'd
propose the diffserv WG to specify that (for IPv6) a diffserv domain MUST
remark the DSCP value of the Traffic Class field at egress to use the
PHB-definition recommended ("standards action") DSCP value, including the
case that *local use* or *experimental* PHBs are mapped to the default PHB
('000000') at domain egress.
In addition to more efficient classification and policing on the domain
ingress, this could have a side effect of encouraging the operators to
actually use the recommended DSCP values intra-domain as well :-)
The only argument against this I have seen to date is that "operators
wanted" the DSCP bits to be locally mappable (and perhaps so that reverse
mapping back to the standard values may be hard?). Has there been any
discussion with these operators on the possibility that instead of agreeing
with their peers about the DSCP values to be used *at the domain boundaries*
(could still use locally mapped values intra-domain), they would base their
mutual SLAs on an end-to-end field set by the IP host originating the
traffic? IHO this is way different from the MF-classification discussed in
the diffserv specs (since the proposal in the draft is actually about a
behavior aggregate classification).
Jarno
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.?!? 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]
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
