Subject: RE: Higher level question about flow label

From: [email-masked]
Date: Fri, 24 Aug 2001 13:47:26 +0300

Christian,

I still believe that "bits are bits". As you pointed out, there is no
certainty that a packet to port 80 will carry HTTP. Therefore we should not
pretend to know. Any classification based on this "make believe" is
inherently flawed (IHO).

The DSCP (for diffserv) and address + flow label (for intserv) are all that
is needed for determining the right treatment for the packet.

Information theory wise, the port number stuff you propose is either
redundant or a mistake (the latter in the case of ESP with non-NULL
encryption).

The last thing the Internet needs is "content based charging" for transport,
or "good QoS for supported (read $$$) applications only", both scenarios
likely if the scheme you propose would be in place.

Then again, I might be wrong :-)

	Jarno

> -----Original Message-----
> From: ext Christian Huitema [mailto:[email-masked]]
> Sent: 23. elokuuta 2001 3:49
> To: Brian E Carpenter
> Cc: ipng
> Subject: RE: Higher level question about flow label
> 
> 
> > On Thu, Aug 16, 2001 at 08:44:59AM -0500, Brian E Carpenter wrote:
> > > I think the WG needs to decide once and for all whether the flow
> label
> > is
> > >    a) a CATNIP or MPLS-like routing handle
> > > or b) a QOS hint for intserv only
> > > or c) a QOS hint for intserv and diffserv
> > > or d) a waste of bits
> 
> I think that the most useful use is probably (c). Option (a) is not
> terribly interesting: if you want to do MPLS, just insert an MPLS
> header; MP in MPLS stands for multi-protocol, which means that MPLS is
> always going to have a "layer of indirection" for v4, v6, and whatever
> else the ISP wants to run on it. Option (b) really means "a set of
> random bits" and is not terribly useful either: it would require that
> the routers trusts the random generation in the hosts, which is not
> going to happen (the trust, I mean.) 
> 
> Option (c) really means "tell me something useful about the content of
> the packet so I can use it for classification." Suppose I 
> place here the
> port number that identifies the service, e.g. 25 for mail, 80 for web,
> etc., plus an indication of whether this is UDP or TCP. This plus the
> addresses would enable some easy filtering into intserv or diffserv
> classifications, without requiring that the router go deep into the
> header chain. It would enable easy traffic statistics. It 
> would be easy
> to implement for the host (pick the lowest of dest or source port.) It
> would work even if the packet is encrypted. We could reserve 
> values for
> specific traffics, e.g. RTP-audio, RTP-video. It would work even if we
> use ESP. From an information theory point of view, this looks 
> much more
> useful than either random bits or null values.
> 
> Indeed, the bits will have to be set by the host. But then, so are the
> port numbers. Nothing prevent cooperating hosts from running NFS over
> port 80... In fact, if the router is willing to inspect the 
> full header
> chain, it could rewrite the bits to a "trusted" value. Also, 
> some hosts
> may not be willing to provide the information, e.g. when they actually
> want to hide the nature of the encrypted traffic; these hosts 
> could use
> a null field, which would be classified to some default rule by the
> diffserv filters (you cannot have it both ways.)
> 
> Count my vote for (c).
> 
> -- 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: Alex Conta <[email-masked]>
Date: Mon, 27 Aug 2001 12:10:13 -0400

Jarno,

> is needed for determining the right treatment for the packet.

You're forcing the use of a subset of Diffserv on everybody. 

One MUST be able to use Diffserv with IPv6, at a not lesser extent than
Intserv with IPv6. 

This is even more so, when it does not cost anything, or much, as you
seemed to agree at one point.

> redundant or a mistake (the latter in the case of ESP with non-NULL

The port number is just a way to represent. Whether you use something
else, or not, it does not really matter. Do not get carried away in the
"other" semantics of the port number.

---

From: Alex Conta <[email-masked]>
Date: Mon, 27 Aug 2001 14:23:27 -0400

Steve Blake wrote:
> > 
> IPv6 supports Diffserv today in precisely the same way that IPv4 does.
>  

IPv6 has the flow label, and it has extension headers for more than just
IPsec, which IPv4 has not.
The flow label has a QoS purpose, which means precisely Intserv, and
Diffserv.

Regards,
Alex

---

From: Steve Blake <[email-masked]>
Date: Mon, 27 Aug 2001 12:45:46 -0400

Regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven L. Blake               <[email-masked]>
Ericsson IP Infrastructure                   919-472-9913

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 27 Aug 2001 12:09:04 -0700

> The flow label has a QoS purpose, which means precisely Intserv, and

While the original purpose of the proposal for the flow label may have 
been QoS, there is nothing restricting it to that usage. Brian's original 
note tainted this discussion by including intserv and diffserv in the 
list. I would argue that options b & c be replaced with:

an end-to-end immutable field which may provide a hint to the routers
that the sequence of packets with this marking are related

How the routers treat that hint is a local administration issue, and
outside the scope of any specific QoS model. The routers in the same
administrative domain of the originating host may treat those as 
intserv bits, while an intermediate ISP may ignore them, and at the 
same time the destination administrative domain may have enough 
information to treat them as modifiers to a diffserv infrastructure.
The point is they are simply a hint from the originator that packets
between the src/dst pair are related as far as it is concerned. The 
only one that may care is the destination host, so trying to invert 
the non-transitive relationship between the flow label and QoS models 
is simply wrong. The knowledge that the originator has related a set 
of packets may be of some use in building a QoS model, while the fact
that there is no single definition of QoS across administrative domains
means that it is impossible to use any single set of bits to create
that definition. 

Tony

---

From: Alex Conta <[email-masked]>
Date: Mon, 27 Aug 2001 16:28:00 -0400

Tony Hain wrote:
> 
> [...]The
> only one that may care is the destination host, 

could you please clarify/elaborate?

> so trying to invert
> is simply wrong. 

could you please clarify/elaborate?

> [...] while the fact

could you please clarify/elaborate?

Thanks,
Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Aug 2001 15:29:59 -0500

> IPv6 supports Diffserv today in precisely the same way that IPv4 does.

Indeed. The proposal on the table is to give IPv6 an edge in the case
of ESP packets. 

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Aug 2001 15:53:56 -0500

Tony,

> that the sequence of packets with this marking are related

I have to disagree very strongly with this. The proposal on the table
is much stronger, is directly based on the IETF's two QOS mechanisms,
is specific, and doesn't "taint" anything at all. Your text is vague, and
it prejudges the "immutability" which is more a consequence of the intserv
and proposed diffserv usages than a precondition. 

> outside the scope of any specific QoS model. 

Not at all. Our two QOS mechanisms are specific. There will be local
configuration issues for both diffserv and intserv, but the mechanisms
are universal and specific.

> The routers in the same

No. There is no meaningful way that the same flow label can serve both
intserv and diffserv. The mechanisms involved are just plain different.

> between the src/dst pair are related as far as it is concerned. The

Thet are actually more than a hint. In the proposal on the table,
there are three very specific statements that the flow label may make:

a) this {source address, flow label} identifies a specific microflow
b) this {flow label} identifies traffic requiring a specific per-hop bahavior
c) this {flow label = 0} identifies no QOS requirement

> only one that may care is the destination host, 

No, the destination host is the least likely system to care (although it might
do some inbound queue handling based on the flow label, this is certainly
not a baseline requirement).

> the non-transitive relationship between the flow label and QoS models

This statement defeats me. In the intserv case the flow label is an arbitrary
number and in the proposed diffserv case it is in a 1:1 relationship
with the QOS service class - that is why we chose the PHB ID option.
It's as transitive as they come.

> The knowledge that the originator has related a set
> of packets may be of some use in building a QoS model, 

Which QOS model? We have two, and they are different and require
different flow label semantics to work.

> while the fact

See RFC 3140. 

  Brian

---

From: Bob Hinden <[email-masked]>
Date: Mon, 27 Aug 2001 14:12:12 -0700

Alex,

>The flow label has a QoS purpose, which means precisely Intserv, and

There are other uses of flows (and possibly the flow label field) that have 
nothing to do with QOS.  It isn't limited to Intserv/Diffserv.

Bob

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 27 Aug 2001 15:35:21 -0700

Brian E Carpenter wrote:

>> ...
I am sorry, I did not intend to be vague. The proposed wording is intended
to be a precise definition for the field, and explicitly leaves out the 
letters Q, o, & S. 

> are universal and specific.
My original statement here was poorly worded. Yes QoS handling is very 
specific. My point was that the field is not strictly tied to QoS, and 
therefore the interpretation of the field is a local administration issue. 

> intserv and diffserv. The mechanisms involved are just plain 
Yes the mechanisms are different, but that does not mean they are exclusive.
It is not hard to imagine a site with rules for intserv use of the bits 
which slightly reduce the randomness of the flow label in a way that the 
traffic class field could be reconstructed by the destination site after 
the ISPs randomize it. This would of course require the destination site to 
know the rules the origin used, but nothing precludes that. Once 
reconstructed the destination site could make decisions based on the TC, 
while the origin used intserv based on the flow label.

> c) this {flow label = 0} identifies no QOS requirement
I didn't read the original message that way. In any case what I was 
trying to argue is a), strictly worded as it is here without any mention
of QoS handling, or implication that 'microflow' means intserv. All the 
originator is doing is telling anyone that cares to listen that the 
set of packets with this marking are related. 

> not a baseline requirement).
It might also want to use that field to demux flows over port 443
to enable an application to work through a firewall. The point is
it is an end-to-end immutable field that the source uses to identify
a specific set of packets as a flow.

> It's as transitive as they come.
From the viewpoint that the field is limited to use for QoS those are
hard relationships. My point was that QoS is not the only possible use
for the field. Overlaying a QoS interpretation is fine, but insisting
that all other interpretations are invalid is wrong.

> different flow label semantics to work.
I fail to understand how either would break if they simply intrepret the
flow label semantics as 'the source has identified this set of packtes
as related'. In either case there is an out-of-band mechansim to 
translate the value to a router task. The place you appear to be 
struggling is finding a standard mapping between a psuedo random value
and the Traffic Class field. Since the Traffic Class field is itself
a non-standard value (and effectivly psuedo random from an end-to-end
perspective) this seems pointless. 

> > means that it is impossible to use any single set of bits to create
From the above:
In a given network domain, there is a locally defined mapping between 
DSCP values and PHBs.  

Therefore my statement stands, there is no single definition of QoS
across administrative domains. 

Tony

---

From: Alex Conta <[email-masked]>
Date: Tue, 28 Aug 2001 11:17:06 -0400

Tony,

I answer, since you addressed this to me.

Tony Hain wrote:
> [...]
> been QoS, there is nothing restricting it to that usage. 
> 

I do not think that the Carpenter/Conta draft tries to exclude anything.
It tries to include Diffserv along Intserv. It is some of the Intserv
supporters that try to keep Diffserv out (excluded).

> 
> an end-to-end immutable field 

Requesting "immutability" makes sense only when a group of routers on
the path, in a routing domain for instance, are not capable of
preserving the meaning from ingress to egress of that domain, when and
if that
meaning is significant further downstream. If the routers are capable of
preserving the meaning, or there is no significance downstream, then
"mutability" is a non-issue. 

So, "immutable" has to be at the most conditional, and therefore not
part of the
main definition.

> which may provide a hint to the routers

If treating the hint is outside the scope of the QoS model, how do we
know how to treat the flow label bits for QoS? That, to me, excludes
QoS, and so it cannot be accepted.

> intserv bits, 

If the bits may be treated as intserv bits, the flow label must be in
the scope of the Intserv model. This contradicts your previous
statement.

Access routers could police/shape the traffic using Diffserv.

> while an intermediate ISP may ignore them, and at the

Are you saying that the flow label bits can be used by Diffserv? That's
fine, however, there is still a contradiction, in my view, with your 
previous "scope" statement.

> between the src/dst pair are related as far as it is concerned. 

This is an oversimplification, and vagueness, with no practical benefit. 
At this stage, I do not think, we can afford that.

> The

So, you provide in the flow label an additional hint to the destination
beside the pair of
ports that are in the host-to-host header? and that hint is using 20
bits of the main network layer header?

Oh NO, I do not think we can afford that for that purpose.

The IPv6 main header is very expensive real estate. Processing at wire
speed in the forwarding and QoS infrastructure is too, too critical,
that's where the flow label must be used. 

And then why to duplicate information that the destination host has full
access to anyway (ports, destination options, etc...)?

> [...]

Sorry, without clarification, I could not make sense out of the rest of
what you wrote, so I discarded.

Alex

---

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

Tony,

[lots deleted since I think the nub of our mutual misunderstanding is
in this bit]

> translate the value to a router task. 

But in the diffserv case, which is stateless (no signalling, no soft state)
the only out-of-band mechanism that works is if the flow label has
intrinsic semantics. The fact that the packet belongs to a class is
useless information on its own; you need to know what that class means,
and that can only be conveyed by an encoded field, since there is no
signalling or state.

> The place you appear to be 
> and the Traffic Class field. 

Yes, because it's impossible.

> Since the Traffic Class field is itself

No, it's the whole point: the classifier at a domain ingress must
choose an appropriate DSCP value to write into the TC field, and that
*requires* the classifier to interpret the semantics of some set of
fields in the packet header.
> across administrative domains. 

Indeed. The problem to be solved is choosing the most appropriate PHB and
DSCP for the given domain. The proposed solution is to use the globally
defined PHB ID to drive the classifier.  

   Brian

---

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

Alex Conta wrote:

> ... snip ...  It is some of the Intserv

I am not trying to exclude diffserv, just make the point that
diffserv already has a field to work with and is finding that
it can't get the job done without taking over another field
with imutable properties.

> "mutability" is a non-issue. 

Since the network can't possibly know if there is significance 
downstream (say at the end host), the field has to be imutable.

> This is an oversimplification, and vagueness, with no 

There is nothing vague about that. The originator is identifying
a set of packets as related. It would only be vague to a middle
box that has no context. In fact in many cases there is practical 
benifit in preventing the middle boxes from acquiring context.

> At this stage, I do not think, we can afford that.

At this point what we can't afford is redefining a field simply 
because the diffserv WG refused to create a set of end-to-end 
consistent bits. It is no surprise that people are finding it 
difficult to build hardware that will make consistent decisions 
when all the bits in the header are random. Since the diffserv 
mechanism is the one that needs a consistent set of bits for 
hardware acceleration, that WG should have provided them. Instead 
the DSCP is effectively a random set of bits with no global 
context, and we are being asked to redefine another set of bits 
to provide the necessary end-to-end consistency since the 
diffserv WG refuses to.

Tony

---

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

Brian,

> But in the diffserv case, which is stateless (no signalling, 

There is RFC2996 to fix this problem...

> and that can only be conveyed by an encoded field, since there is no

No argument about needing an immutable encoded field, just that 
it doesn't need to be the Flow Label. There is still the opportunity 
for the diffserv WG to create a standard set of encodings for the 
TC field that are immutable end-to-end, and as you note below that
is in process.

> fields in the packet header.

Or simply to expect that the value in the TC already is the 
classifier and configure the local PHBs accordingly.

> ... The proposed solution is to use 
> the globally

So why do we also need to usurp part of the FL field, when a 
global PHB will result in an end-to-end consistent TC field?

Tony

---

From: Steve Blake <[email-masked]>
Date: Tue, 28 Aug 2001 15:03:11 -0400

> to provide the necessary end-to-end consistency since the 

I agree with your conclusion, but I disagree with the assumptions you are
making about diffserv (for the sake of argument, say).

RFC2475 was built on the assumption of bilateral agreements between
peering providers, because that was the only model that had a hope
of being deployed.  The Diffserv flow-label proposal is trying to
invent an end-to-end, in-band QoS "signaling" mechanism to operate in
parallel with the hop-by-hop DSCP "signaling".  The only additional
in-band information that would be remotely useful for Diffserv would 
be a credit card account number.

Regards,

---

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

Steve Blake wrote:

> I agree with your conclusion, but I disagree with the assumptions 
> you are making about diffserv (for the sake of argument, say).
I assume you are talking about the WG not the protocol. :)

> of being deployed.  
But bi-lat's don't necessarily require mutability of the TC field. That
was simply a concession to those who wanted knobs to make it more 
difficult for the less skilled. Now we have a mechanism that only has
a hope of being deployed, but is operationally useless on a global 
scale because it lacks any context.

> The Diffserv flow-label proposal is trying to
> parallel with the hop-by-hop DSCP "signaling".  
Basically the hop-by-hop decisions have to be based on consistent
end-to-end semantics of a set of bits, but the TC field was allowed 
to be randomized so it is currently useless for that purpose. This 
is still fixable by locking down the PHBs and matching DSCPs, so 
there is no need for taking additional header bits.

> The only additional
Not if the proposed new end-to-end signaling is left as mutable. There 
will be a never-ending series of requests for bits until it is accepted 
that what is required is an end-to-end immutable set that the origin 
node uses to identify its intent for the packets, (in or out of band). 
The intervening networks will always make local decisions based on 
those bits, so there is no need to rewrite them at every domain boundary. 
All the TC field is used for now is an embedded MPLS type tag, so why is 
it embedded? Shouldn't it be the end-to-end consistent set of bits and 
let MPLS do the tagging it will undoubtedly do for TE purposes anyway?

Tony

---

From: Steve Blake <[email-masked]>
Date: Tue, 28 Aug 2001 17:27:40 -0400

> I assume you are talking about the WG not the protocol. :)

Actually, the opposite.  :)

> scale because it lacks any context.

Diffserv on a global scale is useless, in the sense that, I don't care
what QoS you want for your packet unless you are paying me directly,
or paying me via a proxy that I peer with, ad infinitum.

> there is no need for taking additional header bits.

There is no need to take additional header bits period, in my view,
irrespective of whether the hop-by-hop semantics of the DSCP are changed.

Diffserv does support some "flexibility" that in retrospect is more silly
than useful, IMHO, but even if the mapping of DHCP-to-PHB were fixed,
the PHBs have been defined in such a way that they have no obvious
relationship to a particular user's or application's QoS preferences, and
even if that were not the case, the DSCP still remains mutable, because a
network has to be able to protect it resources from upstream freeloaders.

> let MPLS do the tagging it will undoubtedly do for TE purposes anyway?

As I said, the only useful immutable information is a billing account 
number.  That could be propagated via signaling (Intserv), although that
does not appear to be a popular option these days.  There is no way we will
ever try to shoehorn that kind of information in-band into packets.  

The Diffserv model is to aggregate classification information at domain
boundaries, so that the billing model will scale.  The DSCP is the field
that conveys this information between boundaries.  It must remain mutable
to protect from freeloaders (as an alternative to simply discarding their
packets).  I haven't seen any evidence that six bits isn't adequate for 
this purpose.

We cannot rely on MPLS labeling because MPLS isn't pervasive (yet).

The argument that Diffserv critically depends on the ability of a
router to classify the application type in the middle of the network is
incorrect; the Diffserv model will work if this function is restricted
to the edges of the network, and then only because of the lack of
infrastructure which would allow the source host to mark the DSCP
meaningfully.

I would personally prefer that the flow label would remain an end-to-end
immutable field that uniquely identifies flows originated by a particular 
source node, though as a forwarding engine designer, it doesn't matter;
we will find the bits we need to find regardless.

Regards,

---

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

Tony,

...
> consistent bits. 

Please don't use this kind of language. As I just said on the other
thread, diffserv reached consensus (in 1998) on a completely self-
consistent model meeting the key requirements stated by ISPs. 

> It is no surprise that people are finding it
> when all the bits in the header are random. 

What on earth do you mean? The DSCP to PHB mapping is configured,
but there is nothing random involved. If you actually study the
diffserv MIB, you will discover just how structured it is. (You
won't actually find any PHBs in the MIB, since PHBs are just
composed from queues and schedulers).

> Since the diffserv
> hardware acceleration, 

No, it needs to examine header semantics at administrative domain
boundaries. That might or might not be a hardware based process,
depending on technology. But the core routers don't need to
examine header semantics.

> that WG should have provided them. Instead
> context, 

Again, there is nothing random about them, and the mapping is
configured via the MIB or some such mechanism.

> and we are being asked to redefine another set of bits

Again, it isn't a question of "refuses". See above.

   Brian

---

From: Alex Conta <[email-masked]>
Date: Tue, 28 Aug 2001 17:55:45 -0400

Tony Hain wrote:
> diffserv already has a field to work with

The DSCP field and its numbering space is not sufficient for everything
that one may want
Diffserv for.

Diffserv has two types of classifiers, the B-A, and M-F. For good
reasons, each achieving different purposes.

Intserv can use addresses, and ports as filter_spec(s) in both IPv4, and
IPv6. 
Diffserv can use addresses, ports, and protocol IDs, for M-F
classifiers, in both IPv4, 
and IPv6.

Intserv can use addresses and IPv6 flow labels in IPv6, where the flow
labels are replacing 
ports.

Diffserv could use addresses and IPv6 flow labels in IPv6, to replace
ports and protocol 
IDs in M-F classifiers.

> and is finding that it can't get the job done without taking over another field

It can get the job done, but less efficient than in IPv4, and that is
not because 
work done by the Diffserv WG.

If Intserv can take advantage of the flow label, and be more efficient,
since it can use
the functions that were designed for this in IPv6, why should Diffserv
not take advantage as well? You oppose that only because it has to share
the flow label space with Intserv?

If the flow label were to be used ala RFC 2460, the entire space from
00000 ot fffff would
be allocated to Intserv. 

If my customers, or just people in general, do not choose to use
Intserv/RSVP, but want to use Diffserv, with M-F classifiers, for them,
the flow label and its numbering space is a waste.

> downstream (say at the end host), the field has to be imutable.

Your assumption is wrong. The network can know, through various means,
which of course 
include signaling. 

Ad absurdum, if the routers in a domain, do not know, or there is no
mechanism to know, 
but they can  have a use of a mutable flow label, then they would work
together, and have the egress restore the original value when packets
leave the domain. 

My making the flow label an absolute immutable field, you would lose
this capability, as
well as potential for future development.

> There is nothing vague about that. 

It is vague in its final practical purpose. A definition devoid of
purpose makes little sense. It is like saying we define the TCP, and UDP
ports just for the sake of having some ports in the header.

> because the diffserv WG refused to create a set of end-to-end

You are missing the point. 

The Intserv, and Diffserv have not created sets of bits to be used for
Intserv classifiers, or Diffserv M-F classification purposes with IPv4.

IPv6 has the flow label, which is defined and advertised as an important
(QoS)
diffentiator. In reality besides being a differentiator, it is used to
compensate for the inefficiency introduced by the IPv6 "extensibility".

For people that do not want to use Intserv/RSVP, without adding flow
label support
for Diffserv, that advertized differentiator is just smoke, it does not
exist, while they pay the efficiency penalty of the "extensibility".

On one hand, you suggest this vague, no final purpose, definition of
flow labels, which 
is practically a waste of the bits, and on the other hand you oppose a
good practical use of those bits, just because there is an attempt to
structure them in a certain way.

> hardware acceleration, that WG should have provided them. 

That working group does not standardize the IPv6 headers.

> [..]

That "another set of bits" is already there. You just give them a use
for which they are there for, which is QoS, and a structure. 

Alex

---

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

> There is RFC2996 to fix this problem...

That only works up to the first diffserv domain on the traffic path.
As the packets enters a 2nd, 3rd etc. diffserv domain, the problem
reappears. By the way, the absence of signalling is a virtue, not a
problem, from the scaling viewpoint.

> TC field that are immutable end-to-end, and as you note below that

No it isn't. By construction, DSCPs are "SHOULDs" and are always mappable.
PHB IDs are meta-values.

> classifier and configure the local PHBs accordingly.

This is exactly what ISPs have always said they will not do in
the general case, although of course they will if the SLA
in place says so.
> global PHB will result in an end-to-end consistent TC field?

Because the diffserv architecture requires the option to
reclassify traffic, because that's what the ISPs say they need.

I don't like the word "usurp". If the flow label was already
standardised and in habitual use, it would be appropriate,
but then we wouldn't be having this conversation anyway. Since
it is not standardised, there is nothing to usurp.

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Aug 2001 17:01:13 -0500

Preamble: this is getting pretty far away from the core of the debate.
I'd like the chairs to make some consensus calls, because
we are going round in circles.

> scale because it lacks any context.

I think that is quite unproven. Specifically (apart from a few researchers)
the kind of thing I expect major ISPs to do with the flexibility is
to implement multiple instances of the standard PHBs, which requires them
to use additional DSCP values for the multiple instances. The context will
be provided by a QOS policy management system and their SLAs.

> is still fixable by locking down the PHBs and matching DSCPs, so

This is a dream. It isn't going to happen. I went through 
denial/anger/acceptance on this three years ago.

> there is no need for taking additional header bits.

Abolish IPSEC and I will agree with you.

> node uses to identify its intent for the packets, (in or out of band).

There is no request for a new mutable field. On the contrary, diffserv
classification needs something that is globally unique.

> it embedded? 

That's a *complete* mischaracterisation. It doesn't resemble an MPLS
tag in any shape or form. It's in the IP header becasue it is used to
drive schedulers for queues of IP packets.

> Shouldn't it be the end-to-end consistent set of bits and

MPLS is not the e2e protocol in the Internet, and is probably only
a passing phase anyway. Diffserv traffic will get mapped onto a variety
of hardware layers; but diffserv is about IP packet scheduling, not about
lower layer frame scheduling.

  Brian

---

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

> consistent model meeting the key requirements stated by ISPs. 

I did not mean to be inflammatory, I was just reacting to the statement
by Alex about what we can afford to do at this point in time. 

While the diffserv WG has a self-consistent model, it is incomplete
and in fact unworkable in the presence of IPsec and multiple domains.

> but there is nothing random involved.

From an end-to-end perspective it is completely random. Yes there
is structure within each domain, but there is no way to predict how 
each provider will set those bits, so one provider can't use the
settings from another as a basis for decisions. 

> Again, it isn't a question of "refuses". See above.

I understand there was a contingent of the WG that insisted on the 
current behavior, but in doing so they created a situation where the
WG refused to make static mappings for those bits a MUST. 

Tony

---

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

> work done by the Diffserv WG.

In fact, diffserv can't get the job done across multiple domains in 
the presence of ESP. There simply are no visible bits with well-known
semantics to base the decisions on. Allowing the DSCP to be mutable was
explicitly the work of the diffserv WG, and therein lies the reason you
are looking for another set of immutable bits.

> together, and have the egress restore the original value when packets

Talk about ambiguity, what is the point of rewriting the flow label 
only to restore it later? Even if you wanted to, where is the protocol
that communicates the value from edge to edge? 

> That working group does not standardize the IPv6 headers.

They wrote RFC 2474 didn't they. As far as I can tell that means they
are responsible for the content of the TS field.

Tony

---

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

> problem, from the scaling viewpoint.

The absence of signalling is not the virtue, limiting the points where
the signalling is interpreted is. Removing signalling explicitly kills
any hope that the endpoint is capable of expressing its willingness to
pay for enhanced services. Basically there can't be a sustainable QoS
business model that is strictly based on diffserv, because the person 
with the cash has no means to control which packets get which level of 
service. The whole diffserv effort was so overbiased by the provider 
viewpoint of limiting abuse that it forgot that there has to be some 
means for the originator to state intent and see value in return.

> reclassify traffic, because that's what the ISPs say they need.

But have they got any paying customers for that service? Or for that
matter any hope of having any? 

> it is not standardised, there is nothing to usurp.

I will grant you that we have no Standards in this space, but to 
the status of 2460 I believe it is standardized as:

A flow label is assigned to a flow by the flow's source node. New
flow labels must be chosen (pseudo-)randomly and uniformly from the
range 1 to FFFFF hex. 

All packets belonging to the same flow must be sent with the same
source address, destination address, and flow label.  

Tony

---

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

> Preamble: this is getting pretty far away from the core of the debate.

Actually I thought the threads were very focused on the topic.
Do we need to redefine the FL field to allow diffserv to have an
immutable field with well-known end-to-end semantics, or not? Since
the diffserv WG didn't want to use the field it was given that way
why should we give it part of another one?

If those are not the core of the debate I am really confused.

> we are going round in circles. 

Since the conversation is not widespread this may help spark further
input.

> classification needs something that is globally unique.

I agree with you about what diffserv needs, but Alex keeps insisting 
that those bits remain mutable. If that happens diffserv will have two
mutable fields and still won't work.

> drive schedulers for queues of IP packets.

Both are a set of bits that only have context within an administrative
domain, and both are used for identifying the outgoing packet queue in
the router. The only difference is that one gets added and stripped off 
at every domain boundary, while the other is simply overwritten. 

Tony

---

From: Alex Conta <[email-masked]>
Date: Tue, 28 Aug 2001 22:36:24 -0400

Tony, 

I asked for clarifications. You didn't respond. 
I am sorry, in their absence, I would repeat again, what 
I said based on what I understood you saying, and you were quite vague
in that sentence: 

I strongly believe, and am not the only one, please see earlier messages
in the thread, packet forwarding and QoS processing in line 
cards on routers at wire 
speed is too critical to afford the use of flow label in the network 
layer header, to pass duplicate information from source to destination, 
that has no network layer meaning, or use in the network.

Alex

---

From: Alex Conta <[email-masked]>
Date: Wed, 29 Aug 2001 00:21:23 -0400

> are looking for another set of immutable bits.

I think you are talking about tunnel mode ESP, and Brian talks about
transport 
mode ESP. 

Brian's reason to use the flow label is for M-F classification, with
transport mode 
ESP.  Ports and protocol ID, are encrypted, while BA classification, can
still
be done, since the DSCP is in clear.

The tunnel mode ESP is a completely different beast, I have not looked
at 
that in detail, since it is beyond the scope of the Carpenter/Conta
proposal.

> that communicates the value from edge to edge?

A model is there: MPLS label distribution, which includes RSVP-TE.

> are responsible for the content of the TS field.

Likely, Brian can answer this much better than I can, since I have not
been 
involved in the Diffserv architecture work.

To me it is simple:  I see the IPv6 main header divided into functions
for forwarding, 
and functions for QoS. The 8 bit TS is part of the QoS fields, and is
the Diffserv BA classification field, similar between IPv4, and IPv6 -
great similarity/compatibility achievement, from model, architecture,
specifications, to implementation in devices, and practical use by
providers, and providers' customers. 

The 20 bit flow label is also a QoS field, which up to the
Carpenter/Conta proposal 
was a field defined normatively for QoS, and non-normatively for
Intserv/RSVP. 
There is conceptual similarity between Intserv non-flow label based
classifiers, and Diffserv M-F classifiers. Intserv classifiers can use
the flow label, and so could the Diffserv M-F classifiers, in which case
they would share the 20 bit space.

It is late here, so please bear with me...

You seem to see the problem in terms of bit allocation.

You seem to say that the Diffserv architecture should accommodate all
its functions in 8 bits for IPv6, because the TS is all that DIffserv
would ever get, and that is because the 20 bits of the flow label, used
by Intserv, are too precious to share with Diffserv.

OK, so the alternative that you suggest, means to have the DIffserv WG
rework a completely different Diffserv model, mechanisms, architecture,
specifications which some are already on the standards track, IETF
marketing, etc...  for IPv6.

This means dropping, the model, architecture, mechanisms,
implementation  similarity/compatibility between IPv6 and IPv4, and
dropping the complete similarity or commonality of the user/provider,
and provider/provider model between IPv4, and IPv6, and all the other
implications.

Is that what you really mean?

Alex

Alex

---

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

> I said based on what I understood you saying, and you were quite vague

I thought I did respond. The use of the bits would only appear to 
be vague if a middle-box without context were looking at them. If
you will recall the fundamental principle of the Internet is its
end-to-end nature, so the fact that some bits only have meaning
between the endpoints is not surprising.

> that has no network layer meaning, or use in the network.

And there are probably more of us who strongly believe that there
must be header bits that have immutable context from end-to-end.
The network elements are not the drivers here, the endpoints are.
If we allow the middle boxes to control our actions we end up with
the POTS network, and loose the ability to deploy new and 
innovative applications.

Tony

---

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

> I think you are talking about tunnel mode ESP, and Brian talks about

I am not mixing them. Diffserv only works within a single domain 
when ESP is used, because in that context there is a hope that 
the SPI carries enough context for the first hop provider to 
construct the DSCP. Once the domain boundary is crossed that 
capability is lost so the next provider has no clue how to set 
the DSCP. If those were fixed bits end-to-end, the first hop 
could have set them and all the rest could process accordingly.

> ... Ports and protocol ID, are encrypted, while BA 
> classification, can still

But the point is that no provider will understand or trust the 
DSCP as it is passed between domains, so BA classification will
fail after the first provider, and it will even fail there if 
that provider doesn't trust the host to mark it correctly.

> and functions for QoS. 

You appear to have forgotten that the endpoints need to
communicate with each other. The header is also used for
that primary function, or the others will not matter.

> You seem to see the problem in terms of bit allocation.

That is not my point, and you are the one that keeps raising
the value of the bits... Anyway the point is that we are 
being asked to change an existing definition to accomidate
a capability that another WG really needs, but refused to
create for itself in the field it had to work with. Why 
should we do that?

> implementation  similarity/compatibility between IPv6 and IPv4

No in fact that is what your proposal does. IPv4 does not have
the flow label to fall back on, so your proposal makes the 
mechanisms different between the versions. All I am saying is 
that the diffserv WG should go back and define a set of DSCP
values with global context, then there would be no need for
modification of the flow label definition.

Tony

---

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

> fields in the packet header.

   I don't think this is quite right: you MAY set up a 
   classifier at the edge of your domain to remark packets,
   but it is not a requirement. You could simply believe
   that the packet is classified appropriately and police
   to the appropriate SLA and remark to the appropriate
   outbound traffic class. This allows for the obvious
   situation where I, on my own network, have an SLA
   with my upstream provider for x% EF traffic, and that
   it's completely my own business which traffic I chose
   to mark as EF. The upstream provider shouldn't be
   either required or even desired to remark the traffic;
   that's my problem. His job is only to police to our
   SLA.

   What you seem to want is a provider-centric
   model where you always know better than I do
   which traffic should be separated into which 
   buckets. That's *a* model, but certainly not
   the only model, and indeed as is painfully
   obvious here, suffers greatly from the
   middlebox syndrome as encyption vividly demonstrates.

	Mike

---

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

> the POTS network, and loose the ability to deploy new and

I agree, and you are right, we do not have to get to a place, where the
network controls everything.

In the same time, we have to be careful to not overload the main network
layer header with functions or information that are not critical to fast
header processing in the network.

I think with flexibility, and wisdom, we can accommodate any end-node
needs. IPv6 has this wonderful thing - we all know (-: - called
"destination options" headers that can carry information relevant to the
end-nodes, if that information is not pertinent to packet forwarding or
QoS in the network. There are also the transport and application
headers, which are just for end-node consumption.

For information that is pertinent, and critical to both network and end
nodes, for functions related to the network, we should make every effort
to include them in the main header.

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Aug 2001 16:13:59 -0500

Tony Hain wrote:
> service. 

Absolutely untrue. The customer's SLA drives the provider's QOS policy
configuration which drives the classifiers. There is a direct impact
of customer money on this. And it should recurse from ISP to ISP, assuming
every bilat inludes an SLA.

It is of course at the granularity of traffic aggregates, not flows.
> The whole diffserv effort was so overbiased by the provider

It's just as much the destination as the source, but the intent is
expressed in the SLA. Also, I agree with you: host marking is a Good Thing
and I could name some products that do it. Consistent SLAs allowing consistent
use of code points are also a Good Thing. But for scenarios without
these Good Things, I would like a pragmatic solution.
> matter any hope of having any?

I don't know what customers ISPs have, but I do know that diffserv
capability is getting into many products and management systems.
What I certainly don't know is whether people are signing diffserv-
savvy SLAs.

> source address, destination address, and flow label.

That's Appendix A, which the Area Director has stated is non-normative.

  Brian

---

From: Francis Dupont <[email-masked]>
Date: Fri, 31 Aug 2001 21:49:26 +0200

Tony, I am afraid that you are right. Diffserv seems to need
reclassification at some points in the backbone and 20 bits are
not enough to do the job... not speaking of the IPsec issue.
According to an old thread the extension header mechanism of IPv6
makes (re)classification at very high speed difficult, if we agree
flow labels with semantic don't provide a solution, what to do?

Regards

[email-masked]

PS: some random ideas:
 - classify the first packet of a flow, use the flow label for
   next packets in the same flow: does this scale to a large
   number of flows? Latency of the first packet?
 - introduce a new destination option with needed infos? Can help
   for packets with a deep chain of extensions but not efficient
   for the standard case? (note I'd like to get a good solution
   for non-standard cases or extensions will suffer from the same
   problem than IPv4 options)
--------------------------------------------------------------------
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: Fri, 31 Aug 2001 15:08:03 -0500

Unfortunately I think the extension header mechanism is probably
too heavy as Francis says, but I want to think a bit longer about
that (and re-read kre's last message and some of Jarno's messages).

   Brian

---

From: Francis Dupont <[email-masked]>
Date: Fri, 31 Aug 2001 22:47:33 +0200

In your previous mail you wrote:

=> this is heavy but we can do more with this than with 20 bits,
in fact we can do more with this than with protocol/ports (*)...
The basic idea is to make (still unknown) avantages greater than
(already known) drawbacks.

Regards

(*) I have two different kinds of ideas about this:
 - first I don't fully understand what ISPs will do with protocol/ports
   because SLAs are not signaling: rules will be very coarse like
   "remark TCP port 80 to lower than best effort"... Perhaps protocol/ports
   are not designed for classification (:-). Of course, to pack them into
   20 bits (or less!) won't make these field more useful!
 - if we use available bits with a better semantics both we need less
   (even less than 20 bits because we deal with macro flows in Diffserv
   but look at the last point) and we can do more with them, for instance
   code a stack of DSCPs (a good solution for the rewrite/restore issue).
 - a destination option (in a header just after the IPv6 header or
   the hop-by-hop/please-use-the-slow-path header) provides a lot of bits
   and is expandable, in fact it can (i.e. should) be expandable on the
   fly: a stack of annotations for classification? MTU is not a real issue
   because backbones have already larger MTUs than edge networks for
   other reasons, the last edge router just needs to cleanup the stack.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------