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

From: Francis Dupont <[email-masked]>
Date: Sat, 01 Sep 2001 19:22:07 +0200

Alex, perhaps I was unfair about the c) option.
I understood that you'd like to replace the MF classifier on
the 5/6 tuple (adresses, DS field, protocol, ports) which I'll call
the 5F classifier by a simpler MF classifier with the flow label
in place of protocol and ports. This cancels the efficiency issue
of the extension header chain of IPv6.

My first concern is the 5F reclassification is a bad idea because
an ACL-like classifier will never give what I want as an user.
This is too rigid, not real-time, ...

The second concern is with ESP: the 5F classifier wants to look at
bits I want to hide. No conciliation is possible, IPsec people
(like Michael) will *never* accept to reveal transport layer or
payload details for a 5F classifier.

This point raises a real question about the c) option: what will
be the content of a flow label with a diffserv semantic? There are
two kinds of proposals:
 - to pack some bits from protocol/ports into the flow label
   (A.1 or A.2 appendix of your I-D). This will make mapping
   of a 5F classifier to a flow label based one easy but
   the two previous concerns apply. I vote no for this
   interpretation of c).
 - to use an opaque value (a PHB ID as in 7.1.1 of your I-D
   is an obvious candidate) but this doesn't work if a ISP
   doesn't trust you:
    - there is no easy map from a 5F classifier
    - or the PHB is standard and doesn't provide more information
      than the DSCP, or it is not and only some ISPs can interpret it.
   This kind of flow label is an extension of the DS field, it doesn't
   match the requirements for the (broken) MF reclassification and
   is too short for advanced features (for instance a ISP should not
   rewrite it because it is hard to restore it).

I don't vote for or against the second interpretation of c) because
something is clearly broken somewhere. Tony claims that Diffserv is
broken and I believe he is right: at least the MF classifier stuff
has to be more understable... This is a ISP requirement, can ISP people
explain what they need?

Regards

[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: Michael Thomas <[email-masked]>
Date: Sat, 1 Sep 2001 12:24:11 -0700 (PDT)

Just as a point of clarification, I'm not
categorically against reclassification (though
I'll admit to being wary). What I don't like is
the idea that ESP protection of transport headers
and some diffserv scenarios desire to have them in
the clear are mutually exclusive. Placing some of
those headers into the flow label in a way that 
can be analyzed is still subverting the intent
of keeping the transport headers private and
effectively the same as transport friendly ESP
(though, IMO, inferior).

I believe that the way things are being formulated
here is mutually exclusive. The reason is that the
host who ESP-encapsulates the datagram has no clue
without signaling whether it should go the
transport friendly route or the private route.
What that probably means in practice is that
privacy will lose, and that would suck.

Like Francis, I think there is something
fundamentally broken here. I suspect that it is
the base assumption that middle boxen must always
have access to the transport headers. This is a
fundamental shift in the IP architecture, though
I'll admit that it's pretty much as common as dirt
with firewall filtering, NAT's, etc. If we really
want to go here, we should just embrace that
principle and fix the offending protocols. I don't
think I agree with such an architectural change,
but these half-baked attempts at having it both
ways are the worst of both worlds.

	 Mike

---

From: Alex Conta <[email-masked]>
Date: Tue, 04 Sep 2001 15:25:02 -0400

Michael Thomas wrote:
> 
> Just as a point of clarification, 
> [...]  Placing some of
> [...]
> [...]

If we do not loose sight of the fact that, with IP QoS, 
the network (Internet) infrastructure, that delivers the packets 
to destination, handles not only forwarding information, 
but als QoS information, then we would accept that 
the QoS information is in the same class, relative to privacy, with 
forwarding information. In light of that, criteria to use tunnel or 
transport ESP apply based on user needs.

Alex

---

From: Alex Conta <[email-masked]>
Date: Tue, 04 Sep 2001 16:34:17 -0400

> Alex, perhaps I was unfair about the c) option.

You were Francis.

> This is too rigid, not real-time, ...

It may not give you what you want as a user, but it would give me
what "I" (read my customers) want as user(s).
 
Remember, having a Intserv, and Diffserv use of the flow label gives
the user the option, and that is a good thing. 

> payload details for a 5F classifier. [...]
>
> Francis

Let's put religion aside.

Conceptually, with IP QoS, infrastructure devices delivering packets to 
destination, are processing forwarding and QoS information. 

As traffic between two end-nodes may have distinct QoS requirements, it 
is obvious that the information to be given to an infrastructure device
must provide the differentiation of the traffic between the two
end-nodes.
That information, by definition, is in some relationship with the
multiplexing 
of the communication between the two end-nodes, which is being realized
through the
transport (host-to-host) header information. At an extreme, that
information is the 
transport protocol and source and destination ports, themselves.

Since, with IP QoS, the QoS information is in the same class, relative
to privacy,
with the forwarding information, if one needs to apply full privacy to
QoS information, 
it will apply the same criteria as for forwarding information: use
tunnel ESP.

Regards,
Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 04 Sep 2001 15:22:26 -0500

There is no proposal to reveal port/protocol numbers
in the flow label field, for the simple reason that it's impossible;
there is no reversible hash of all those bits into 19. So the
idea fails even without the security argument (which is a
strong one too).

As for whether people believe in 5-tuple classification (for
non-encrypted traffic), it surely isn't an issue for this WG.
What Alex and I came here to discuss was doing better than
that with IPv6.

   Brian

---

From: Francis Dupont <[email-masked]>
Date: Wed, 05 Sep 2001 11:04:52 +0200

You were Francis.
   
=> I agree, c) is not a bad idea, the problem is with diffserv itself
(the MF re-classification on the 5/6 tuple or worse which:
 - has bad privacy/security implications
 - is hard to do at very high speed, even with IPv4
 - makes IPv6 slower than IPv4 because of the extension header chain
   (problem you try to fix))

    
=> I am not convinced because I have no control on random intermediate ISPs.
Perhaps we are using the term user for different things, my user is
an end-user, your user is a ISP?

=> because of its scalability problem, Intserv is usable only locally,
for instance on the first or last wireless segment between me and
my correspondent. But diffserv seems to have the same restriction,
ISPs that we are in business are first or last ISPs. Core transit ISPs
are pseudo-randomly (for us) chosen and if they re-classify my packets
I'd like to know what silly rules on the 5/6 tuple they use...
The only reasonable option is to see what are source and destination
ISPs (using BGP table for instance) and to remark packets according
to them.

   
=> security/privacy is a religion we can't fight (:-). I definitely don't
want to have to choose between QoS and security/privacy.

   
   
=> I disagree: your proposal is to drop diffserv QoS if I'd like to get
security/privacy. I can't accept this. As intserv has not this issue,
the problem seems to be in the QoS information, and how it can be used
by ISPs.
I have contracts with my first ISPs (and my correspondent with last ISPs)
so I can mark my packets with the desired QoS, ISPs will apply the QoS
(keep my packets, drop others :-) and send the bill to me.
This model doesn't work for core transit ISPs: in general I can't choose
them, in fact I don't know what they are. I have no trust in them,
I don't pay their bill, etc. And of course they have no trust in me,
nor in the bits I've put in the DS field of my packets. So any QoS
information I have put in my packets has no meaning...
In conclusion I have no relationship with core transit ISPs, they can
re-classify by packets on the 5/6 tuple or worse, this is only a crazy
way to slow down the core routers. I rely on the first/last ISPs to
have business relationships with core transit ISPs in order to get
a reasonable service, and core transit ISPs should use MF re-classifier
only on the 2/3 tuple (addresses/DS field). BTW IPv6 gets an advantage
over IPv4 because of its addressing (better aggregation: simpler prefix
matching on source and destination addresses).

So I propose to refocus the discussion on the real issue: what will be
in practice MF re-classifiers and what constraints will this imply?

Regards

---

From: Francis Dupont <[email-masked]>
Date: Wed, 05 Sep 2001 11:22:00 +0200

=> so you give up the appendix A of draft-conta-ipv6-flow-label-02.txt?
The diffserv flow label in proposition c) will be an extension of
the DS field with same kind of properties?

=> I'd like to get the head of the 5-tuple classification in the core (:-)!

=> I understand but I shan't support the c) option until the 5-tuple
re-classifier monster is killed.

Regards

---

From: Robert Elz <[email-masked]>
Date: Wed, 05 Sep 2001 16:27:31 +0700

Date:        Tue, 04 Sep 2001 16:34:17 -0400
    From:        Alex Conta <[email-masked]>
    Message-ID:  <[email-masked]>

  | Remember, having a Intserv, and Diffserv use of the flow label gives
  | the user the option, and that is a good thing.

Actually, no it isn't, the way it is being proposed anyway, it is
a horrible thing indeed.

It is certainly a good thing to allow people to decide whether they
want to use intserv, or diffserv - but we also have to recognise that
they're not likely to have a free choice in large numbers of cases.

That is, whether the end user uses intserv, or diffserv, will depend
upon what is supported between the source and destination of the packets,
not on which protocol the user happens to thing is best (or most
suitable for the particular traffic).

As described so far, that isn't a problem, as long as the user gets the
choice to use the protocol that will actually work, that's what is
important, right?

The problem comes because there's no guarantee which of intserv or
diffserv will be applicable to any particular network.  It is entirely
possible that both will occur between the two end points of any
connection.  What's more, aside from being extra work for the user
(the user's system) that shouldn't matter - the user should be able
to send packets with diffserv classifiers in it, after having requested
an intserv path from the intermediate systems that support it.

That's why taking the flow label, and saying "this packet is for intserv"
or "this packet is for diffserv" is wrong - because the packet might need
to be for both.

Now, I understand that solving the "how do I work with both intserv and
diffserv" problem is out of scope for basically everyone at the minute,
and when that is suggested, everyone just says "we're not doing that".
And that's fine - but we cannot have a solution to anything which by its
very nature means that a solution to that problem can never be obtained,
because users are forced to choose (per packet) whether intserv or
diffserv is to be applied to that packet - with no way at all to say "both".

Having a bit in the flow label that says "this is diffserv" or "this is
not diffserv" or "this is a microflow identifier (prng)" or "this is a
static classifier" (which amounts to the same thing) if forcing that
choice, and leaving no room at all for "both".   Everyone has to
be able to work with one format of flow label, otherwise we're forcing
choices that mean too many possibilities are excluded.   10 years from
now we might know enough about how this is actually used to do that, now
we simply don't.  Nothing more than guessing.

  | As traffic between two end-nodes may have distinct QoS requirements, it 
  | is obvious that the information to be given to an infrastructure device
  | must provide the differentiation of the traffic between the two
  | end-nodes.

Yes, this is obvious.

  | At an extreme, that information is the 
  | transport protocol and source and destination ports, themselves.

That's totally the wrong information, but it doesn't really matter, it
won't be available anyway - and what matters here anyway is not what the
actual information is, but that there needs to be some information.

There was very little direct reaction to my previous message (Brian's
need to think about it more was about it), but there seems to be some
suggestion that an extra header would be too heavyweight, and so be
too slow to handle.

I can't see how that can possibly be (given what you're willing to allow
now anyway) ... just imagine that the IPv6 header was 48 bytes long
instead of 40.   And instead of one bit to say diffserv or not, that
you seem willing to test, there are 8 bits that need to be set to a
particular value (sure that's more gates to do the test, but testing
8 bits for a particular value is one of the simpler pieces of logic to
design..., and is no slower than testing 1).

As long as those bits say that the diffserv QoS info is there, then it
would be at a fixed position relative to the start of the packet.
Just somewhere between byte 40 and 48 instead of somewhere between
byte 0 and 4.   Big deal.   To compensate for the extra delay while the
extra bits arrive, you get more information to use.

What's so heavyweight about that?   I wasn't proposing anything that would
require chasing header chains to find the data, and extracting it from some
arbitrary position (though diffserv seems able to do the rough equivalent
of that for IPv4 - note that the transport header might be buried within
several layers of IP in IP headers).

Just at the minute it seems to be (as an outsider) as if people on both
sides of this debate have become entrenched in their position, and rather
that looking for a solution that can work, are instead simply set on
making the solution that they originally conceived into the winner.

Please, everyone, back to the drawing board, come up with some solution
that is feasible, and can actually work.

kre

---

From: Francis Dupont <[email-masked]>
Date: Wed, 05 Sep 2001 12:46:38 +0200

=> in fact I'd like this idea, this is a good solution but I am afraid
that this is a good solution of a wrong problem...

Regards

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 Sep 2001 09:50:43 -0500

> the DS field with same kind of properties?

Sure, it was included as FYI.

> re-classifier monster is killed.

That is not the business of this WG and irrelevant to the issue of
using the flow label. It's also running code and I think out
of the hands of the IETF and in the hands of the market to decide.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 Sep 2001 10:03:24 -0500

Robert Elz wrote:
...
> connection.  

There are a couple of models for doing that in the ISSLL WG. Maybe 
they should be having this argument. From a quick glance, none
of those documents refer to the flow label.

> What's more, aside from being extra work for the user

That's why the "well known value/locally unique value" dichotomy seems
more hopeful. 

...
> making the solution that they originally conceived into the winner.

Not particularly. But I think we do need to find solutions that minimise
change. As has been said, people are pouring silicon.

     Brian

---

From: Robert Elz <[email-masked]>
Date: Wed, 05 Sep 2001 22:22:56 +0700

Date:        Wed, 05 Sep 2001 10:03:24 -0500
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

  | That's why the "well known value/locally unique value" dichotomy seems
  | more hopeful. 

But that means that a packet is one or the other, and hence inserv
(which needs a micro-flow ID, not a fixed classifier) or diffserv
(which needs a classifier, but no micro-flow ID), but never both.

How can that possibly allow a packet to flow through a local intserv
domain in my (end-user's net) and then through diffserv in the outside
ISPs, and then back into intserv processing again when it reaches the
destination net.

I don't know how to do that now, but I know I don't want to make it
impossible.   And given that we have ESP, that only the source/dest
nodes can decode, all we have left for anyone to look at is what we
put in the IPv6 header, and other headers before ESP.  At the minute
the only proposal I have seen is the flow label usage.  And that seems
to be being designed to preclude using more than one QoS paradigm (for
one particular packet).

  | Not particularly. But I think we do need to find solutions that minimise
  | change. As has been said, people are pouring silicon.

Minimise change because people are making hardware today must mean
leaving the flow label the way it is in 2460 (or making that text be
normative instead of an appendix).

Anything else is change.   If we can have change one way, and that is
acceptable, slightly different change must be acceptable too,.

kre

---

From: Michael Thomas <[email-masked]>
Date: Wed, 5 Sep 2001 12:36:51 -0700 (PDT)

With Intserv-like networks, you don't ever need to
reveal any L4+ headers. This is also true with
diffserv networks if you don't require
(re)classification, which is a perfectly
reasonable way to design a diffserv network. 

This entire controversy surrounds whether diffserv
networks which have interior routers do the
classification is legitimate. Considering that it
breaks a perfectly reasonable user desire --
privacy -- I'd say that's a pretty good reason
to question the base premise.

	    Mike

---

From: Alex Conta <[email-masked]>
Date: Thu, 06 Sep 2001 01:19:12 -0400

> (the MF re-classification on the 5/6 tuple or worse which:

I do not agree that there is a problem with Diffserv itself or with M-F
classifiers.

> [..]
> Core transit ISPs

No silly rules, just rules. I would like to know too, and I may learn
the standard rules but the proprietary rules, is much more difficult. 
Practically though, for most people, it would not really matter, as long 
as core providers provide the service people or people's access
providers 
pay for (on people's behalf).

> security/privacy. I can't accept this. 

You do not have to drop diffserv QoS.

Let's acknowledge first, that what is the most important is the
confidentiality of the application payload, i.e. the user's message. 

Hiding completely the fields of the transport header, or the fields of
the IP headers, that one may be worried about, does not eliminate the
use of forwarding and QoS information.
The tunnel header carries forwarding and QoS information that is
pertinent to the tunnel
(traffic). If the tunnel carries one flow, then that applies to one
flow. If it carries an aggregation of flows, it applies to that set of
flows.

> As intserv has not this issue,

By the way, RFC 2207 applies only to non-flow label based Intserv. So
your assertion is not true for the use of Intserv flow label.

Your 'has not this issue', or that the mechanism is perfect, applies in
general terms. In very specific terms, for instance, it is not clear to
me how an RFC 2207 classifier is able to distinguish one user's
micro-flows between two end-nodes, based on 4-tuple classification rule.

> (keep my packets, drop others :-) and send the bill to me.

For this case, if the providers have networks in which they use only
Diffserv, why not allow them to use the flow label with Diffserv?

> in practice MF re-classifiers and what constraints will this imply?

Let's not go on that path. We go in circles, and move the focus, when in
fact 
the problem is fundamentally very simple:

1. premises
       a. Intserv and Diffserv are two IP QoS models.
       b. Intserv classifiers are similar to Diffserv M-F classifiers
		(in fact in hardware, one can use the same engine) 
       c. the IPv6 flow label has a QoS purpose 
       d. the IPv6 flow label can be used with Intserv
		RFC 2207 states reason - more efficient access to header fields
2. conclusion 
       a. Diffserv should be able to use the IPv6 flow label, like
Intserv.
		based on same reasons - more efficient access to header fields.

Regards,
alex

---

From: Alex Conta <[email-masked]>
Date: Thu, 06 Sep 2001 01:19:54 -0400

> [email-masked]

In fact the c) option is not using the 5-tuple classifier. So I do not
understand
why you link them together.

But the M-F Diffserv classifier is not different than the Intserv data
path classifier.
It uses the same fields, with the same type of capability to represent
range of values by wildcarding some of the bits, or an entire field. 

How come you do not have a problem with the Intserv classifier?

Regards,
Alex

---

From: Alex Conta <[email-masked]>
Date: Thu, 06 Sep 2001 01:27:59 -0400

Kre,

Sorry for not answering your message earlier. I was on travel, and I
tackled, shorter messages first.

I left much of your text, which makes the message longer, but makes
easier
to follow the line of thought.

> suitable for the particular traffic).

Providers are routers/switches users, and they decide what to use in
their networks, i.e. in their routers/switches.

> choice to use the protocol that will actually work, that's what is

That's right. The "end-user" users, and "provider" users.

But it is not right to say that "because there is Intserv, that might
work, we must not allow Diffserv, that would also work".

> possible that both will occur between the two end points of any
 
As it is very possible that Diffserv will be used e2e. 

> or "this packet is for diffserv" is wrong - because the packet might need

You are right.

But "is wrong", in fact, applies to RFC 2460, appendix A, i.e. the PRN
number.
You are pointing in fact to one of the main reasons why there was a need
to 
define a flow label formatting, or value setting for Diffserv. That is
because 
RFC 2460 appendix A, through the PRN rule and some others, excludes
Diffserv.

> diffserv is to be applied to that packet - with no way at all to say "both".

No. In fact it was in our scope, Brian and I, and those who support c),
to have both Intserv, and Diffserv work. 

To make Intserv, and Diffserv flow labels work with the same flow label
value on the same sequence of packets is an additional requirement, but
is in my mind, a  subset, and it can be resolved, it is just working out 
the details. It may imply some restrictions, like a router cannot use
the 
same 3-tuple rule for both Diffserv and Intserv, if the QoS processing 
of the packet after classification is different, which most likely it
is.
 
Our proposal needs more work, we knew that -- to have both Intserv, and
Diffserv work with the same label, Brian and I acknowledged that.

But it is important to underline that "c)" does not exclude Intserv, "
b)" does exclude Diffserv.

In reality, nothing other than the using of a Pseudo Random Number (PRN)
rule, of RFC 2460, appendix A, prevents a node to signal a Diffserv
formatted label (ala our proposal) as part of a Intserv filter_spec.

>  Everyone has to

This is an important point. 

Earlier, we also got the point that a static separation of the label
space 
is not considered optimal, or acceptable by some people on the thread. I
didn't
mind working with the premise that the label space must not be
statically divided.

I would not mind to consider c) as it was, but with the extension that
flow label
is shared to the extent that 
a flow label value must work with both Diffserv and Intserv.

> actual information is, but that there needs to be some information.

You're right. That is in fact, exactly what I meant, which is why I said
"at an extreme".

> suggestion that an extra header would be too heavyweight, and so be

I am not sure if I answered that directly or indirectly. I may have also
missed your message. But you're right, it is too slow, too heavyweight.
In fact I was looking for the same efficiency for Diffserv, as that
given to Intserv by the flow label. Additionally...

> instead of 40.  

...Additionally, because it is the same field in the IPv6 main header,
for both Intserv, and Diffserv, it allows the use of the same
software/hardware/silicon classification engine core for both. 

> making the solution that they originally conceived into the winner.

It is interesting that you perceive it this way. 

I said it many times on this thread, or related threads, that in my
perception those who want "c)", like Brian, myself, Christian, and
others, are /looking for/seeking/ a "win-win" situation, that is,
Diffserv with no excluding of Intserv. 

Those who want "b)", in my perception, just want to exclude Diffserv
from using the flow label (at any cost), which is a "win-lose"
situation.

> kre

So, I take your pointing to  "c)" ,i.e. that is use of flow label by
both Intserv, 
and Diffserv, with the caveat of a flow label format & value that can be
used by both Intserv, and Diffserv.

Alex

---

From: Alex Conta <[email-masked]>
Date: Thu, 06 Sep 2001 01:29:42 -0400

> to be being designed to preclude using more than one QoS paradigm (for

I think that this can be done. In fact, INTServ, could use the current
Diffserv flow label 
as long as Intserv allows non-PRN numbers.

The only issue is that a host MUST NOT set the same label value for the
same pair of
source and destination to be used by one router for both Diffserv and
Intserv. 

Which is to say, that a router, MUST NOT have two identical
classification rules, in two distinct tables, one in the Intserv
classification table, one in the Diffserv classification table. This is
to say that one router MUST have a certain 3 tuple, containing a certain
flow label value, stored in a classification rule either by way of RSVP
(Intserv), or by way, of Configuration/etc... (Diffserv), but not by
both.

> normative instead of an appendix).

That is not acceptable because it excludes Diffserv. Something MUST be
done to have both, and than maximize that (as much as possible).

Alex

---

From: Robert Elz <[email-masked]>
Date: Thu, 06 Sep 2001 14:00:00 +0700

Date:        Thu, 06 Sep 2001 01:27:59 -0400
    From:        Alex Conta <[email-masked]>
    Message-ID:  <[email-masked]>

  | I left much of your text, which makes the message longer, but makes
  | easier to follow the line of thought.

I'm going to try to send one reply to your 2 replies to me, and because
your messages should be just before mine in everyone's mailboxes, and in
the archives, I'll delete most of the context, leaving just the parts I
am directly responding to.   (The first 2 messages in the References header
identify the 3 I am replying to directly, for anyone who needs to find them).

  | But it is not right to say that "because there is Intserv, that might
  | work, we must not allow Diffserv, that would also work".

I don't know who is saying that, but it isn't me.   There is some question
about how diffserv needs to be supported, but "not allow" certainly isn't
part of the answer.   Nor "not allow" some other new QoS protocol that
hasn't yet been invented.

  | That is because RFC 2460 appendix A, through the PRN rule and some others,
  | excludes Diffserv.

No, it doesn't allow diffserv type use of the flow label field.   That
isn't "excludes diffserv", just alters the way it should be used.

  | No. In fact it was in our scope, Brian and I, and those who support c),
  | to have both Intserv, and Diffserv work.

That would be good - nd if you can show me a plausible way it could be
done (and ideally, how other different schemes yet to be invented could
also be supported) then I think you'll find that much of the opposition
(from an IPv6 perspective, rather than perhaps internal to how diffserv
does, does not, or should, or should not, work, which is a different
issue entirely).

  | To make Intserv, and Diffserv flow labels work with the same flow label
  | value on the same sequence of packets is an additional requirement,

Perhaps, but I think an essential one, which hasn't been demonstrated yet.

  | is in my mind, a  subset, and it can be resolved, it is just working out 
  | the details.

Yes...

  | It may imply some restrictions, like a router cannot use the 
  | same 3-tuple rule for both Diffserv and Intserv, if the QoS processing 
  | of the packet after classification is different, which most likely it
  | is.

I'm not so worried about the same router wanting intserv & diffserv
classification of the same packet - that would be a pretty silly thing
to expect.   But different routers wanting to handle the packet using
different QoS schemes.

  | Our proposal needs more work, we knew that -- to have both Intserv, and
  | Diffserv work with the same label, Brian and I acknowledged that.

I think that needs to be done before anyone would consider changing the
flow label spec.  At the very least you would need a pretty convincing
argument that it can be done.

  | But it is important to underline that "c)" does not exclude Intserv, "

As described so far, if the flow label is formatted in the diffserv way,
it seems to me that it does, as a diffserv formatted packet carries the
means for packet classification, where for intserv, the packet needs to
carry the identifier of a previously setup classification scheme.  That
is, for any particular traffic type, the former will be a constant, and
the latter will not be.   That looks like "exclude" to me.   Unless you
can find some other way around that.

  | b)" does exclude Diffserv.

b excludes diffserv use of the flow label field, yes - but that's a
different thing than excludes diffserv.

  | In reality, nothing other than the using of a Pseudo Random Number (PRN)
  | rule, of RFC 2460, appendix A, prevents a node to signal a Diffserv
  | formatted label (ala our proposal) as part of a Intserv filter_spec.

No, it doesn't - but there's just one diffserv formatted label for any
particular traffic type, right?   It is basically a well known value
(otherwise it would be useless for diffserv classification).

As I understand intserv (which isn't a lot, nor diffserv), a static
value isn't very useful.

  | I didn't mind working with the premise that the label space must not be
  | statically divided.

If there's been a proposal which avoids that, I must have missed it.
Where was that?

  | I would not mind to consider c) as it was, but with the extension that
  | flow label is shared to the extent that 
  | a flow label value must work with both Diffserv and Intserv.

Fine - how?

  | In fact I was looking for the same efficiency for Diffserv, as that
  | given to Intserv by the flow label.

As I understand it, and do correct me if I'm wrong - that's not really
needed.   That is, by your own earlier argument, the flow label should be
used for packet forwarding in the fast path.  In diffserv as I understand
it, the bulk of the routers would never be looking at the classifier (the
thing you want to stick in the flow label).  Hence, it should not be there,
as it isn't being used for forwarding.   On the other hand, for intserv,
every router uses this value - it is truly in the fast path of forwarding,
and hence, by your own earlier argument, its value belongs in the flow label.

On the other hand, I also appreciate that the routers that do do diffserv
classification need to be able to process packets quickly as well, so the
format to be used for the classifier needs to be efficient enough to extract
for that subset of all the routers (what, 4 or 5 maybe in a path length of
30 or so?  - assuming diffserv is used everywhere).

[Quoted out of order, wrt getting the value from someplace else]:
  | I am not sure if I answered that directly or indirectly. I may have also
  | missed your message. But you're right, it is too slow, too heavyweight.

I wouldn't be right in that case, I would be wrong.  I don't believe that
it would be, I think you're not understanding just what it is that I was
proposing - but I will reply to that part of the other message stream
(the one that is off the list - which I did, as my original message
contained too much ignorance of what is actually required).

  | ...Additionally, because it is the same field in the IPv6 main header,
  | for both Intserv, and Diffserv, it allows the use of the same
  | software/hardware/silicon classification engine core for both.

That's a good point if it actually gains a lot.   I would have thought
that the classification being done, and how it is used, would differ
remarkably between the two, so as to negate that benefit.  But who knows,
I don't have much idea what is happening, perhaps I am completely wrong.

But I thought that diffserv was to use this value to access its database
of classification rules, and from that calculate a traffic class (I forget
the acronym you're using for this value now), and then set that in the
traffic class field for future routers in your domain, while simultaneously
using it to decide upon queueing (perhaps routing) strategy for the packet
(just like later routers will do).

On the other hand, intserv is using the value (long with addresses, etc)
to access its forwarding table to direct the packet along a path previously
established (queueing, etc...)   No access to the classification database,
that was done before, instead access to a totally different place.

So, while the silicon to actually get the field out of the packet might
be shared, that seems to me to be the easy part of all of this - after that
almost everything is different, until we finally have the "how do I process
this packet" - which has come from elsewhere (different in the two cases),
though it eventually will probably be processed the same way.

I would certainly like to hear from someone who has ever designed silicon to
actually process both intserv, and diffserv, and who has used, or could use,
the ability to share the flow label access to good benefit (something that
couldn't be essentially as easily done with the flow label elsewhere in
the packet).

  | I said it many times on this thread, or related threads, that in my
  | perception those who want "c)", like Brian, myself, Christian, and
  | others, are /looking for/seeking/ a "win-win" situation, that is,
  | Diffserv with no excluding of Intserv.

I would like that too.

  | Those who want "b)", in my perception, just want to exclude Diffserv
  | from using the flow label (at any cost), which is a "win-lose"
  | situation.

I think they're mostly wanting to make sure that the current uses of the
flow label aren't disadvantaged by its being given a static value, which
until now has never been really considered.  And I don't think it needs to
be a win-lose.

  | So, I take your pointing to  "c)" ,i.e. that is use of flow label by
  | both Intserv, 
  | and Diffserv, with the caveat of a flow label format & value that can be
  | used by both Intserv, and Diffserv.

Show us how that can be done.

  | I think that this can be done. In fact, INTServ, could use the current
  | Diffserv flow label as long as Intserv allows non-PRN numbers.

Since any value, considered alone, is just as much a random number as
any other value, using a number that happens to be identical to a
diffserv classifier must be OK for intserv.   For one flow.   For
the next flow however, intserv (as I understand it) would prefer a
different value - even for the same QoS request.  diffserv wants the
same value.   That's where it seems to get hard to me.

  | > Minimise change because people are making hardware today must mean
  | > leaving the flow label the way it is in 2460 (or making that text be
  | > normative instead of an appendix).

  | That is not acceptable because it excludes Diffserv. Something MUST be
  | done to have both, and than maximize that (as much as possible).

My comment there was a response to Brian's "minimise change" as a request,
which I suspect he intended as "minimise change to current thinking about
diffserv" but which when treated properly, really would mean exclude
diffserv from the flow label.  The point was that "minimise change" is not
what you need to be aiming for.

kre

---

From: Francis Dupont <[email-masked]>
Date: Thu, 06 Sep 2001 11:46:49 +0200

=> so the next version of the draft should be more accurate about
the draw backs of appendix A proposals (introduction talks about
positive and negative aspects but there is nothing/not enough thing
about negative aspects).

   using the flow label.

=> so I suggest in a previous mail to move this discussion to another list.

   It's also running code and I think out of the hands of the IETF and
   in the hands of the market to decide.
   
=> I disagree because I am not so trusting in the wisdom of the market.
Current diffserv specs are too neutral about misuses of 5F re-classifiers so:
 - IPsec users can get an unfair penalty
 - IPv6 users can get an unfair penalty
 - core router engineers have to find a way to implement 5F classification
   at very high speed (obviously a very hard task :-)
If we can not stop stupidity we should document it ASAP, perhaps if we did
that for NATs *in time* today the situation would be better.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Thu, 06 Sep 2001 18:14:54 +0200

=> I agree but where/how to fix this?

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Thu, 06 Sep 2001 19:36:29 +0200

=> I've done an assumption on the default rule (not known ports), you too.
If the default is not the worse QoS then to avoid to get the worse QoS
is too easy, I could already see that with the port 80 -> low priority
rule someone tried to apply here.

   
=> they don't need this. The PHB ID flow label extends a bit the range
of validity of marks I've put on my packets but they don't change something
for core transit ISPs. This is a partial improvement, a real fix needs
to fix the status of MF re-classification over the 5/6 tuple or worse
in the middle of the network.

   > in practice MF re-classifiers and what constraints will this imply?
   
   Let's not go on that path.

=> I disagree: this is the real problem.

   We go in circles, and move the focus, when in
   fact the problem is fundamentally very simple:
   
   1. premises

=> I disagree with 1b, Intserv classifiers are dynamic and they don't need
to be over the 5 tuple because of 1d.

=> I disagree: Intserv works on dynamically defined micro-flows,
Diffserv works on statically defined aggregates.

=> if you'd like to apply this argument you have to remove the possibility
to apply a MF classifier over the 5/6 tuple anywhere. Intserv does this
by 1b because signaling provides a 1-1 mapping between a slow MF classifier
over the 5 tuple and a fast MF classifier over addresses+flow label.
You can't do that with Intserv just because you don't know what are
the silly rules applied in the middle of the network: a priori you don't
know the characterization of aggregates so I can't see you can map them
to flow labels.
So IMHO the issue is really MF re-classifiers in core transit ISPs
(something which is not an IPv6 WG mailing list topic :-).

Regards

---

From: Francis Dupont <[email-masked]>
Date: Thu, 06 Sep 2001 19:47:25 +0200

> re-classifier monster is killed.
   
   In fact the c) option is not using the 5-tuple classifier.

=> in your question you didn't specify if c) uses it or not.

   So I do not understand why you link them together.

=> c) should be at least split in c)+PHB ID-like and c)+Appendix A-like.
I don't believe the first c) is a complete solution for diffserv,
and the second c) just triggers the issue with MF re-classifiers on the
5-tuple anywhere.

=> devices are the same, ways to use them are very different.

=> yes because I can use for instance flow labels in order to
reduce an Intserv 5F classifier to a simpler one (making the assumption
for the discussion that Intserv is usable in the core).

Regards

---

From: Michael Thomas <[email-masked]>
Date: Thu, 6 Sep 2001 10:57:33 -0700 (PDT)

> => I agree but where/how to fix this?

I'm not sure there's anything to be fixed. This
strikes me as the same sort of contradiction that
NAT's impose on the network. This is a zero sum
game; something loses.

		Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 06 Sep 2001 13:47:35 -0500

Michael, to be precise it is not interior routers, but ISP border
routers, that would reclassify. But it doesn't change the principle
of what you say.

Indeed, it is clear that users who wish to be protected against
anthing beyond source/destination traffic analysis cannot use 
the proposed flow-label diffserv mechanism. That's a user trade-off,
not a decision for the IETF to make.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org

"We shall need a number of efficient librarian types 
 to keep us in order." - Alan Turing, 1947.
--------------------------------------------------------------------
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: Thu, 06 Sep 2001 13:56:04 -0500

Robert Elz wrote:
...
> If there's been a proposal which avoids that, I must have missed it.
It's been hinted at in several messages; it will work if you can assert
that the same triple {source address, destination address, flow label} 
is never used in any router for both an intserv flow and a diffserv 
aggregate simultaneously. I am not yet convinced that this assertion
can be made. It will take some thought.

  Brian

---

From: Alex Conta <[email-masked]>
Date: Thu, 06 Sep 2001 21:36:03 -0400

Robert Elz wrote:
> No, it doesn't allow diffserv type use of the flow label field.   

That's correct.

> also be supported) [...]

The above "the same label" was meant "the same label space". As a
further clarification, 
it means to work on removing a static separation of the flow label
space.

> argument that it can be done.

Your statements suggest that any specification of the use of the flow
label with 
Diffserv must work with the use of the flow label by Intserv, and any
other possible 
schemes to be invented...

In principle, and I said this before with other words, I do not have
trouble with a standard in which both Intserv and Diffserv can share the
same label space, and 
therefore the same label.

But I should say that I am troubled, if the standard is not applied
fairly, and equally
on both sides.

Your statements above, and implicitly anything supporting them, I am
afraid, create a double standard, don't you think?

One, in which it is OK that the specification of the use of the flow
label with Intserv, 
in Appendix A of RFC 2460, which, by requesting the use of a
Pseudo-Random Number, 
excludes currently the use of the flow label by Diffserv, which back in
94-95, 97-98, was  "a possible scheme that could be invented in the
future".
 
The other, in which any specification for the use of the flow label with
Diffserv,
MUST work with a Intserv flow label, and anything that could be invented
in the future.
 
> can find some other way around that.

According to the proposal, there is a separation of label space. That
ensures
that the use of the flow label with Intserv, and Diffserv do not
intersect, and 
therefore, in light of the AD's clarifications regarding normative,
non-normative text,
there is not need to change "appendix A", in RFC 2460.

> As I understand intserv (which isn't a lot, nor diffserv), a static

Why not?

> needed. 

I correct you. 

> I wouldn't be right in that case, I would be wrong. 

I was answering your statement "but there seems to be some suggestion
that an extra header would be too heavyweight, and so be too slow to
handle"

So, you were right, there were such suggestions. But please do not
misunderstand me, 
if it is a good approach, please write it up.

> I don't believe that

I thought that as a Hop-by-Hop header option, only for Diffserv, it is
not going 
to provide the same efficiency as the flow label, a fixed size field at
a fixed 
offset in the main header, and the advantage of using the classification
engine 
for both Intserv and Diffserv. I replied to you in more detail, with my
observations, 
in a private message.

> I don't have much idea what is happening, perhaps I am completely wrong.

I think this was mentioned at least a couple of times, by a couple of
people, besides me, on adjacent threads, or this one, for instance Frank
Kastenholtz.

> the ability to share the flow label access to good benefit 

You just heard it (-:.

> until now has never been really considered.  

Even though we knew it does not really matter whether the flow label
value is PRN or not, it is exactly why Brian and I put out a proposal
that would not change the PRN rule for the Intserv use of flow label --
the proposal of a static separation of the flow label space. 

But again, I am quite concerned by the double standard being suggested,
and in fact, applied (see above).
 
> And I don't think it needs to
> be a win-lose.
> 

This is a very positive step.

> same value.   That's where it seems to get hard to me.

For Diffserv, for a different flow, between the same two end-nodes as
the previous 
flow, there is a need for a different flow label value. For a different
flow, between two end-nodes that are different than those of the
previous flow, the flow label value can be the same, or can be
different.

Alex

---

From: Alex Conta <[email-masked]>
Date: Thu, 06 Sep 2001 22:28:31 -0400

Francis Dupont wrote:
> => they don't need this.

This is your interpretation. This is needed wherever there is a Diffserv
router which does
M-F classification, whether access or edge.

>  The PHB ID flow label extends a bit the range
> for core transit ISPs. 

What the PHB ID flow label does is irrelevant, relative to the ability
to do an efficient M-F classification, using the same fast and efficient
classification engine as the one that can be used by Intserv. This
ability is what is relevant.

> This is a partial improvement, a real fix needs

As the resetting of a machinery to a fresh starting point, anywhere in
the network,
the M-F re-classification can be seen in fact, as part of the mechanisms
that helps Diffserv scale.

> => I disagree: this is the real problem.

It is not a problem at all. It is a feature -- please see above.

> to be over the 5 tuple because of 1d.

Dynamic or static is irrelevant to the control plane. Classification
rules have to be set
in a classification rules table, whether for a short duration, or long
duration. In fact
noone requires a Intserv flow state to be shorter than a certain time
interval, so it can be as long as a week, or a month. 

It is irrelevant to the data plane classification engine that processes
the packets, since
they process packets regardless of how long a certain classification
rule table entry is lived.

> Diffserv works on statically defined aggregates.

This has no relevance on the data plane classification engine - see
above.

The statically defined aggregates can have a fine granularity of one
application communication between two end nodes.

> know the characterization of aggregates so I can't see you can map them

I always assumed that the Diffserv flow label based MF classifier, will
not exclude the possibility of a 1-1 mapping between a slow classifier (
5-tuple) and a fast flow classifier (3-tuple). In fact that is one of
the essential reasons for the proposals.

> [email-masked]

I agree with completely, but since you brought it up, I responded.

Regards,
Alex

---

From: Alex Conta <[email-masked]>
Date: Thu, 06 Sep 2001 22:48:17 -0400

> => in your question you didn't specify if c) uses it or not.

It was related to flow label wasn't it? So it meant 3-tuple classifier.

> => devices are the same, ways to use them are very different.

The fact that the Intserv and Diffserv model are different, is
irrelevant to the classification engine.

> for the discussion that Intserv is usable in the core).

So you like that feature. So do we, and we would like to use with
Diffserv. 

That's exactly what our proposal is supposed to accomplish for Diffserv. 

And your voting b) and the argumentation against c), means in fact that
you do not 
allow us to accomplish that.

Regards,
Alex

---

From: Robert Elz <[email-masked]>
Date: Fri, 07 Sep 2001 18:44:18 +0700

Date:        Thu, 06 Sep 2001 21:36:03 -0400
    From:        Alex Conta <[email-masked]>
    Message-ID:  <[email-masked]>

  | > | Our proposal needs more work, we knew that -- to have both Intserv,
  | > | and Diffserv work with the same label, Brian and I acknowledged that.

  | The above "the same label" was meant "the same label space".

Then that's not good enough - they need to be able both work on the
exact same label.

  | As a further clarification, it means to work on removing a static
  | separation of the flow label space.

Since Christian has just proposed a compromise, which would embed that
static separation, that's nice to hear...   A unified space is all that
I think is reasonable.

  | Your statements suggest that any specification of the use of the flow
  | label with Diffserv must work with the use of the flow label by Intserv,
  | and any other possible  schemes to be invented...

Intserv is irrelevant to me ... I'd characterise my statements as more
along the lines of expecting that any proposed used of the flow label
be able to use it as it is defined.  If one user can adapt to the
definition that exists, and another cannot, well, then one is going to
have a seeming advantage over the other.   Live with it.

  | In principle, and I said this before with other words, I do not have
  | trouble with a standard in which both Intserv and Diffserv can share the
  | same label space, and therefore the same label.

It is no good to just share the label space, to be effective, they both
need to be able to use the same precise label (as one packet can only
carry one label, and it can pass through both diffserv and intserv
sections of the net - and perhaps others yet to be invented).

  | But I should say that I am troubled, if the standard is not applied
  | fairly, and equally on both sides.

Wah - mummy - its not fair, he has pink icecream, I want pink icecream too!!!
You're allergic to strawberries, they make you itch, and you don't like it.
I don't care, it's not fair, I want pink icecream too!!!

A fine argument from a 4 year old...

  | Your statements above, and implicitly anything supporting them, I am
  | afraid, create a double standard, don't you think?

No.

  | One, in which it is OK that the specification of the use of the flow
  | label with Intserv, in Appendix A of RFC 2460, which, by requesting
  | the use of a Pseudo-Random Number, excludes currently the use of the
  | flow label by Diffserv, which back in 94-95, 97-98, was  "a possible
  | scheme that could be invented in the future".

The flow label identifies flows,  it should be doing no more than that.
A PRNG is just fine for that.   Anyone is free to make use of that
identification for any purpose they can dream up.  Changing it however
is an entirely different thing.   No double standards at all.

  | According to the proposal, there is a separation of label space. That
  | ensures that the use of the flow label with Intserv, and Diffserv do not
  | intersect,

For me, that isn't good enough.   These aren't different choices, in which
you pick whichever one you like, and use the label that suits.   Rather,
you have to use the one that is used to actually classify the packets,
except there isn't just one - there can be many, so they all need to
work together.

  | > As I understand intserv (which isn't a lot, nor diffserv), a static
  | > value isn't very useful.
  | 
  | Why not?

I explained that off list.

  | > As I understand it, and do correct me if I'm wrong - that's not really
  | > needed. 
  | I correct you.

Again, off list, in an earlier reply, I explained why...

  | But please do not misunderstand me, 
  | if it is a good approach, please write it up.

Unfortunately, at the minute, I don't have time, I have other things
to do that are more urgent.   Further, it isn't for me to define how
diffserv (or intserv, or anyone else) should do their thing - I just
threw out a suggestion that I think would work just fine.   Again, off
list, I have tried to explain to you just how.

  | I thought that as a Hop-by-Hop header option, only for Diffserv, it is
  | not going to provide the same efficiency as the flow label,

Close enough, it is.

  | a fixed size field at a fixed offset in the main header,

That one it also is, absolutely.

  | and the advantage of using the classification engine

That one might take a little extra work, if it is appropriate at all.
I'm not the one to answer - the problem would be more or less that the
bits would come from two different places in the packet, one if you're
doing diffserv, a different one for intserv.   Whether that's a really
difficult problem to handle (in silicon, it is trivial in software) I'll
leave for someone else to answer.

  | for both Intserv and Diffserv. I replied to you in more detail, with my
  | observations, in a private message.

Yes, I replied...

  | Even though we knew it does not really matter whether the flow label
  | value is PRN or not, it is exactly why Brian and I put out a proposal
  | that would not change the PRN rule for the Intserv use of flow label --
  | the proposal of a static separation of the flow label space.

I'm not sure if I'm not being clear, or if you're just ignoring the
requests - Brian clearly understands what I am asking, and why.

Static separation isn't the answer to anything - that is the problem
that I am trying to avoid - the precise problem, almost the only problem.

kre

---

From: Francis Dupont <[email-masked]>
Date: Fri, 07 Sep 2001 19:30:50 +0200

=> I object: there is a real difference: today NATs are a fact,
diffserv is not yet deployed: we have still time to stop this
(optimistic point) but perhaps we have not the power to stop this
(pessimistic point).

Thanks

---

From: Michael Thomas <[email-masked]>
Date: Fri, 7 Sep 2001 11:07:04 -0700 (PDT)

> not a decision for the IETF to make.

   Moving the lose-lose situation to the user does
   not seem like a very useful recommendation. We
   shouldn't be in the business of letting end users
   decide which lossage due to bad architectural 
   assumptions is better. Foisting the NAT
   hackitecture on the world was bad enough and 
   is probably the single largest source of
   entropy we face; we shouldn't take this sort
   of thing lightly.

	    Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Sep 2001 14:31:08 -0500

>    entropy we face; we shouldn't take this sort

I don't take it lightly, but many users simply don't care about traffic
analysis risks and there is no argument for penalising them; the users
who do care will *inevitably* lose something in exchange for hiding
their traffic type; that is truly a zero-sum game.

  Brian