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

From: Keith Knightson <[email-masked]>
Date: Tue, 28 Aug 2001 12:04:55 -0400

Guys,

Why is it not possible to use  the field for different purposes if 
the purpose can be suitably identified by some included mechanism 
Christian has suggested. Some values being for "standardized" usages 
and a few reserved?

That way everyone could get what they want.

Or is this a stupid suggestion?

Keith Knightson

At 3:43 PM -0700 8/27/01, Christian Huitema wrote:
>
>Could we be a bit parcimonious and reserve a couple of header bits "for
>further use"? We don't seem to have a level of consensus in the group
>that people can guarantee that either a bunch of random bits, or a
>diffserv flow label, are absolutely the best thing since sliced bread.
>Not at the same level as the payload type or payload length, in any
>case.  It would be nice to be able to invent something like ECN in
>2010...
>
>Maybe we could make it something like 4 bits of "label type" and 16 bits
>of label value, defining then the possibilities for "0-0", "0-random"
>and "1-diffserv" -- whatever that means.
>
>-- Christian Huitema
>--------------------------------------------------------------------
>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 11:58:31 -0500

I don't think that is in the least stupid, but some people
seem to :-)

    Brian

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 28 Aug 2001 11:16:33 -0700

> Or is this a stupid suggestion?

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.
What we have on the table is a proposal to take over 
part of another field to create that set of bits, but
even that contains the argument that the bits should be
mutable. As soon as that is deployed and proven 
inadequate they will be back for another set of bits.
The diffserv WG should have defined a set of PHBs with
global context and mapped a set of DSCPs to those. It 
chose not to, and now to make products work people are
looking for another set of bits. That is the wrong 
process. The diffserv WG should go back and fix the
immutability problem they created.

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Aug 2001 16:25:29 -0500

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

> mutable. 

No it doesn't. They should be set at source. (But anyway, why
would it matter if they are mutable, since they aren't covered
by checksum? I'm not aware of a law of nature against mutable bits.)

> As soon as that is deployed and proven

There would indeed be the option of defining an IPv6 header
not covered by ESP for this. But I think that would raise traffic
analysis issues way beyond those raised by the current proposal.
Anyway, in this last sentence you have stopped arguing on the
merits.

> chose not to, 

No, that is in fact what we did, but at the specific insistence
of the ISPs active in the design of diffserv, we made all of
the mappings SHOULD instead of MUST. You want to ding the WG
for meeting a clearly stated key requirement of the principal
customer set?

> and now to make products work people are
> looking for another set of bits. 

er, try "to give IPv6 an advantage over IPv4 in the case of
encrypted traffic with a QOS requirement..." Products work just fine
the way things are. 

> That is the wrong

Immutablity isn't the problem. Encryption of the port and protocol
numbers is the problem. I could equally well say that IPSEC should
go back and fix the invisibility problem they created. What I am actually
saying is that this WG should go back and fix the ambiguity problem
created by the Appendix to RFC 2460.

    Brian

---

From: Alex Conta <[email-masked]>
Date: Tue, 28 Aug 2001 18:08:39 -0400

Tony Hain wrote:
> 
> [...] Some of the pushback is

I hate to say it, but your conclusion is grotesquely false. 
The Diffserv QOS model is not broken at all - I don't know 
how, where, and why you got that. 

For IPv4 M-F classification, Diffserv can use the well-known 5-tuple.
src, dst addresses, src, dst ports, and protocol ID.

For IPv6, it can use the same 5-tuple. However, using the same tuple
presents a number of problems, which the use of the flow label
alleviates.
That is in a similar fashion to the Intserv use of filter_specs, with
addresses, 
and ports, and addresses and flow labels.

> even that contains the argument that the bits should be

These are false conclusions. This is ignoring or ignorance, of some
basic facts. 

First the FLOW LABEL WAS DEFINED WITH MUTABILITY IN MIND - the 
checksum calculation (IPv6), and the IPv6 IPsec authentication skip the
flow label 
field, on purpose to allow en-route changes. 

You assume that the flow label MUST be immutable, because you base your 
thinking on an absolute model. An absolute model is closed, and
unnecessarily restrictive, not allowing future development or
enhancements. As the value of the flow label can change 
as long as the meaning is preserved, the model can be relative, and thus
be opened for future development.

> inadequate they will be back for another set of bits.

This is a grotesque ignoring of facts, and misleading statements.

The flow label value space is there (00000-fffff).

If Intserv is using the flow label ala RFC 2460, than the entire label
space is given to Intserv.
 
If Diffserv is using the flow label, and that is as legitimate as the
use by Intserv, it has to simply share the same label space. 

A simple way is to keep a static separation, and divide it in two.

> immutability problem they created.

What are you talking about? This seems to be a grotesque 
random mixing of things, and getting to false conclusions and 
misleading statements.

Alex

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 28 Aug 2001 17:06:28 -0700

> intserv I suspect) with tunnel or transport mode ESP. 

But that is the point. If IPsec had been widely deployed in the 
IPv4 Internet, diffserv would have been forced to fix the DSCP
end-to-end, because that would be the only alternative. 

> by checksum? I'm not aware of a law of nature against mutable bits.)

Speak to your co-author who keeps insisting that they are 
mutable. In any case, the point is that for diffserv to work there
has to be a visible set of bits that are immutable end-to-end
with well-known semantics. Currently that is the protocol/port, 
simply because ESP wasn't in widespread use. In IPv6 we assume 
it will be, so diffserv needs another set of bits that have an 
immutable well-known end-to-end semantic.

> for meeting a clearly stated key requirement of the principal

In this case yes, because that requirement results in an 
inoperable state when security is applied. RFC 2475 starts the 
discussion about IPsec interactions, but only from the perspective
of protecting the DSCP. It misses the point that when ESP is in
use there is no visible set of bits to base decisions on for 
each domain to set the DSCP. The only set of bits there is left
to work with is the SPI, and the semantics of that are only
known between the endpoints unless signalled via RSVP.

> Products work just fine the way things are. 

In fact that is a false statement because those products can't 
work today if one tries to use an encrypted channel. 

> go back and fix the invisibility problem they created. 

That is a specific feature. There are many times when you don't
want traffic analysis done on the ports in use and number or sequence 
of packets between them. 

> What I am actually

No argument, but the only ambiguity I see is the comment about 
control protocols. The rest of the text is very clear. 

Tony

---

From: Alex Conta <[email-masked]>
Date: Tue, 28 Aug 2001 21:16:14 -0400

Tony Hain wrote:
> > [...] (But anyway, why
> with well-known semantics. 

I do insist on the distinction between the bits in the field, and the
meaning carried by the bits. So let me clarify this once more, for the
last time.

The bits in the field are mutable, they are "read/write". Checksum, and
authentication
skip them. It was very wise that the WG decided and did it so.

The meaning of the Diffserv flow label bits is immutable. 

There seem to be a mixing of the two, and an insisting on the
immutability of the bits, on your side. But I think in reality, you care
about the immutability of the meaning of the bits. That is the essence,
and one should not care of what happens with the bits, as long as the
meaning is preserved, which is the point I am trying to get across,
perhaps not clearly enough. I hope it is clearer now.

> [...]
.  It misses the point that when ESP is in
> known between the endpoints unless signalled via RSVP.

You are pointing to tunnel mode ESP, and not transport mode ESP. 

> > go back and fix the invisibility problem they created.

Brian refers to transport mode ESP.

> [...]

Alex

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 28 Aug 2001 18:17:37 -0700

> how, where, and why you got that. 

How does it work if I am encrypting my traffic (independent of
protocol version)? On top of that the diffserv model provides 
no control to the originator of the packets, and that is the
source of the money which makes a business model work. Yes there
is a technical definition for diffserv QoS, but there is no 
sustainable business and operational model which includes the
source of the packets & money. A strict diffserv network is a 
providers fantasy land. There must be a mechanism for the 
endpoint to inject intent or there will be no reason to pay.

> thinking on an absolute model. 

No, I base my thinking on the fact that for diffserv to work 
there has to be a visisble set of immutable bits with well-known 
end-to-end semantics. Otherwise each provider can't figure out
which PHB is appropriate. 

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 28 Aug 2001 18:25:34 -0700

Alex Conta wrote:

> The bits in the field are mutable, they are "read/write". 
...
> The meaning of the Diffserv flow label bits is immutable. 

This makes no sense... Those are the same bits, so they have
to be one or the other. Since you are promoting a diffserv
usage, I have to assume you intend them to be immutable
end-to-end with a well known semantic, but you keep insisting 
they are mutable. As long as the TC field is mutable, there
has to be another one that is visible and immutable. 

Tony

---

From: Alex Conta <[email-masked]>
Date: Wed, 29 Aug 2001 01:01:36 -0400

> has to be another one that is visible and immutable.

Let's take an example. 

Let's say flow label value 50, is RT traffic between A and B.

C, D, and E are routers between A, and B. Between A, and C, the RT
traffic to B, has flow
label 50. At router C, the value of 50 changes to 60, and it stays that
way, to E, where it is changed back from 60 to 50.

Between C and E, the meaning was the same, as between A, and C, and E,
and B, that is
the RT traffic between A and B.

The flow label bits were mutable, the meaning was immutable. 

Alex

---

From: Alex Conta <[email-masked]>
Date: Wed, 29 Aug 2001 01:09:28 -0400

Tony Hain wrote:
> protocol version)? 

In transport mode ESP, the BA part works, in fact better than Intserv. 
The MF part has the same issues as Intserv.

In tunnel mode ESP, the MF Diffserv and Intserv face both the same
problems. 

So it would seem that both Intserv, and Diffserv face problems with ESP,
and so
no QoS model gets a free ride, except Diffserv BA with transport mode
ESP.

> [...] A strict diffserv network is a
 
There is little experience with IP QoS billing. But how about FR and ATM
services, where PVCs do not give users any more control than Diffserv,
and various levels of QoS and billing are available.

How about Internet access networks. A billing model existed and worked,
when the Internet access was based on analog modems, and you had the
choice between per minute charge or unlimited service charge. It works
today when some of the Internet access is done with DSL, or Cable. There
is a basic, simple SLA/TCA, and the users pay today a basic monthly fee.
I see no reason, why that would not work with Diffserv, with a few QoS
levels, and policing, and shaping, which would not be different
conceptually from the FR or ATM model.

> [..]

What you are saying is absolutely right.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 29 Aug 2001 10:01:03 -0700 (PDT)

> You are pointing to tunnel mode ESP, and not transport mode ESP. 

   Wrong. Everything at L4+ is encrypted with transport
   mode ESP. The only difference between tunnel and
   transport is the visibility of the inner IP
   addresses.

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 29 Aug 2001 10:15:02 -0700 (PDT)

> src, dst addresses, src, dst ports, and protocol ID.

   The problem is that the 5-tuple is exactly *one* kind
   of definition of a uflow. RFC 2207 defines another kind
   which instead of requiring IPsec to conform to RSVP's
   desire for a 5-tuple, defines another kind of
   uflow based on SRC,DST,SPI instead. This does not
   compromise the privacy of the flow itself since what
   the SPI represents is opaque to the classifier. What
   you are proposing is that that opaqueness is bogus
   and that I should always reveal the 5 tuple for 
   all to see.

   I disagree. If there's lossage here, we should
   err on the side of privacy. What you all are
   proposing effectively renders ESP protection of
   transport headers a dead letter if you want
   diffserv QoS.

		Mike

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 29 Aug 2001 10:35:13 -0700

> The flow label bits were mutable, the meaning was immutable. 

And exactly how did C tell E that it would need to remark the packet
to a particular value, or even know that it should do that, or who to
tell? If you are assuming all the routers are all within the same 
domain, then yes, you can replace the entire header with 12 if every 
exit router knows that 12 means put a header on that exactly matches 
the original. The point is that every administrative domain and the
destination will be looking at the same set of bits, not how some 
intermediate domain chooses to mangle packets.

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 29 Aug 2001 10:55:47 -0700

Alex Conta wrote:

> There is little experience with IP QoS billing. 

And that will continue until people figure out that a real-time
modification to an SLA structure is required for the end user
to perceive enough value to be willing to pay.

> But how about FR and ATM

Hop-by-hop labeled circuit services are exactly what MPLS 
provides, but Brian felt I was being unfair by characterizing 
diffserv that way. If a user is going to bother to get QoS 
from the Internet, it will have to provide more capability
than F/R or ATM, or it will have to be significantly cheaper.
Since I don't see the latter happening because diffserv is
too labor intensive, I can only expect we will get more
capability. If all you are offering is to match capability
Internet QoS will go nowhere.

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

> conceptually from the FR or ATM model.

True; see above.

Tony

> -----Original Message-----
> From: [mailto:[email-masked]]
> Sent: Tuesday, August 28, 2001 10:09 PM
> To: ALH-IETF
> Cc: Brian E Carpenter; ipng
> Subject: Re: a), b), c), d), or e)
> 
> 
> 
> 
> Tony Hain wrote:
> > 
> >
> today when some of the Internet access is done with DSL, or 
> Cable. 
> 
> > [..]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Aug 2001 15:14:30 -0500

I gave myself 24 hours off from this thread to draw breath. Here are
comments on a bunch of points from various people.

Tony Hain wrote:
...
> end-to-end, because that would be the only alternative.

I can only repeat that diffserv did fix the the DSCP values
but only with a SHOULD. My private opinion is that in the end the
ISPs will need to settle down to using the recommended values across
domain boundaries, but what they do in their bilats or within their 
domains is not something the IETF can dictate.

... 
> >(But anyway, why

Yes, and I think I disagree with him :-)

> In any case, the point is that for diffserv to work there

Well, Alex is correct to the extent that "immutable" is not an 
absolute requirement; "globally defined" is necessary and sufficient.
But as just stated, I prefer immutable.

> inoperable state when security is applied. 

Not really. It is quite operable if the SLA in place at each
domain boundary recognises the upstream DSCP value (see my
first comment in this message). The case that isn't covered
is ESP packets with no such SLA, and the result will be
that those packets get default QOS. If we don't find a solution
for that case, it doesn't break diffserv.

...
> want traffic analysis done on the ports in use and number or sequence

I agree. Traffic analysis concerns could be a show stopper for paranoid
users.

Alex Conta wrote:
...
> The flow label bits were mutable, the meaning was immutable.

Yes, it *could* work that way but I would argue against it - I'd much rather
keep it simple and have the flow label immutable.

[email-masked] wrote:
...
> > 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?

That's an interesting thought. 
  if flow label != 0
     and there is no intserv state
  then try diffserv classification

This needs a little thought but it looks hopeful to me.

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

All diffserv classifiers require configuration. This would mean configuring
a classifier to look for (say)

    Destination IP = Big Customer X
    Source IP = *
    Flow Label = 12345
 
This is a new form of diffserv classifier. Alex has a draft ready to ship
on this, but we decided to wait. Since "12345" would be a globally defined,
well known value, it is just built into the QOS policy repository of any
ISP that wants to support it. (This is what Tony thinks should be done
with the DSCP values.) 

...
> 
> I thought the current definition of the MF-classifier in intserv would allow
> usage of the flow label field for classification. 

Yes, except that RFC 2460 does not describe this in normative text.

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

Correct. This is the point that Tony argues right at the top of this message,
with my reply. There is some non-IETF work on signalling for this, but
the real world solution today is off-line SLAs. 

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

I really don't understand that comment. We have to aim for simplicity,
but we also have to solve real world problems. Telling the ISPs what
they are allowed to put in theirs SLAs isn't an option.
> 
> 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.

There is no new scenario here; the scenario is an absolutely standard
diffserv scenario with multiple ISPs on the path, with traffic conditioning
at every ISP boundary. What we don't have (with ESP) is the ability
to perform full traffic conditioning at those boundaries. 

Michael Thomas wrote:
> 
>    Sorry if this is redundant; it's been a hard thread
>    to keep up with.

Oh really? :-)

...
>    I've got what may be a pertinent question: do the re-classifiers
>    require actual knowledge of the contents of the encrypted headers,
>    or do they just require the ability to differentiate the unique
>    flows associated with a particular DSCP?

It's the former; if an ISP chooses to disbelieve the upstream ISP,
and re-classify the traffic, the semantics of the transport
header are exactly the information of interest.

> 
>    If it's the former, I think I object to requiring a node to
>    _have_ to reveal information (quite valuable information, if
>    you consider it) in order to obtain QoS. 

Indeed, I think this is a basic trade-off: to ask for QOS in the
absence of both signalling and SLAs, you have to reveal something.
The security question is whether revealing a PHB ID is acceptable.
It would allow an intruder to figure out how much traffic of
which kind Bob is sending to Mary, but there is less detail
than port/protocol numbers would give.

Or to put it another way, if your level of paranoia prevents you
from revealing a PHB ID, then you have three choices:
a) accept default QOS
b) use IntServ
c) ensure that all ISPs on the path have the right kind of SLA

>    At the very least,
>    how is a non-signaled diffserv host to know whether it
>    should or should not insert the revealing information into
>    the flow label? If the answer is that it always has to do
>    that, you have effectively defeated one of the useful
>    protections of ESP. This would be very bad.

I think this would have to be configured by local policy
(an interesting blend of security and QOS policy).

>  > > 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.
> 
>    I'm afraid that this makes no sense at all. 

The point is that the diffserv low level scheduling mechanisms are
driven entirely by the 6-bit DSCP field and that is the only
thing that core routers look at. That's what we mean when we
say diffserv is blind to microflows. The edge classifiers are
also very unlikely to be microflow based; although they use 5-tuple
classifiers, we expect the addresses and ports to be ranges or wild 
cards in most cases. In fact it would be quite unusual for a
diffserv classifier to look for a specific microflow rather
than a large class of microflows.

...
>  > 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.
> 
>    The current proposed lossage involves ESP over UDP.
>    In fact, that would probably provide you with what
>    you need for both v4 and v6.

Only in a limited sense, because the actual port and protocol values
will be hidden. Diffserv would work just fine, but all ESP/UDP packets
would be treated the same. 

[email-masked] wrote:
...
> For the proposed diffserv usage the flow label should be mutable to enable
> policing and aggregation. The point is that the flow label should NOT be
> locally mappable, it MUST always contain a standardized value, or it's
> semantics must be signaled (ála intserv).

As I noted above, that is a sufficient solution, but I don't think
mutability is necessary; when a domain wants to aggregate it can use
the diffserv code point to do that.

...
> It may be that diffserv cannot be changed NOT to allow local mapping any
> more, but where are these ISPs NOW?

They went away when RFC 2474 was published, literally saying "we got what
we want." Just recently we have got some ISP people back in diffserv,
but I haven't seen any attempt to rediscuss the mapping issue, which is
of course very deep in all implementations and in the MIB.

...

> Another problem is the MF-classification defined by the diffserv: How long
> you think it takes for the SLAs to be updated end-to-end (or more precisely,
> hop-by-hop), when two consenting hosts switch to SCTP instead of TCP? 

The SLAs and local policies are database and human driven. They need to anticipate
all ports etc to be used in advance. 

...
> I hope that if we'll have the flow label support for what Brian is asking
> (standard, non-mappable behavior aggregates), he'll promise to remove the
> MF-classifiers peeking into transport headers from the diffserv specs :-)
> (also from the non-ESP case).

That's not going to happen.

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

This can be done at the DSCP level (mark the packet for best effort). There
really is no need to change anything else.

Tony Hain wrote:
...
>  The operators are finding that making
> the DSCP completely random has resulted in a useless technology.

It isn't random, come on. It's locally configured. If operators
want values that cross domain boundaries, they either use the
recommended values, write an SLA, or both. This isn't hard.

...
> I was being very careful not to use the 5-tuple
> because the src/dst addresses are mutable thanks
> to NAT. The only end-to-end consistent bits are
> the protocol & port, and the flow label.

In this case I don't think NATted addresses are a problem at all.
The addresses (both source and destination) are both meaningful
within a given domain - even Net 10 addresses are meaningful within
their own domain - and MF classifiers are configured within a given
domain too. Mutable addresses seem to be a problem for intserv since
they are signalled in FlowSpecs, but not for diffserv.

   Brian

---

From: Robert Elz <[email-masked]>
Date: Fri, 31 Aug 2001 17:53:29 +0700

Date:        Thu, 30 Aug 2001 15:14:30 -0500
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

  | I gave myself 24 hours off from this thread to draw breath. Here are
  | comments on a bunch of points from various people.

I have taken longer than that, while trying to figure out what is
really going on here.

I think I have a better understanding now, so here are some more
opinions, this time  little less uninformed...

  | My private opinion is that in the end the
  | ISPs will need to settle down to using the recommended values across
  | domain boundaries, but what they do in their bilats or within their
  | domains is not something the IETF can dictate.

You keep saying this, in one form of words or other - and it is obviously
true.  Nor would we want to.   On the other hand, we can certainly constrain
the sensible options - we do that all the time with the protocols and
mechanisms we create.  A lot of that seems invisible, it is just a part
of the flora that doesn't stand out, because it has all been there for so
long that people just accept it as a natural part of life, and not to
be worried about - accept it, and deal with it.   But all kinds of things
have been invented by the IETF (and other groups - IEEE, ISO, etc) that
place all kinds of constraints upon what is sensible to agree, as do
politicians and lawyers (though their constraints tend to have different
kinds of effects if ignored).

To give some semi-relevant examples .. IEEE (and or DIX before them)
constrained ethernet frames to 1500(++) bytes: that constrains packet
sizes that are passing between ISPs.   They may prefer larger ones (less
switching), and they might like to write agreements that demand larger
ones - but they don't, because that would be stupid, and everyone knows that.

Even closer to this discussion, the IPv4 and IPv6 headers have fixed sized
fields (different ones) into which this QoS information can be placed.
The IETF imposed those limits, there's no natural or legal restriction
that forced them.  It was just a judgement call on how much space could be
afforded, and how best to divide that among competing uses.  Again, the
ISPs (and in this case, diffserv WG) are just accepting those limits, and
dealing with them as best can be done.  They might want to be able to have
64K different packet classifications, but they can't - there simply aren't
enough bits provided for that, so they make do with less.

We can do more of this if the arguments for imposing more constraints
are accepted by the relevant WG, and if we do, the ISPs will just need
to deal with those constraints in their agreements.

This is not specifying what the ISPs can agree with each other, which
we can't, and wouldn't anyway, do, just designing the protocols that
they happen to be agreeing with each other about...

  | Yes, except that RFC 2460 does not describe this in normative text.

Part of this discussion is to whether or not anything about the flow label
should be fixed now for all time, or whether it should remain in its
current state (for a while at least).

My read on what I have seen here is that there isn't yet enough agreement
about what should go there that ipngwg should change the current status
of that field - just leave it exactly as it is.

I certainly don't consider it unthinkable for IPv6 to continue with a
bunch of more or less undefined bits - I don't consider very much at all
as unthinkable - doing that tends to bias your options way too much,
and lead to missing other viable solutions.

  | It's the former; if an ISP chooses to disbelieve the upstream ISP,
  | and re-classify the traffic, the semantics of the transport
  | header are exactly the information of interest.

No they're not.   There is nothing at all in any transport header of
relevance that contains anything in any way related to QoS.

This guessing based upon port numbers is simply absurd - and simply
leads to people doing weird machinations on port numbers because they
can predict what effects that will have upon the network in the middle.
That's not what port numbers were ever for.

It also doesn't work - many packet flows that should get special QoS
attention are between random port numbers at each end, totally unpredictable
until the after the rendezvous and connection has been established.
Should DNS SRV records start being used for more services, you'll see
even more of that - port number classification is a crock that simply
has to be abandoned.

What's more, it is absolutely no business of the ISPs what port numbers,
or for that matter, what transport protocol, I happen to be using to
communicate with my peers.  That is entirely between me and them.
With ESP, and especially with IPv6, none of that information will be
available, and that's a good thing.  Making it available again by
sticking the same information (even in a reduced form) in some unprotected
header is simply wrong.

On the other hand, if I want some special forwarding processes (QoS)
applied to my packets, I certainly have to be willing to provide that
information.  Whether I calculate from port numbers, or just because
this particular web page is one I want real fast (even though it is the
same port number, same server, as that other web page I don't care
about nearly as much), is none of the ISPs business.  Nor is it of
the IETFs.

For intserv, as I understand it, I do this using RSVP, I communicate
my needs, and indicate how the packets will be labelled so the routers
can properly process them (provided they're willing, I'm prepared to
pay if required, etc...)

For diffserv, there's no out of band signalling, so every packet needs
to be labelled so it can get the correct processing.  That (as can
intserv as I understand it) be done with no mutable header bits at all.
The sender could simply provide a standard classification label, the
ISP could choose to process it or not (at every router, though one would
assume using a common distributed configuration).  No need to rewrite
anything.

But because there are mutable bits, the decision is to use them to speed
processing at intermediate nodes - with only the border routers between
ISPs (or ISP/client) actually looking at the user's provided classification,
and everything between simply trusting the value (DSCP) set by the
border routers, and doing its packet processing based upon that value.

Had there been no mutable bits that would never have been possible, and
things would simply have to have been done the other way - it is of course
still possible to pretend the bits are immutable, and process them that
way (whatever the IPv6 protocol actually requires).  But I see the
attraction for using them (one mutable bit "this value is to be trusted,
or not" and a value set by the sender would really be enough though).

  | Indeed, I think this is a basic trade-off: to ask for QOS in the
  | absence of both signalling and SLAs, you have to reveal something.

Yes, I have to reveal the QoS I want.  No more, no less.   There cannot
be an absence of signalling, I suspect you mean an absence of out of
band signalling - but that's largely irrelevant.  I have to provide the
information somewhere, sometime, no question about that.

  | Or to put it another way, if your level of paranoia prevents you
  | from revealing a PHB ID, then you have three choices:
  | a) accept default QOS
  | b) use IntServ
  | c) ensure that all ISPs on the path have the right kind of SLA

d) Adopt a QOS model that takes in-band defined signalling which carries
only the QoS desired.  Nothing extra.   That is all that is required.

There was something Alex said (I think) a couple of times, which I think I
agree with ... that is, the IPv6 basic header should contain only data
that is necessary to packet forwarding - this is the thing processed by
the fast path, and shouldn't be having other stuff thrown in there which
isn't related to that process.

That I think is what dooms the proposals to add PHB ID values into the
flow label - they're not needed for fast path processing, they only
get used at ingress/egress routers, where the header is (possibly)
going to be changed by rewriting the DSCP, and where it seems that
you're willing to poke into transport headers to find values of
interest.  While it is possible in some cases to process all of this
quite quickly - it isn't the basic packet forwarding operations that
the IPv6 header should be supporting.

On the other hand, the flow identifier (micro-flow if you like), whether
it is being used for intserv, or just to allow routers to quickly find
the likely forwarding information (quick key to a CAM lookup) is most
definitely fast path material.  It needs to be there for that, and it
needs to be optimised for that.  That is, whether or not the packet might
also be passing through some diffserv domains, and getting diffserv
processing along part of the path.

So, if we are going to be moving the flow label definition anywhere into
the normative text, the definition I would be happy with at the minute is
exactly the one which currently exists.

Now, I can imagine you wondering ... "higher up he agreed that we
need to have QoS data available to diffserv, but now the only place to
put it has just been eliminated as a possibility - contradiction..."

Not at all, rather, false premise.  The flow label isn't the only place
that diffserv QoS signalling can be placed.  It is just where you have
currently decided is available to dump it.   It is already clear that for
IPv4 there's no flow label available, so you're willing to go trolling
through transport headers to find the (inappropriate anyway, but never mind)
information you need.  For IPv6 you could do the same, except that ESP
gets in the way (it will for IPv4 as well, in time), and the nature of
the header chains makes the transport headers harder to locate, so you'd
prefer not to have to do that.

But IPv6 has another way - you can simply request that the sender add
a new header (more on that in a second), require it to appear immediately
after the hop-by-hop options (if any, or the IPv6 header otherwise) for
it to be effective anyway (ie: you look that far, and assume default
processing if the header doesn't appear there).  In this header you can
stick all the QoS classification information you're ever going to need.
That can even look like a transport protocol port number combination if
you like - just don't expect the port numbers (or even transport protocol)
to have any relationship at all with the ones the transport protocol or
its ports that are actually being used.   I'll pick values that generate
the QoS effects that I desire (which might sometimes be a 1::1 mapping
from the value actually being used, but also might not be).

What's more, you can also have this header carry an independent QoS request
from the receiver (returned to the sender in an earlier reply packet) so that
ISPs with a relationship with the recipient of the packet can classify
it according to the receiver's view of how the packet ought be processed,
instead of the senders.   If the receiver starts getting packets with
classifications it never authorised, it can just reset the connection,
and if that doesn't work to halt it - then it is just another DoS attack
to track and kill (since none of this data is authenticated, such attacks
will be a fact of life, however the classification is done).

Now to the header.  The obvious clean way would be to define a new QoS
header type, and stick the data in there.  That way it contains exactly
what is needed, and can be structured so as to be easy for hardware to
access the fields (it could even carry authentication information if
anyone believed that it would ever be actually used).

However, adding a new header requires (at least) the source and
destination to be able to handle that header, and requiring it to
be in this particular position also means it would need to be understood
by every router that might ever process a routing header.

If IPv6 were widely deployed, that would be unimplementable - but since it
isn't really yet, it is still feasible, though only barely I suspect.

The other way is simply to carry this in a destination options header,
and require that header to be immediately after hop by hop options (in
other contexts we have discussed the possibility of headers appearing
in "weird" orders, and I believe, agreed that support for that is needed).

Then, a QoS option can be defined (unknown options can be skipped, so
this is easier than a new header) to carry the necessary data.  The format
wouldn't be as flexible, or nice, as a new QoS header, but it is easier
to get implemented (still have a possible problem with intermediate
routers, and routing headers, but there is much less of that to worry
about).   The formatting can be made rigid - the QoS option could be
required to be the first option in this particular header, etc, so it
would still be easy for hardware to check for its presence, and extract
the values (the only variable, in either case, is whether a hop by hop
options header is present, and hardware needs to deal with that decision
already - if it is, probably the packet will be slow path shunted, if
it isn't, then the QoS data would be in a fixed position relative to the
IPv6 header - or not there at all).

Might something along these lines possibly satisfy everyone?

kre