Subject: RE: a), b), c), d), or e)

From: [email-masked]
Date: Tue, 28 Aug 2001 11:53:51 +0300

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-masked]
> --------------------------------------------------------------------
> 
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Aug 2001 09:37:47 -0500

> proposed to replace the DSCP field on the domain boundaries.

Exactly, since it can convey e2e semantics from the source.

> *local use*, e.g. intra-domain) use more of the 16 bits.

Correct. The idea was that people could register PHB IDs with IANA to
go beyond the formally standardised ones. 

> - Since the PHB-ID carries only 6 bits of information between diffserv

No, the DSCP is limited to 6 bits; the PHB-ID has a full 16 bits.
The mapping to DSCP is a decision made by the classifier in an ingress
border router.

> then be understood by the receiving diffserv domain. 

It might be reasonable, but we can't assume it. This depends entirely
on the SLA between the two ISPs concerned and is a business decision.

> The egress could base

Impossible. This is not something the IETF can mandate, and in particular ISPs
are free to implement non-standard PHBs (e.g. multiple independent implementations
of EF, or more than four AF classes, or some proprietary PHB).
> actually use the recommended DSCP values intra-domain as well :-)

This is not in our power.
> behavior aggregate classification).

This is not a discussion one can have with ISPs. What they do in their
bilateral agreements is a private, confidential matter.

   Brian

---

From: Thomas Narten <[email-masked]>
Date: Tue, 28 Aug 2001 12:22:10 -0400

> go beyond the formally standardised ones.

Has anyone done so, or are you aware of any plans at the present time
to do this? (The IANA page doesn't seem to have any listed.)

I'm trying to understand if this is something that people feel is
useful today, or whether defining the Flow Label  is intended to
provide additional encouragement for folks to do so.

Thomas

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Aug 2001 11:51:34 -0500

> provide additional encouragement for folks to do so.

I don't believe that any have been registered yet. Frankly I'm not surprised,
since the communities expected to use the PHB ID first (bandwidth broker,
MPLS, ATM) are still busy working out how to handle the standardised PHBs.

Indeed, if this usage for the flow label is added, it might well be a stimulus,
but that is not my motivation :-)

  Brian