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

From: [email-masked]
Date: Wed, 29 Aug 2001 10:46:40 +0300

Brian E Carpenter wrote:
> [email-masked] wrote:
> > 
> > Robert,
> > 
> > Very well put! Just some additional thoughts:
> > 
> > - If diffserv WG so wants, it can even define a specific 
> (standard) DSCP
> > value to be used between domains to signify that the flow 
> label in the same
> > IP header has "diffserv semantics". This way the 
> classification could be
> > done the same for all source addresses (otherwise ingress 
> router would need
> > to know which source addresses use diffserv semantics for 
> the flow label?).
> 
> That's an interesting thought, but I think it doesn't work. 
> The egress router
> has to *know* that the flow label is in diffserv format, and 
> I think that
> requires some magic.
> 

Wouldn't the absence of intserv state for the flow at the domain egress be
the magic for this determination?

A related question: Flow label field is presumably end-to-end, i.e.
non-mutable. How can some random diffserv domain egress router know if the
flow label value should be honored or not (even if it had a specific format
for the PHB-ID)?

> > 
> > - If there is a diffserv relationship between a client and 
> an ISP, the
> > client could still use intserv for select flows by doing 
> intserv signaling,
> > which would explicitly tell the ISP that the associated 
> flow label does not
> > have any diffserv semantics.
> 
> Only for unencrypted traffic I think? The problem case is 
> encrypted traffic,
> where all you can "see" are the IP addresses and the flow 
> label. I think the
> intserv flow spec will be insufficient in that case.
> 

I thought the current definition of the MF-classifier in intserv would allow
usage of the flow label field for classification. At least this has been the
whole function of the flow label: to enable flow classification based on the
IPv6 header data only (e.g. even in the non-encrypted case IPv6 transport
headers should NEVER be used for flow classification). If the flow label is
not part of the intserv classifier specs, then maybe we need to revisit RSVP
(RSVPv6?). Or perhaps the starting NSIS work will make this happen?

	Jarno
--------------------------------------------------------------------
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: [email-masked]
Date: Wed, 29 Aug 2001 11:01:12 +0300

Brian E Carpenter wrote:
> > 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.
> 
> Exactly, since it can convey e2e semantics from the source.
> 
> > 
> > - 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.
> 
> Correct. The idea was that people could register PHB IDs with IANA to
> go beyond the formally standardized 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.
> 

My precise point was that *between domains* PHB-ID carries 6 bits of
information only (the standardized DSCP values). Any *local use* values
would not be used inter-domain, and any *experimental* value usage would
need bilateral agreements (perhaps as part of the SLAs), so for this info
(mapping from an *experimental* PHB-ID to the actual behavior definition) an
out-of-band signaling method (online or offline) exists already.

> > 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. 
> 
> 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.
> 

Hopefully the SLAs specify what treatment should be given to which packets.
It is not up to IETF to standardize redundant technologies just because a
"business decision says so".

In my opinion, you have not yet shown a convincing scenario, where the
proposed behavior aggregate usage of the IPv6 flow label field actually
provides something we don't already have. You should provide a concrete
example showing the relationships between the operators, who marks what
(end-to-end/hop-by-hop), how the traffic is policed etc.

> > 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.

Let's add to the end. "If a bilateral SLA doesn't state otherwise."

> 
> 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).

The whole discussion has been for the case *between operators*, or have I
missed something. With my amendment above, the above can easily be mandated
by IETF. The main motivation for any standardization is interoperability.
IMO what I said above would just facilitate interoperability (in case the
operators don't know better).

> > 
> > 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 :-)
> 
> This is not in our power.

"encouraging" doesn't need too much power, just good will :-)

	Jarno

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 29 Aug 2001 09:28:38 -0700

> > There are no stupid questions. Some of the pushback is
> > simply based on the fact that the diffserv model of QoS
> > is inherently broken because there is no end-to-end
> > immutable set of bits for local decisions to be based on.
> 
> This is a very unfair comment. Diffserv is just fine in the
> case of unencrypted traffic. It has a problem (and so does
> intserv I suspect) with tunnel or transport mode ESP.

ESP is just one of the cases in which "looking at the port numbers" does
not provide sufficient information to make an informed decision. There
are many examples that do not involve ESP, e.g. an audio stream can
carry different levels of hierarchical encoding on successive ports, an
HTTP transaction can carry a medical transaction just as well as
recreational content, a file transfer may be a virus update or a virus
propagation. At some point, the classification decision has to rely on
information provided by the source.

In fact, there is no contradiction between the "immutable" requirement
that Tony is advocating and Brian's "diffserv handle" requirement. In
the diffserv model, the actual classification is based on the 6
classifier bits; there is no context that this can be mutable, since
ISPs must be authorized to reclassify traffic. The reclassification is
based on information carried in the packet, part of which is the label
affixed by the source; making that label immutable is a good thing,
since it prevents intermediaries from removing the information that can
be used by a downstream router.

-- Christian Huitema

---

From: [email-masked]
Date: Wed, 29 Aug 2001 23:31:02 +0300

Brian,

Maybe Bob meant just IPv6 tunneled over IPv4, not protocol translation?

	Jarno

Brian E Carpenter wrote:
> Bob Hinden wrote:
> > 
> ..
> > I think you are going a bit far to suggest that the fate of Diffserv
> > depends on what the IPv6 w.g. does with the flow label 
> field.  I suspect
> > that Diffserv will live or die based on IPv4 usage.  Also, 
> as IPv6 is
> > deployed much of it will be initially carried over IPv4.  
> Any QoS solution
> > that is going to be end-to-end will have to deal with a mix 
> of native IPv6
> > and IPv4/IPv6 headers.
> 
> Indeed, and since I don't quite see how IPSEC and NAT-PT are going to 
> work together, the need that triggered this discussion (the need to
> classify ESP packets in the middle of the Internet) really 
> doesn't arise
> in the case of translated packets. The concern is for a 
> native IPv6 environment.
> 
>   Brian

---

From: [email-masked]
Date: Thu, 30 Aug 2001 00:05:26 +0300

Tony Hain wrote:
> > There is a basic, simple SLA/TCA, and the users pay today a basic 
> > monthly fee.
> 
> But there is no mechanism for the end user to say that he is 
> willing to pay Nx his normal rate *right-now* because it is 
> really important that this get done. It is also impossible to
> sort between business use of an app vs. recreational use. 
> Strict diffserv has a limited domain of applicability, and as 
> I said before it is a providers fantsyland because it allows 
> the provider complete control without giving any mechansim 
> for input or negotiation from the person paying the bill.
> 

An SLA between the user and the provider could do all this with diffserv.
You just mark the more expensive packets with a different DSCP, and you will
be charged accordingly, as specified in the SLA. To work in practice this
would probably need its own PHB-group definition (n price levels), and well
implemented support in the end system.

	Jarno

---

From: [email-masked]
Date: Thu, 30 Aug 2001 00:21:20 +0300

Christian,

I might be wrong, but it seems that a downstream (operator) router CANNOT
use end-to-end immutable information. If the policer in the 1st operators
domain concludes that the customer is not paying enough for the treatment
he's asking, the "treatment indicator" needs to be downgraded. If that is
not allowed, the only other option would be to drop the packet altogether.

	Jarno

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 29 Aug 2001 15:26:14 -0700

I believe you are wrong. On obvious counter-example comes if the sender
has no privilege with the sender's ISP, but the receiver has these
privileges. In that case, the packet is marked as "priority high,
traffic type X" by the sender; the sender ISP's rewrites that to
"priority standard, traffic type X"; the receiver's ISP rewrites to
"priority high, traffic type X."

By the way, many people seem to believe that diffserv necessarily ties
with monetary exchanges. That is not necessary, if for example you
implement "alternative best effort" and get 2 best effort classes, one
for "high throughput, low loss", and one for "low delay, possible
losses."

-- Christian Huitema

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, August 29, 2001 2:21 PM
> To: Christian Huitema; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: a), b), c), d), or e)
> 
> Christian,
>

---

From: [email-masked]
Date: Thu, 30 Aug 2001 02:12:01 +0300

> "priority high, traffic type X."

Assuming that the domain ingress would check the SLA with the eventual next
domain after the domain egress, in addition to the SLA with the immediate
traffic origin, yes. This in the diffserv specs?

Anyway, your example assumes existence of an indication for the traffic
type, that does not exist. If it would, it would open opportunities for some
interesting DoS attacks, wouldn't it?

Another way to a similar scenario would be for the receiver to arrange
partial path reservation from the ISP in question onwards with explicit
signaling. I'd guess GPRS with the radio bearer QoS extended to the GGSN
would suffice as an example. A variation of RSVP could do the same for any
IP terminal. I'd believe this will come up in NSIS, when it gets going. But
this would be flow specific, intserv-like stuff.

> for "high throughput, low loss", and one for "low delay, possible

This assumes that the service got from the 2 classes is equally useful (or
that the applications that can benefit from these different classes are
equally useful to the end users). Would not work if the other is clearly
more useful than the other. And even if both classes are equally useful, and
there is actual benefit of the 2 best effort classes, the operator's would
be fool not to try charge extra (maybe an extra $1/mo?) for offering this
choice. Customer retention can also be expressed in monetary terms.

People are willing to pay (more) for the more predictably successful
"dial-in experience" to their ISPs.

At least a year ago the phone operators in U.S. still charged $1/mo for
*tone dialing*... Could save by subscribing to pulse dial only :-)

I think that by definition, if there is differentiation to the user
experience, there needs to be monetary difference somewhere.

	Jarno

---

From: [email-masked]
Date: Fri, 31 Aug 2001 09:47:27 +0300

Mike,

I believe you misunderstood what I meant. To rephrase: The currently defined
RFC 2460 App.A semantics allows the IPv6 flow label field to be used for
intserv MF-classification, instead of any of the transport headers. In this
case the multi-field (MF) classifier would look only at the IP addresses and
the flow label. Intserv does not need to care about any of the headers above
the IP header, if the flow label is used and signaled end-to-end. With the
current flow label definition there are no additional privacy implications
raised by the use of the flow label in intserv signaling and classification.

Brian has repeatedly mentioned that intserv would have a problem with ESP.
With reference to RFC 2207 this is clearly not true (uses SPI instead of the
ports). Additionally, using the IPv6 Flow Label to label the flows for
intserv allows the intserv signaling implementation to be independent of the
IPsec policy in place (e.g. signaling would be the same regardless the IPsec
policy, don't need to refresh the intserv state when re-keying, etc.).

	Jarno

Michael Thomas wrote:
> 
> [email-masked] writes:
>  > Just some comments for clarifying some stuff that keeps coming up
>  > repeatedly:
>  > 
>  > Brian E Carpenter wrote:
>  > > 
>  > IPv4 intserv shares the same difficulty of doing 
> MF-classification with ESP.
>  > However, in IPv6 the flow label can be used in 
> MF-classification for intserv
>  > semantics, even when ESP is used.
> 
>    This is incorrect. RFC 2207 defines a way to classify 
>    ESP traffic for intserv *and* it doesn't compromise
>    privacy. What's being floated here for diffserv requires
>    that I compromise privacy in order to work, which I 
>    think is bogus.
> 
> 	    Mike
>