Subject: Higher level question about flow label

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Aug 2001 08:45:21 -0500

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

We can get back to the details once we have a consensus on this.

  Brian
--------------------------------------------------------------------
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: Bob Hinden <[email-masked]>
Date: Thu, 16 Aug 2001 15:33:17 -0700

Brian,

>or c) a QOS hint for intserv and diffserv

I would like to suggest another choice:

     e) a set of bits we hold in reserve for the future

I don't think that we have enough experience to pick between a), b), or c) 
now, and think that something might come up in the future where 28 bits in 
the IPv6 header might be very useful.  This might not have anything to do 
with QOS.

Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Aug 2001 09:15:19 -0500

>      e) a set of bits we hold in reserve for the future

A couple of people have said this in private mail too. I agree;
making it a "reserved MBZ" field is the practical alternative
to "a waste of bits".

> the IPv6 header might be very useful.  This might not have anything to do

I think you mean 20 bits. The traffic class octet is fully standardised by 
diffserv and ECN. 

The problem with this is that the text we have today effectively selects 
option b), since it endorses the pseudo-random value. If we do nothing,
we have effectively chosen the intserv-only usage. That's why I started
this thread.

   Brian

---

From: Francis Dupont <[email-masked]>
Date: Fri, 17 Aug 2001 16:21:16 +0200

In your previous mail you wrote:

=> I vote for b)

Regards

[email-masked]

PS: Intserv is not 100% dead because there is an environment (wireless)
where to get more bandwidth is really expensive (in Europe at least :-).
PPS: there is another usage: flow-based switching for fast routing
but I don't believe this really helps (petabit router vendors?)
--------------------------------------------------------------------
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: Tim Chown <[email-masked]>
Date: Fri, 17 Aug 2001 17:22:23 +0100 (BST)

>    or c) a QOS hint for intserv and diffserv

So would you vote to mandate that the field is non-mutable in transit too?

tim

---

From: Bob Hinden <[email-masked]>
Date: Fri, 17 Aug 2001 09:47:34 -0700

Brian,

>I think you mean 20 bits. The traffic class octet is fully standardised by

Yes, my error.  I was not suggesting we change the traffic class field.

>we have effectively chosen the intserv-only usage. That's why I started

I agree.  It was good to ask the question.

The point I was trying to make is that while we have now many QOS 
standards, we don't have very much deployment experience.  As such it is 
hard to tell if it is worthwhile to use these 20 bits to optimize QOS 
performance.

Bob

---

From: Francis Dupont <[email-masked]>
Date: Fri, 17 Aug 2001 19:55:32 +0200

=> yes but only if its value is not zero (i.e. restrict to write once).

Regards

PS: the idea is to put zero in the field by default and to put a (non-zero)
random value by source or one of the first equipments on the path for
Intserv. We have a bridge (laptop running FreeBSD 4.3 + ALTQ) on a
subnetwork which just does that here.
--------------------------------------------------------------------
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: Bill Sommerfeld <[email-masked]>
Date: Fri, 17 Aug 2001 03:13:00 -0400

> the IPv6 header might be very useful.  This might not have anything to do 

Currently the field is defined as "must be random"; if we want to
preserve the ability to recycle it for something else in the future,
we need to redefine it *NOW* as a "must be zero".

					- Bill

---

From: [email-masked]
Date: Sun, 19 Aug 2001 11:46:27 +0900

>   or c) a QOS hint for intserv and diffserv

	(b).

itojun

---

From: Jim Bound <[email-masked]>
Date: Sun, 19 Aug 2001 22:57:42 -0400 (EDT)

Hi Brian,

Good idea.  I vote for b.  As first input.

/jim

---

From: Jim Bound <[email-masked]>
Date: Sun, 19 Aug 2001 23:11:11 -0400 (EDT)

We cannot define it now for MUST be zero.  RSVPv6 uses its.

But because it is random I don't agree means that specific bits can't be
identified later if we need to.

When the flow is encoded at such a point in time specific values will
cause an error to the init app creating it (as I am a supporter of "b").

/jim

---

From: Jim Bound <[email-masked]>
Date: Sun, 19 Aug 2001 23:17:41 -0400 (EDT)

Yes I would as a note.  I want what we orginally called for and to make
sure nothing breaks RSVPv6 which uses the flowlabel too.

/jim

---

From: Jim Bound <[email-masked]>
Date: Sun, 19 Aug 2001 23:25:57 -0400 (EDT)

I think we should do b via an experimental draft.  Go write some code and
see if it works in the test beds (e.g. 6bone, 6init, Eurosix, DoD).  Then
report back.  This will give us some experience.

I think doing anything to promote routing based on transport+port is a bad
technical idea and strategy for IPv6.  IPv6 should put an end to that type
of route lookup and forwarding now.  

Also regarding the argument of not knowing the length of headers, Itojun
is correct we cannot put that in the flow label it will create bugs and is
not prudent.  We have long known that the forwarding path will have to
live with extensibile headers.  It is a done deal and we should move
forward.  Let the best engineers win who are are the smartest to create
algorithms that can adapt to IPv6 extensibility.

/jim

---

From: Thomas Narten <[email-masked]>
Date: Mon, 20 Aug 2001 07:31:59 -0400

> we have effectively chosen the intserv-only usage. That's why I started

Is this really the case?

RFC 2460 actually says:

> 6.  Flow Labels
> 
>    The 20-bit Flow Label field in the IPv6 header may be used by a
>    source to label sequences of packets for which it requests special
>    handling by the IPv6 routers, such as non-default quality of service
>    or "real-time" service.  This aspect of IPv6 is, at the time of
>    writing, still experimental and subject to change as the requirements
>    for flow support in the Internet become clearer.  Hosts or routers
>    that do not support the functions of the Flow Label field are
>    required to set the field to zero when originating a packet, pass the
>    field on unchanged when forwarding a packet, and ignore the field
>    when receiving a packet.
> 
>    Appendix A describes the current intended semantics and usage of the
>    Flow Label field.

The only place that I know of where the Flow Label bits appear to be
used is in RFC 2205 (Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification). It says:

>       2.   IPv6 inserts a variable number of variable-length Internet-
>            layer headers before the transport header, increasing the
>            difficulty and cost of packet classification for QoS.
> 
>            Efficient classification of IPv6 data packets could be
>            obtained using the Flow Label field of the IPv6 header.  The
>            details will be provided in the future.

RFC 2205 does include an "IPv6 Flow-label FILTER_SPEC", but by my very
quick skimming this appears to be a separate filter spec in addition
to the normal IPv6 one that just uses ports, address, etc. I.e., its
not required to make use of RSVP in IPv6.

Personally, I do not see the need to further define the Flow Label
field just for the sake of defining it. These are effectively unused
bits that may become useful at some time in the future that we can't
well anticipate. When someone can make a compelling argument for why
the bits need to be defined in a certain way (i.e., there is a real
application for which using the bits provides significant benefits,
and those benefits do not appear achievable through other means) that
is the time to define the bits. What I do sense with many of the
recent discussions surrounding the Flow Label is that there are many
folks (i.e., folks putting IPv6 into hardware) that want to know what
they should implement w.r.t. the Flow Label. While it would be nice to
be able tell them what to do, we shouldn't standardize something just
for the sake of having a definition.

Thomas

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Mon, 20 Aug 2001 21:05:18 +0900

I voted for (b), with our past experience.reason.
	It may be useful to comment from out experiences, so I'll try to
	explain.

	We had some offsite meeting network setup in Japan, just like IETF
	terminal cluster, but with more aggressive experimental one.  We used
	diffserv with prioritized queueing of some sort ([email-masked]
	should be able to refresh my memory about more detail), as well as
	integrated MPLS + diffserv network (diffserv classification, you can
	purchase bandwidth guarantee by virtual currency, traffic goes through
	dedicated MPLS path).  Both of the time, major portion of the traffic
	was HTTP (TCP port 80), or SSH (TCP port 22).  the fact made the
	classification guys (including kjc) irritated, as almost all the
	traffic look the same and there's no fun in doing port-based
	classification.  Also, once someone uses ESP, it becomes impossible to
	classify based on port number.

	So, kjc wanted to at least identify each of the flow, at least for
	statistics purposes, as well as traffic classification/policying
	if possible.  Even if end nodes use ESP, he would liked to identify a
	flow from other flows.  So, he wanted us to attach unique pseudorandom
	flow label per flow.  This leads us to (b), and that's one of the
	reason why draft-itojun-ipv6-flowlabel-api-02.txt is based on (b).

	It is true that the originating node can put random value into flow
	label and confuse classifier, but there's no point in doing that.
	Also, it is true that it may help if the originating node can fill in
	port number information into the flow label, however, the originating
	nodes are not that cooperative.  End-to-end pseudorandom value 
	looks like the most useful, and most easier-to-manage for originating
	nodes (without requiring too much information leak).

itojun

---

From: "Brian Haberman" <[email-masked]>
Date: Mon, 20 Aug 2001 08:53:17 -0400

Brian,
     I would vote for (e) as well.  I would rather wait until someone
can demonstrate that an application/use will benefit greatly from the
use of the flow label bits.

Brian

---

From: Kenjiro Cho <[email-masked]>
Date: Tue, 21 Aug 2001 02:24:11 +0900 (JST)

> 	reason why draft-itojun-ipv6-flowlabel-api-02.txt is based on (b).

minor correction:

My point was that leaving the flowlabel field unused doesn't do any
good for QoS/IPv6 deployment.
So, I proposed to itojun to set flowlabel by default because I think
the availability of flowlabel values will promote practical use of
this field.

The original definition may not be perfect but at least there are
useful applications.  It isn't only for intserv; e.g., it can be used
for best-effort traffic to provide better fairness by WFQ-style
schedulers.

I think what the QoS community should have learned from the last
several years is that sometimes getting practical and moving forward
at the right time is more important than arguing :)

-Kenjiro

---

From: Alex Conta <[email-masked]>
Date: Mon, 20 Aug 2001 13:36:11 -0400

Thomas Narten wrote:
> 
> > [...] If we do nothing,
> > we have effectively chosen the intserv-only usage.[...]
> >
> Is this really the case?
> 
> RFC 2460 actually says:
> 
> > 6.  Flow Labels
> >
> >    The 20-bit Flow Label field [...]
> >
> Functional Specification). [...] 

Are you saying that the "intended semantics and usage of the Flow Label
field"
documented in the Appendix A of RFC 2460 are optional?

Alex

---

From: Alex Conta <[email-masked]>
Date: Mon, 20 Aug 2001 14:10:44 -0400

Kenjiro Cho wrote:
> >       statistics purposes, <...>
> >  on (b).
> 
> minor correction:
> 

I agree. 

> the availability of flowlabel values will promote practical use of

If Intserv-only is "good" for QoS/IPv6, the use with both Intserv, and
Diffserv, is 
"more than good", is an enhancement, a plus.

> for best-effort traffic to provide better fairness by WFQ-style

Adding the ability to do Diffserv QoS would improve the applicability,
the useful applications,
while allowing all of the original applications. It is a win-win
situation.

Alex

---

From: Thomas Narten <[email-masked]>
Date: Mon, 20 Aug 2001 13:53:46 -0400

> Are you saying that the "intended semantics and usage of the Flow
> Label field" documented in the Appendix A of RFC 2460 are optional?

Optional at best, so yes.  

Note that when 2460 was advanced to Draft Standard, there was IESG
pushback on including the Appendix A definition of the Flow Label as
part of the standard (that is why it got moved to an appendix, with
Section 6 using the wording "still experimental and subject to
change"). The definition is largely unproven (in the sense that folks
agree this is the best way to provide the function) and unused at this
point, hardly what one would expect as part of a Draft Standard.

That is not to say that it is the wrong way to do the Flow Label. But
there is no consensus that it is the right way either.

In my view, deciding on the right useage of the bits requires first
understanding the problem that needs to be solved.

Thomas

---

From: Alex Conta <[email-masked]>
Date: Mon, 20 Aug 2001 16:14:47 -0400

Thomas Narten wrote:
> 
> [...] When someone can make a compelling argument for why

10Gb/sec time wise means 100 psec/bit, or 0.8 nsec per byte, or 3.2
instructions of a hypothetical
1Ghz processor which can execute one instruction per cycle. That's a
hell of a requirement.

As consumers, we all enjoy the very cost-effective availability of
100Mb/sec line speed packet processing in almost every Notebook, or PC. 

IP and QoS Engines implemented in silicon, on a chip or a few chips, by
IBM, INTEL, and many, many others, is one of the reasons of the low
costs, along with the ability to optimizing the hardware
in so many more and different ways than the software (for instance
parallel header, or parallel header field processing). 

1Gb/sec IPv4 packet forwarding is a reality, 10Gb/sec is just around the
corner, with 40Gb/sec following not long after. 

With such drastic "timing" requirements, implementing engines in
silicon, and inventing *clever* mechanisms to handle the sequential
processing of headers alone, will not be sufficient to implement very
cost-effective IPv6 forwarding and QoS solutions, and IPv6 is at a
disadvantage relative to IPv4.

We need all the help we can get from the protocol, that is headers, and
their fields, for forwarding and QoS processing, and by that I mean both
Intserv, and Diffserv.  

Regards,
Alex

---

From: Alex Conta <[email-masked]>
Date: Mon, 20 Aug 2001 16:21:34 -0400

Thanks for the clarification,
Alex

---

From: Alex Conta <[email-masked]>
Date: Mon, 20 Aug 2001 17:47:29 -0400

Alex Conta wrote:
> 1Ghz processor which can execute one instruction per cycle.

 ""or 3.2 instructions"" 

meant to be:

 ""or 3.2 instructions per 4 byte longword""

Sorry.

>  That's a

---

From: Alex Conta <[email-masked]>
Date: Mon, 20 Aug 2001 18:23:43 -0400

Jim,

Please reexamine. 

As a hint, note that MPLS, which is using *mutable* labels, is using
RSVP-TE (extension of RSVP
for Traffic Engineering) as one of the label distribution mechanisms.

Alex

---

From: Alex Conta <[email-masked]>
Date: Mon, 20 Aug 2001 20:07:06 -0400

Jim,

Jim Bound wrote:
> technical idea and strategy for IPv6.  

I am afraid, there is a misunderstanding. Nobody advocated
transport+port to promote routing 
or as a strategy.

> IPv6 should put an end to that type
> not prudent.  

I am afraid again of a misunderstanding. 

As I do not expect everyone to understand or care about bit shifting, I
should mention
just for the sake of the record, that it was shown, that the details can
be crafted to eliminate 
the risk mentioned by Itojun, regarding length. 

> We have long known that the forwarding path will have to
> forward.  

We have also known from day one, that the flow label is an aid to
forwarding, and to QoS, and that
we still have to work on it.

> Let the best engineers win who are are the smartest to create

No question, IPv6 extensibility which is the ability to define and stack
options in the 'hop by hop' headers, or 'destination' headers, is a
plus. 

But we should minimize the price paid for it, that is the price for
variable IPv6 headers of variable size. Cause variable size, during
packet forwarding, is as bad, if not worse than variable size addresses,
and we know where we (Steve, Bob, Jim, I, and many others) were on that
many years ago.

Minimizing the price paid is even more necessary, when we examine the
gain on extensibility,  by counting the IPv6 options which were
standardized. and compare, them to the IPv4 standard options.

Alex

---

From: Jim Bound <[email-masked]>
Date: Mon, 20 Aug 2001 23:59:21 -0400 (EDT)

Alex,

Well aware of RSVP-TE.  I believe MPLS to be different than intserv.
I also believe MPLS Labels could become moot in theory with the correct
use of the flowlabel and become what the label does for MPLS via the flow
label.  Then I believe tunneling like RSVP-TE could be eliminated to
distribute the labels.  I don't believe all of this will scale but we will
see soon once the economy upturns and broadband is recharged in the
market.

I would like to see tunnels, NAT, etc all go away.  The flowlabel if used
correctly can contribute to that possibility.

We are at a stand still here.  Its too bad.  I guess I will have to
produce a draft supporting Brian's "b" and state the case and the
performance gain on the overall network.

I think RSVPv6 is a moot point there is not enough implementations to
worry about.  But it was a good exercise in using the flow label instead
of the IPv4 transport+port fields and digging past the header to define
the flowspec and queue classification.  Also it can be set for path msgs
using the v6 base API which gets past directly to the header.  RSVPv6 and
the RSVP API (RAPI) peforms better with IPv6 because of the flowlabel and
by orders of magnitude from what we saw testing video and audio.

I suggest we do this real time at the next Sun Connectathon and show
RSVPv6 and take measurements.  

RSVPv6 is useful to private enterprise Intranets as IPv6 inteserv tool
today.  But not on across the Internet unless we mesh with diffserv.

As far as IPv6 being left behind IPv4 for routing metrics you predict.
As far as I am concerned who cares if its not E2E which is being totally
lost with IPv4 lack of address space.  So I don't accept that argument.

IPv4 has no way of differentiating the header or the addresses except by
digging past the header.  We have the opportunity to do that with IPv6
and fix that error in IPv6 today and not have to bother with all the
AND/OR Gates being built in fast path today.  Its absurd to continue this
with IPv6 IMO.

regards,
/jim

---

From: Jim Bound <[email-masked]>
Date: Tue, 21 Aug 2001 00:18:18 -0400 (EDT)

Alex,

> transport+port to promote routing 

So advocating port numbers in the flowlabel is not the view of the current
thinking?

Thats good then.  If I missed that I will have to go back and check.

> the risk mentioned by Itojun, regarding length. 

I saw that mail.  That is not the only bug.  The other bug will be
assuming the extensions and when to update the length.  Adding this to the
IPv6 processing would need to be reviewed very carefully at this point.
Because it can be bit shifted does not mean it will work.

> we still have to work on it.
Of course.

> options in the 'hop by hop' headers, or 'destination' headers, is a

Also completely new prototcols.
 
> and we know where we (Steve, Bob, Jim, I, and many others) were on that

I agree and that was for the address too.  But if one follows the
extension chain all works correctly no matter what size or how many
extensions exist.

> standardized. and compare, them to the IPv4 standard options.

IPv4 options don't work?  I am missing the point?

But I think we should maybe define the reqs we are trying to achieve?

If we could all agree on that we may be able to move forward.  But that
gets back to Brian's mail on choosing a-e.

I think waiting is not a good idea though.  

We should figure this out now.

regards,
/jim

---

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

Thomas Narten wrote:
...
> understanding the problem that needs to be solved.

I think that from the QOS viewpoint, we do understand the problem very well, 
hence the proposal to add a diffserv usage to the existing intserv usage.

The intserv usage is documented and somewhat implemented, and I don't
think we can hide behind the weasel words in RFC 2460 any longer. 

I don't pretend to understand the routing handle usage (but then,
I'm of the school of thought that doesn't understand why anyone would
want MPLS either).

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Aug 2001 15:33:29 -0500

Hmm... it seems to me that both the formats we are suggesting (pseudo-random
and diffserv PHB ID) are immutable.

   Brian

---

From: Steve Blake <[email-masked]>
Date: Tue, 21 Aug 2001 16:05:59 -0400

Brian Carpenter wrote:

> hence the proposal to add a diffserv usage to the existing intserv usage.'

When I think about the most popular usage of protocol/port classification
for QoS (clamping down Napster traffic on university LANs), I don't see
how the new flow label proposal will solve that problem.

Protocol/port classification is only a "requirement" of Diffserv because
we haven't solved the problem of enabling the host to put meaningful
values in the DSCP.  I would prefer to try to solve that problem.

> think we can hide behind the weasel words in RFC 2460 any longer.

I think the requirement that the flow label be a PRN could be relaxed:
as long as it is unique per-host it should suffice for Intserv and other
flow-caching usages.

> I'm of the school of thought that doesn't understand why anyone would

Because some folks want Frame Relay NG, for a variety of reasons, including
multi-protocol support.  Which is why trying to fit label switching into
IPv6 is completely besides the point.

Regards,

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Aug 2001 16:19:39 -0500

> how the new flow label proposal will solve that problem.

I hope not. It wasn't designed to. At the risk of repeating myself,
the idea is to partially alleviate the problem of classifying
encrypted packets.
 
> values in the DSCP.  I would prefer to try to solve that problem.

That is really a small matter of programming. AIX has been able to set
DSCPs at source for a couple of years, and so has Linux and one or
two other o/s. The issue is getting QOS policy managers into
the hosts, and optionally adding code to applications to interact with
the policy manager and set the DSCP on the socket. IMHO there is
no IETF issue here.

> as long as it is unique per-host it should suffice for Intserv and other

Probably. I don't really remember the argument for PRN but it may have been
gut feeling about hashing efficiency.

> IPv6 is completely besides the point.

Fully agree. When we rejected CATNIP in 1994, we rejected this.

   Brian

---

From: Alex Conta <[email-masked]>
Date: Tue, 21 Aug 2001 19:42:13 -0400

In my view, we didn't restrict it to be "non-mutable", but that is in
the boundaries set by:

   " (c) A flow label is assigned to a flow by the flow's source node.
It
        can be changed en-route, with the condition that its original
        significance be maintained, or restored, when necessary. "

at page 15, in the draft. "(c)" protects the value of the flow label, or
rather, its meaning, where it is relevant to protect it.  

That is because, the value in itself, alone, is not meaningful. It is
the meaning of the value, which is important, and as long as that
meaning is preserved, the value can change.

Regards,
Alex

---

From: Alex Conta <[email-masked]>
Date: Tue, 21 Aug 2001 23:42:32 -0400

Jim Bound wrote:
> > [...]
> > transport+port to promote routing or as a strategy.
> > [...]
> > should mention just for the sake of the record, that it was shown, t
> > hat the details can be crafted to eliminate the risk [...] 
> 

You must have skipped one or more of my earlier messages. 

> > [...]

What does "completely new protocols" have to do with IPv6
extensibility??? What do you mean?

> [...]

You missed some of the earlier messages - mine, Thomas Eklund, etc...
Sequential header processing is OK in software, or in host, but prevents
parallel header fields and headers processing in hardware
implementations, in routers, where fast IPv6 header processing is
critical, and the price paid is high.

The IPv4 options worked, but as it turned out, few were useful, so few
are mandatory. 
This should be an additional indication, that options, in reality, are
not that valuable. 
Based on the number of current standard IPv6 options -- how many? a
handful? -- we should try 
really hard to minimize the cost of extensibility 'cause I see more pain
than gain.

Alex

---

From: [email-masked]
Date: Wed, 22 Aug 2001 11:41:30 +0300

Brian,

Let's then just say that it would be architecturally better to only have one
format that satisfies all the needs. With better I mean things like less
text in the specification, simpler implementations, less bugs, better
interoperability etc.

At this point no-one has established that there is a need or a requirement
for multiple formats of flow labels. You and Alex have brought up a
requirement that the flow label value needs to be somehow constant for the
diffserv for a form of MF classification for diffserv usage. The traditional
intserv has no requirement to the specific value being used, as the value is
being explicitly signaled.

It seems that both the old ("intserv") and new ("diffserv") requirements can
be met with single flow label format (current format with no pseudo-random
requirement).

Earlier it has been thought that the pseudo-random nature of the flow label
would make lookups easier by allowing the flow label to be used as a hash as
such. There are some specific difficulties with this, however:

1) Routers can not know how good pseudo random numbers the flow-labels
injected by hosts are in practice. Bad pseudo random numbers used by large
class of hosts could constitute a kind of DoS attack against router
implementations relying on the pseudo-random number nature of the flow
label. [Maybe someone actually implementing look-ups on hardware based on
the flow label could bring additional light on this matter (Alex?)]

2) If there is an alternative format, that is not pseudo-random (as being
proposed), the routers will have to implement look-ups that function
efficiently with that format. Since we do not know what portion of the
traffic in the future would use this non-pseudo-random format, the
implementations have to assume that all traffic can be labeled with this
alternative format.

It follows that there is no additional benefit of the pseudo-random nature
of the original format. Therefore it would be best to combine these formats
into one, that is non-pseudo-random. I.e. the current format with no
pseudo-random requirement. This would present the minimal change to the
current specification. Also, current (intserv) implementations could keep on
using the current pseudo-random numbers without breaking anything.

	Jarno 

> -----Original Message-----
> From: ext Brian E Carpenter [mailto:[email-masked]]
> Sent: 21. elokuuta 2001 23:31
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: Higher level question about flow label
> 
> 
> Jarno,
> 
> The Carpenter/Conta proposal does include two formats for the 
> label (one aimed
> at intserv flows and one aimed at diffserv flows), but if you 
> use the field
> only for rapid routing lookup, you don't care about that; in 
> both cases you can treat
> the label as 20 opaque bits I think.
> 
> You only care which format it is when you are doing specific 
> intserv or diffserv
> packet classification.
> 
>   Brian
> 
> [email-masked] wrote:
> > 
> > Jim,
> > 
> > Nice rant :-)
> > 
> > Could you elaborate on the pseudo-random nature of the flow 
> label. It seems
> > to me that if it did not need to be pseudo-random, people 
> could go on
> > "signaling off-line" about the flow label values (in SLAs, 
> this seems to be
> > what Alex & Brian want). I see no harm in allowing such 
> practice, but it
> > would be best if there is only one format for the flow 
> label, as it would be
> > faster to decode.
> > 
> >         Jarno
> > 
> > > -----Original Message-----
> > > From: ext Jim Bound [mailto:[email-masked]]
> > > Sent: 21. elokuuta 2001 15:58
> > > To: Thomas Eklund
> > > Cc: 'Alex Conta'; Thomas Narten; Brian E Carpenter; Bob 
> Hinden; ipng
> > > Subject: RE: Higher level question about flow label
> > >
> > >
> > > thomas,
> > >
> > > that is why if we can treat the flowlabel as part of 
> tuple with src
> > > address and identify a connection which identifies the 
> forwarding path
> > > the challenge is reduced.  there is nothing needed but the
> > > header for the
> > > look up and forward.  I believe this can be made to work.
> > >
> > > the traffic class will provide diff serv metric and the flow
> > > identifies
> > > the E2E connection with the src addr.
> > >
> > > The src addr MUST be a global address.
> > >
> > > Site-Local can be done too but don't want to get into 
> that right now.
> > >
> > > One can ask if the Ipv6 address is global why have the 
> flow for per
> > > connection as above.  This is a good question and needs 
> discussion.
> > >
> > > First the flow assists with the lookup in a binary tree,
> > > queue type, or
> > > archaic hash.  Its the hint to the next leaf, bucket, or 
> queue entry.
> > > duplicat highorder bits would cause a branch. This could 
> speed up the
> > > search before even getting to the global address.
> > >
> > > The src + flow could also be used as label for MPLS and its
> > > in the IPv6
> > > header.
> > >
> > > The business reason could also be that end users would 
> create SLAs for
> > > their flow labels in addition the bits set for the traffic
> > > class.  This is
> > > how QOS Int Serv could be realized.  And I guess conjunct
> > > with diff serv
> > > but that would need to be specified too.
> > >
> > > This also benefits client and server boxes too (gateways
> > > too).  We can now
> > > potentially keep one protocol control block for user 
> connections. tcp,
> > > sctp, and dcp per connection data structures would not 
> have to be kept
> > > above the internet per connection datastructures (e.g. bsd
> > > inpcb would be
> > > enough).  This is a performance win for clients and servers
> > > for IPv6 not
> > > just routers or switches or gateways.
> > >
> > > If we put a length in the flow yes it can be made to work but
> > > not without
> > > being verified by the router as the packet is parsed or
> > > "policed" then we
> > > have just put new processing far worse than the IP 
> checksum which we
> > > removed from the IPv6 router.  And opens up opportunity for
> > > bugs at that
> > > code point we don't have today.
> > >
> > > I also don't support the field being mutable as it transits
> > > the network
> > > path to the end destination.
> > >
> > > The reason is that we should make IPv6 E2E perform in the
> > > network as fas
> > > as possible.  If you look at all the work to do VPN, L2TP,
> > > NAT, Virtual
> > > Routing, et al that is emerging pervasive for IPv4 the root
> > > reasons are
> > > lack of IPv4 address space, the desire to do fast layer 2
> > > switching, and
> > > security inspection (e.g. firewalls).
> > >
> > > The later two above are the only valid visions.  We need to
> > > eliminate in
> > > our thinking the mind set developed because of lack of IPv4
> > > address space.
> > > I could argue that what is happening to IPv4 is pure professional
> > > irresponsibility on our part as Internet engineers.  The
> > > Internet should
> > > remain E2E.  This is not a politcal comment or even social
> > > comment.  Its a
> > > comment stating my assumptions about how the Internet 
> should operate.
> > >
> > > I think we need to discuss our assumptions for the
> > > requirements with the
> > > solutions we define.
> > >
> > > ADSL box providers actually market that NAT helps you because
> > > you don't
> > > have to worry about address space.  This is absurd and 
> professionally
> > > irresponsible in the market.  We should stop this with IPv6.
> > >
> > > The way to do that is give routers the means to forward 
> packets E2E by
> > > only looking at the header of IPv6.  That is what Brian's 
> "b" solution
> > > does.  Plus it benefits all nodes besides routes for IPv6 
> as I state
> > > above.
> > >
> > > As far as IPv6 extensions.  The payload length gives the
> > > router the entire
> > > length of the packet.  If the flowlabel can be used to
> > > identify forwarding
> > > the packet in addition to the address and other parts as 
> I state above
> > > then there is no challenge for ASIC vendors for strict
> > > forwarding of IPv6
> > > packets.
> > >
> > > If those vendors want to add more value by digging past the
> > > header then
> > > that is their option to add value but I don't believe it is
> > > required for
> > > fast forwarding of IPv6 packets.
> > >
> > > Steve's design works and I believe can be extended with the
> > > flowlabell and
> > > we can get rid of the mess IPv4 is making of the Internet
> > > because of the
> > > band-aids being applied.
> > >
> > > I believe the End System (and that could be a router in some
> > > cases or a
> > > broker router) should set the flowlabel at the access 
> exit before the
> > > edge.  But thats another discussion.
> > >
> > > Another discussion is how do we pick good random numbers for
> > > the flowlabel
> > > at the access exit end system or even a client.
> > >
> > > regards,
> > > /jim
> > >
> > >
> > > On Tue, 21 Aug 2001, Thomas Eklund wrote:
> > >
> > > > I agree alex.
> > > >
> > > > It gets worse for people that are doing ASIC which is not
> > > programmable, then
> > > > they need to spin a new version their ASIC when the
> > > protocols changes. For
> > > > people that are doing programmable ASIC (network processors
> > > etc) this is not
> > > > a problem.
> > > >
> > > > But common for both approaches is that the header format is
> > > really challenge
> > > > for the ASIC engineers
> > > >
> > > > -- thomas
> > > >
> > > > >-----Original Message-----
> > > > >From: Alex Conta [mailto:[email-masked]]
> > > > >Sent: den 20 augusti 2001 22:15
> > > > >To: Thomas Narten
> > > > >Cc: Brian E Carpenter; Bob Hinden; ipng
> > > > >Subject: Re: Higher level question about flow label
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >Thomas Narten wrote:
> > > > >>

---

From: Tim Chown <[email-masked]>
Date: Wed, 22 Aug 2001 11:32:55 +0100 (BST)

> meaning is preserved, the value can change.

But the only way to preserve the meaning - the fact that the combination
of source address and flow label uniquely identifies the flow because the
source host guarantees that each flow has a unique label - would be to
restore the value to the orginal value previous to any munging/tunelling
in the middle.   If you alter the value, where do you store the original 
value?

tim

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Aug 2001 14:54:13 -0500

I certainly don't care about the pseudo-random requirement for unique-per-host
opaque flow labels, but if we agree that the flow label may be used for diffserv
then it has to have semantics (i.e. it is not an opaque value). For that I am sure
we need the MSB as a flag bit, so that a classifier can tell whether it is looking
at an opaque value or at a value with semantics.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Aug 2001 15:23:23 -0500

Derek Fawcus wrote:
> 
> On Thu, Aug 16, 2001 at 08:44:59AM -0500, Brian E Carpenter wrote:
> I'd suggest e) A flow identifier for router optimisation.
> 
> I sort of see this as a variation of b),  i.e. it identifies a flow using
> a PRN but does not imply any QoS usage.  However it doesn't preclude the
> flow label being used in scenario b).
> 
> Specifically - I see it as a way of replacing the srcPort/dstPort tuple
> that routers peek at in the TCP/UDP header.  Currently I only see this
> being used in one scenario,  that is for load balancing across multiple
> paths.

Can't parse. By "currently I only see" do you mean
   -- this is what I see happening in the real world today
or -- this is what I envisage for the future ?

The fact is that port numbers are used for both intserv and diffserv
classifucation, and this won't go away.

> 
> At the moment (for v4) if a lookup on the dst address address leads to
> a route with multiple paths,  and the route is appropriatly marked,
> the flows of packets can be shared across these multiple paths.  This
> is done (for min size IPv4 headers,  carrying TCP or UDP) by hashing
> the srcIP/dstIP/srcPort/dstPort and using this to help choose which
> path to forward the packet over.

Yes, such hacks are not unknown. I don't think we should endorse this
sort of thing in the design of the IPv6 header.

> 
> Given that for IPv6 we can't guarentee the TCP/UDP header is at any
> given offset,  or even that it's readable.  One would need some other
> way of identifying flows if the above load balancing was to be performed.
> 
> For v6 a core router engine (either s/w path,  or ASIC [as fix logic
> or programable device as someone suggested]) one will not be looking
> beyond the base IPv6 header.  For an edge rouer engine,  one may well
> be looking inside the packet for say classification.
> 
> Hence use the flowID.  Without this we could only hash based upon the
> srcIP/dstIP and hence all flows between a given src/dst pair will hit
> the same path.
> 
> With this info in the flow label,  one would be able to hash together
> the srcIP/flowLabel to find the correct path.  As a router in this
> situation one would always have to combine the src IP address,  but
> if the flow label was defined to uniquely distinguish a given
> dstIP/srcPort/dstPort flow,  one could skip compining the dstIP at
> the router.
> 
> The reason for specifying that it be a PRN is simply to make the hashing
> cheaper at the router.
> 
> I said above that this doesn't preclude using the flow label for scenario
> b),  this can be achieved simply by picking a PRN for scenario b) from
> the same number pool as for scenario e).  Thus if intserv QoS is being
> used,  a (set of) routers would have been informed (via RSVP)
> about the relationship between that flow label and certain QoS
> requirements,  any other routers in the path of the packet flow that
> don't know about intserv/RSVP will simply treat packets in the flow as
> scenario e).

Unfortunately your suggestion does preclude diffserv classification for
encrypted traffic. Since it's also in support of a hack, I'm against it.

> 
> So the usage becomes one that is (potentially) orthogonal to QoS.  It
> will be usable for non QoS'ed (intserv or diffserv) packets,  as well
> as with both intserv and diffserv.

No, it is of no value for diffserv. The only way the flow label
can be of use to diffserv is if it has semantics.

   Brian

---

From: Derek Fawcus <[email-masked]>
Date: Wed, 22 Aug 2001 18:46:38 +0100

> the flow label could bring additional light on this matter (Alex?)]

I'd disagree.  The router should only use the RPN in a situation where a DoS
can't occur.

Take my example above - the route has already been looked up (using the
dst IP address),  and we've got multiple paths.  We're now going to use
the flow label to help pick the path.

So say a set of originating hosts pick a poor PRN,  all that happens is
that they end up getting less available bandwith for all of their flows.
This on the assumption that their choice of a poor PRN causes a sub set
of the available paths to be picked.

Note however that this doesn't affect other hosts with a good PRNG which
will be able to use more/all of the available paths.  It also doesn't
mean that a DoS on any given path will occur - since queuing (say WRED)
will occur after having picked a path.

The only party hurt by their choice of a poor PRN is themselves.

> implementations have to assume that all traffic can be labeled with this

Lookups only occur when a QoS type funtion is applied to the flow label,
say we've been told about a flow by RSVP.  In this case a PRN still helps
since we can reduce the cost of lookups by hashing on the flow label to
pick a subset of flows before doing a search/comparison.

But then if the flow lable was a PRN,  we'd simply skip the hash and use
some of it's bits as a hash bucket index,  before jumping to the search
and comparision phase.

If QoS is not in use for that particular route & flow label,  then if the
value was not random,  we'd have to use a more complex hash algorithm in
order to make sure we had got a good bucket distribution.

DF

---

From: Steve Blake <[email-masked]>
Date: Wed, 22 Aug 2001 18:43:46 -0400

> srcIP/dstIP and hence all flows between a given src/dst pair will hit

Including srcPort/dstPort in a load-balancing hash is generally a bad idea,
as documented in RFC2991 pg. 3.

Regards,

---

From: Alex Conta <[email-masked]>
Date: Thu, 23 Aug 2001 16:45:12 -0400

> in the middle.   If you alter the value, where do you store the original

Nodes that change the value would store information that would help
preserving the meaning. 
This could be done for instance by routers in a routing domain. Such
technologies already exist, even though not specifically for IPv6. The
storing of information can be pseudo-manual under the control of an
operator, or dynamic-automated, under the control of some protocol
engine, running 
on each router.

---

From: Alex Conta <[email-masked]>
Date: Thu, 23 Aug 2001 17:46:23 -0400

Brian,

You covered the essence, so, I will just expend a little on the use of
MSB:

The differentiation between Intserv, and Diffserv flow label values is
helpful when a. and b. bellow are both true:

 a. - packet source nodes send both Intserv and Diffserv traffic to the
same router, or set of        	routers, and
 b. - the router or the set of routers receiving the Intserv and
Diffserv traffic, do both Intserv 	and Diffserv classification.

If b. is not true, e.g. the router, or set of routers do Intserv, or
Diffserv, but not both in the same time, then the differentiation is not
really necessary. Can we be sure that b. is not true. 
I do not think so.

If a. is true, it is sufficient for the source node to pick up flow
label values from two distinct sets of numbers. The set can be
interleaved, as long, as the Diffserv values are known the router(s),
and the Intserv values are signaled to the routers. For instance 1, 2,
4, 7 can be Intserv, 3, 5, 6 can be Diffserv. 1, 2, 4, 7 are signaled to
the routers, 3, 5, 6 are known to the routers. Using MSB draws a
separation line that makes things simple.

Jarno's idea to have just one way of setting the bits in the flow label
has value, if we leave to the source node the problem of making sure
Intserv and Diffserv values do not overlap, or if we make sure that a
router would never do both Intserv, and DIffserv classification. If the
values overlap, it is OK, as long as NO router does both Intserv, and
Diffserv. If a router does 
both Intserv, and Diffserv, and values overlap, then the result is quite
unpredictable.

Regards,
Alex

---

From: Alex Conta <[email-masked]>
Date: Thu, 23 Aug 2001 20:52:00 -0400

Brian, Bob,

I respect very much the IPv6 WG, the WG's chairs, and the participants
to the thread that Brian
started, in an effort to move in the right direction.

But in my opinion -- perhaps as usual, less politically correct than
Brian -- I do not think that the IPv6 WG has a choice, that we have a
choice.

IPv6 is not X's, or Y's IP. It is IETF's IPv6, in fact, everybody's
IPv6. 

This puts a tremendous responsibility, but also demands a certain code
of conduct, or direction of thinking for all of us. If that is not
captured in the charter, I think it should.

The IPv6 WG is not a preferential club, or an exclusivist group. The
IPv6 WG is not to tell the IETF what standard is good and what standard
is bad. While the IPv6 WG develops IPv6, IT MUST ENSURE that IPv6 works
with, and it supports the other IETF standards.

Intserv, and RSVP completed work (WGs closed). Diffserv started is well
on its way. They are TWO IETF models for IP QoS, and are both on the
IETF standards track.

So, in terms of mechanisms to be standardized for the IPv6 flow label,
it is no question in my mind that right now WE MUST DO:

c) - standardization of the flow label for IP QoS, e.g. Intserv, and
Diffserv.

The choice is the user's, e.g. end users and network providers, to use
or not, one (Intserv), the other (Diffserv), or both, when deploying
IPv6. 

Furthermore, personally, I think that if the IPv6 flow label would have
been done right, we would not have MPLS, and IPv6 would have given even
more reasons to be adopted/deployed. 

At this point is too late, if for no other reason than just that MPLS is
a IETF standard on its way, and its own right, and that with the current
IPv6 header format, the flow label cannot match the efficiency of all
MPLS's features anyway. 

As I think that no standard should be excluded, I think that IPv6 WG
should do its best, to make IPv6 work well, friendly with MPLS. Which is
in a way [a subset of a)]+c).

Regards,
Alex

P.S.  Please note that MPLS labels are forwarding handles, that can also
include a QoS hint 
      (Intserv, or Diffserv).

---

From: Jim Bound <[email-masked]>
Date: Fri, 24 Aug 2001 00:44:36 -0400 (EDT)

given alex's mail and christians I change my vote to "c".  but I
would like to hear from Steve Deering at this point which could change my
vote again.  but either we should progress soon or I think we heed Thomas
Nartens mail that we may just want to leave all alone for now and the bits
MBZ if not used by existing intserv implementations.

/jim

---

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

Date:        Thu, 23 Aug 2001 20:52:00 -0400
    From:        Alex Conta <[email-masked]>
    Message-ID:  <[email-masked]>

To be even less politically correct ...

  | The IPv6 WG is not a preferential club, or an exclusivist group. The
  | IPv6 WG is not to tell the IETF what standard is good and what standard
  | is bad.

That is true, but

  | While the IPv6 WG develops IPv6, IT MUST ENSURE that IPv6 works
  | with, and it supports the other IETF standards.

that is simple nonsense.

There are all kinds of IETF standards around - a proportion of them are
utter crap.   In general, that is no problem - the vast majority of the
rubbish that is proposed, worked on, and then progressed can simply be
ignored - I know it is never going to affect me, because I am going to
ignore it forever.

But, if you're trying to tell us all that we have to go look at every IETF
standard (and by that I assume you mean PS and up, as there aren't actually
all that many full standards) and make sure that they are supported by IPv6,
then you're way off base.

Rather, if there are people who actually care about the other work, and need
it to be supported, and they don't think it is, then they need to come to
ipngwg (or whatever the name is this week) and argue for it.  Make a persuasive
case for some proposal, and whatever support is needed & possible is likely
to appear.  On the other hand, if ipngwg doesn't accept your request, then
tough.

Up to this point, exactly the right thing had been happening here, with the
request, and the debate (with no clear decision yet that I could make out).

But attempting to tell the WG that our hands are tied because some other
WG claims to need some feature or other is way off base.   The equivalent
would be if ipngwg sent a message to diffserv saying that they had to make
things work with nothing more than a random number, addresses, and
encrypted payload, because that's all they're getting - after all, IPv6
is a much more mature standard than diffserv.   By your reasoning, diffserv
would be compelled to support IPv6 that way.

I actually treat this message as a concession that there are no strong
enough arguments that can be made to ipngwg that would cause model (c)
for the flow label to be adopted.

kre

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Aug 2001 12:04:50 -0500

Robert Elz wrote:
...
> for the flow label to be adopted.

I don't see where you get that from. As I just said to Jarno, a flow label
with diffserv semantics enhances the diffserv model in the case of ESP headers.
No such enhancement is possible for IPv4. Does the WG want this?

  Brian

---

From: Robert Elz <[email-masked]>
Date: Sat, 25 Aug 2001 00:35:16 +0700

Date:        Fri, 24 Aug 2001 12:04:50 -0500
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

  | > I actually treat this message as a concession that there are no strong
  | > enough arguments that can be made to ipngwg that would cause model (c)
  | > for the flow label to be adopted.
  | 
  | I don't see where you get that from.

That's because you misread it I think.   I didn't say that there were no
arguments in favour of (c), but that I would treat Alex's message as conceding
that there are none.   That doesn't mean that you have to agree with him.
Personally, I have no idea, I'm not picking any of them.  Abstain.

The "I actually treat" was because Alex's argument amounted to "you have to
pick (c) because you're required to support other standards, and diffserv is
one of them".   That's the "because I said so" line of reasoning, which is
generally used (between peers) only when there is no other reasonable
argument available to be made.

kre

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Mon, 27 Aug 2001 22:27:15 +0900

>in a way [a subset of a)]+c).

	could you describe "[a subset of a] + c" in more detail so that
	people can understand you better?

itojun

---

From: Alex Conta <[email-masked]>
Date: Mon, 27 Aug 2001 12:01:18 -0400

> then you're way off base.

You know well, I was directly referring to QoS support for IP, i.e.
network layer protocols. 
As you know that there are standards to which my statements applies. You
do not have to go to an extreme.

However, you seem to contradict yourself - you said earlier "that is
true". 

Anyway, standards are in general made because people need or want them.
Some may look bad for one, or for a group. But they're good standards as
long as they help people that need them.
 
> request, and the debate (with no clear decision yet that I could make out).

You are in fact POLITICALLY VERY CORRECT. 

I am not. 

To have a group of people, within a WG, decide to support with one of
the protocol functions, (flow label), only one QoS standard, and not the
other QoS standard, just shows me how the process can go wrong. 

> would be compelled to support IPv6 that way.

That is nonsense. 

It is not just "some feature". There is no equivalence. The flow label
part is not 
mature - you ignore RFC 2460 itself. Furthermore, "random number" is not
part of the 
standard, and rightly so.

> for the flow label to be adopted.

There is no concession at all. 

It brings things in perspective: getting bogged down in details blurs
the essence, the very simple principle.

IPv6 supports QoS. IPv6 supports currently Intserv, but it support ONLY
a subset of Diffserv: BA.
We need to add the same level of support for Diffserv. That does not
affect any of the current support
of Intserv.

To have to argue at such a length for the full support of Diffserv, to
have to argue for adding the same level of support as it is provided for
Intserv, is surrealist, is absurd.

---

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

To avoid repeating pretty much what was already said, please see Thomas
Eklund messages.

---

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

Alex,

I am responding because you sent the email to me directly.

>started, in an effort to move in the right direction.

Thanks you.

>Brian -- I do not think that the IPv6 WG has a choice, that we have a

The IPv6, or any other working group for that matter, always have any 
choices.  The process is driven by "rough consensus".  The scope of a 
working group work is defined by it's charter.

The only mention of the flow label in the new IPv6 w.g. charter recently 
approved by the IESG is:

     The working group would welcome contributions on the following topics
     (this is not an exhaustive list):

      - Flow label standardization
      .....

This is far from saying the working group must do something.  Many working 
groups do less than their charter :-)

>The IPv6 WG is not a preferential club, or an exclusivist group. The

The chairs try to keep the working group process open and fair.

>with, and it supports the other IETF standards.

I don't think your statements are correct.  There is not a formal IETF 
requirement that the working groups output support all other IETF standards.

>on its way. They are TWO IETF models for IP QoS, and are both on the

Correct.  There may also be new methods for IP QoS defined in the 
future.  If I remember correctly, Diffserv was created after the scaling 
problems with Intserv/RSVP were better understood.

>it is no question in my mind that right now WE MUST DO:

You are, of course, entitled to your opinion.

>or not, one (Intserv), the other (Diffserv), or both, when deploying

"c)" is one of the choices being discussed on the mailing list.  From my 
read of the list, I don't see a consensus on any of the choices.

>more reasons to be adopted/deployed.

I do not agree with this statement and would note that it ignores the use 
of MPLS for IPv4.  IPv4 does not have a flow label field.

>IPv6 header format, the flow label cannot match the efficiency of all

MPLS will swim or sink on it's own merits.  I don't think this has much to 
do with IPv6.

>in a way [a subset of a)]+c).

The IETF creates a lot of standards.  They cover all parts of the protocol 
stack.  Did you really mean to include all of them in your assertion?  For 
example, I bet we could figure out way of including of encoding a DNS name 
in the flow label field to improve the performance of reverse 
lookups.  Email addresses?  Perhaps you only meant to include MPLS, Diff 
Serv, and Int Serv standards in your assertion.

In this case, I don't think that the w.g. has to do this (i.e., MUST).  I 
think we could standardize a specific use of the flow label field (beyond 
what is in the current RFC) if there was a compelling technical argument 
made and there was a rough consensus around that approach instead of the 
other choices.  However, it will have to a reason more compelling than 
other IETF working groups have standardized something.

Bob

p.s. For what it is worth, my current thinking is that I would prefer not 
use the flow label field for any specific QOS approach(s).  I am open to 
something that makes it easier to identify flows.  This could be used for 
QOS or other flow related applications.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Aug 2001 17:30:33 -0500

Bob,

Responding to your final comment, which I guess you made while out of
the chair for a second...

Bob Hinden wrote:
...
> QOS or other flow related applications.

The flaw in this is that one of the IETF's two QOS models is *not* flow
oriented - that is the entire reason why diffserv would need a flow label
with defined semantics.

We could decide not to give diffserv such a flow label, of course. But that
is a binary decision that IMHO needs to be taken soon.

So let me try to reduce this to a yes/no question for this WG:

  Should we give half the flow label space to diffserv as an e2e field,
  as at the beginning of section 7.1 of draft-conta-ipv6-flow-label-02.txt,
  specifically so that IPv6 can support diffserv for ESP packets?

(This specifically does not address the encoding of the diffserv flow label,
which on balance is probably a matter for diffserv.)

>          0                   1
>          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |0|       Pseudo-Random Value           |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
>          0                   1
>          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |1|     Diffserv IPv6 Flow Label        |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Brian

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 27 Aug 2001 16:06:36 -0700

> oriented - that is the entire reason why diffserv would need 

This appears to defy logic. The way I read it, we have a QoS 
mechanism that by-design is not end-to-end oriented, so we MUST 
define a way for the middle to interpret what the end points 
are telling each other.?!? There is absolutly no reason to tie the 
Flow Label field and the Traffic Class field together, which is
the only point of defining diffserv semantics for the Flow Label. 

There is no more need for a diffserv host to use a structured value 
for the Flow Label than there is for an intserv host to do so. 
The field is an end-to-end identification of packet relationships, 
nothing more. The Traffic Class field identifies PHBs, nothing more. 
They both exist in the packet from the origin, so why is it required 
that there be a relationship? The set of packets identified as a 
flow will be the same with either QoS mechansim, so why is there
a need to have distinct semantics unless someone in the middle wants
to interpret them? Since the middle is supposed to be per-hop and
not end-to-end, why would it care what the endpoints are saying?

Basically, why is it suddenly required that we define end-to-end 
semantics for a DSCP in the FL field, when the diffserv WG refused 
to do so for the TC field? If diffserv needs end-to-end agreement
on the DSCP/PHB mappings (which I believe it does for non-technical
reasons) then the work should be done in the TC field. 

Tony

---

From: "Rami Lehtonen" <[email-masked]>
Date: Tue, 28 Aug 2001 09:12:51 +0300

> QOS or other flow related applications.

I'm not followed the whole chain of the flow label discussion, but I was
curious enough to ask what are the reasons why we doesn't use the flow label
just for identification of different flows. We could calculate e.g. a hash
value from the IP addresses, port numbers and protocol number at the client
side and then put that value in the flow label field. That value could be
efficiently used by the network or the receiver to different flow
identification purposes even with ESP headers.

- Rami Lehtonen

---

From: Robert Elz <[email-masked]>
Date: Tue, 28 Aug 2001 15:02:02 +0700

Date:        Mon, 27 Aug 2001 12:01:18 -0400
    From:        Alex Conta <[email-masked]>
    Message-ID:  <[email-masked]>

  | You know well, I was directly referring to QoS support for IP, i.e.
  | network layer protocols.

I know what you were referring to, but I can't think of any good reason
to limit the principle to that, if there were to be such a principle.

That is, unless you're suggesting that QoS protocols are somehow of
magnified status that requires them to be considered where no other
protocol would be?

  | However, you seem to contradict yourself - you said earlier "that is
  | true".

What I mean there is that it isn't for ipngwg to go look at diffserv,
or intserv, or anything else, and then send a recommendation to the IESG
(or anyone) that protocol X is no good, and should be moved to
experimental, or historic, or something.   Especially not when there's
another WG involved.

But that's vastly different than saying that ipngwg (or anyone else) is
compelled to add support in its protocol for any other random protocol.
If the need is apparent enough, then you won't find it hard to convince
the WG of the requirement (like it didn't take much discussion for the
WG to decide that it really needed to support TCP and UDP - on the other
hand (v4) ICMP was discarded and a (similar) replacement invented).

  | To have a group of people, within a WG, decide to support with one of
  | the protocol functions, (flow label), only one QoS standard, and not the
  | other QoS standard, just shows me how the process can go wrong.

I don't see that happening, even if the diffserv arguments aren't
accepted.   That isn't the argument that anyone is making.

  | There is no concession at all.

Then why are you attempting to argue this bizarre "the WG must do it"
line, instead of just showing on the merits that it is the right thing
to do?   If the merits are there, or even if you just believe they are,
that's what you'd be doing, surely - it has to be much easier.

When people start arguing technicalities, and even more, when they're
far fetched unlikely ones, then it is usually a pretty good sign that
they have no substantiative arguments that they find convincing.

  | To have to argue at such a length for the full support of Diffserv, to
  | have to argue for adding the same level of support as it is provided for
  | Intserv, is surrealist, is absurd.

Once again, I am an outsider to this argument, just watching what is
happening.   But as I understand it, the "level of support provided for
intserv" is more just that it happens to fit the flow model label use
that the inpgwg has in mind.   The use that you want to impose requires more
semantics than the WG might want to load into it.

Pardon my ignorance a minute, let me ask you, and Brian (and anyone
else who knows), a few questions.

It seems that the current flow label is defined to be an immutable field
which should be set to a PRNG to identify flows (related packet streams).
Right?

The only reason for PRNG that I have seen identified, is to allow routers
in the path to use it as a ready made hash, and so optimise their lookups.
Right?  Or is there some other reason?

Obviously routers can't rely on that (ie: they can hope for it, and use
it to their benefit where possible, but they can't assume that hosts will
necessarily do the right thing).  So, if a host decided to use 1 2 3
rather than PRNG values, the world wouldn't collapse, right?

In response to an earlier question, Brian pointed out that there isn't
really an issue of hoaxing the flow label field to get better service, as
I'd be being billed for whatever service I actually get (if I ask for
good service I get billed more, I assume, and get given good service, even
if by any normal criteria my SMTP doesn't really need it...   If I ask for
cheap service, I get it, and poor service as well, even if my video
conference would have preferred something better).   Right?

Leaving aside the question of how you know it is me who asked for this
(I assume there's some way of doing this), what I do know is that there's
no way that you can bill me for anything, if we don't have a prior
agreement.  Or rather, you can send whatever bills you like, but you're
not going to get paid.

So, I assume there's a relationship between the sending host (its adminstrators
or owners), and the diffserv routers (or their admins, operators, or owners)
Right?   (Probably the same for intserv).

Given that relationship, and assuming that the world can cope with any
value in the flow label field, is there any reason that the host and the
diffserv router(s) it is using can't simply agree with each other on the
interpretation of the flow label field?   That is, the diffserv routers
say "put this value there, and I'll give you this kind of service".
Where "this number" may be "a number computed by this algorithm using this
input data", for any algorithm that the router & host can manage to
agree upon.   The agreement has already been presumed, we're not dealing
with random associations here, right?

To anyone who doesn't understand the diffserv algorithms, that number will
look random - sure, it won't pass any statistical tests on randomness, but
no-one is suggesting that the flow label field is required to contain that
kind of value, are they?

So, why do we need to reserve a bit (or Christian's group of bits) to let
the arbitrary world know what the format of the field is, when it only
actually matters to those who have agreed between themselves how to
interpret it?

Whatever way we go, there isn't space to stick in multiple different labels,
to identify the packet to multiple different QoS algorithms (one for the
first ISP's routers, then a different one for the next, then yet another, ...)
So, we don't need something to allo each to identify what part is meant
for it.

Nor is there a problem of the ipngwg having specified meanings to all of
those bits, which you need to be able to find a way to work around.
ie: we don't need a bit saying "that other interpretation doesn't apply".
They're just a random collection of bits that the sending host can set
however meets its needs.

It seems to me that all that's needed here is for diffserv to go away and
define "For doing diffserv using IPv6, set the IPv6 flow label field as
defined in section P.Q of this document".

That's still meeting the needs of ipngwg as I see them, it isn't compromising
anyone else's uses of the bits, if they're not doing diffserv, and you can
tell the difference, as you have an agreement with the diffserv users
(which you need to be able to bill them) and with that agreement you can
assume they'll use the field the way that you like.   If it helps you, by
all means include an "on/off" bit for your algorithm in the definition that
you use, so you can tell which packets (flows) are actually requesting
diffserv service, and which are not.

If the client doesn't abide by the agreement, and starts sending diffserv
looking labels, then you just interpret them that way, and bill them that
way, that's what you agreed with the client to do, after all.

So, it seems to me that there's nothing at all for ipngwg to do here,
other than to continue with the definition of the flow label in its
current form, and not start insisting that the value satisfy any particular
tests of randomness (which would be truly silly, as there's no guarantee
that any particular router will ever see more than one flow label value from
any particular source - and by definition, any value is equally likely if
the number is randomly chosen, so anything goes).

kre

---

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

Rami,

Such a hash, being irreversible, would be of no use for diffserv classification.

  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: Tue, 28 Aug 2001 08:40:05 -0500

Tony,

Tony Hain wrote:
> are telling each other.?!? 

The endpoints in diffserv don't tell each other anything; 
diffserv is an entirely hop-by-hop model. Each hop may choose
to look at the entire packet header in order to reclassify it.

> There is absolutly no reason to tie the

No, the point is to provide partial replacement of the {port, protocol}
semantics that are hidden by ESP. There is no tying together of
Traffic Class and Flow Label. They remain orthogonal.
> for the Flow Label than there is for an intserv host to do so.

Wrong (see previous point).

> nothing more. 

That was the old (non-normative) definition. We are proposing
to change it.

> The Traffic Class field identifies PHBs, nothing more.

It contains a code point value that identifies PHBs *within a given 
administrative domain*. It is not an e2e value.

> that there be a relationship? 

There is no relationship. The DSCP is a per-domain value and the proposed
PHB ID version of the flow label is an e2e value. Whether or not they
coincide depends on local diffserv configuration in each domain the
packet passes through.

> The set of packets identified as a
> to interpret them? 

Diffserv is blind to microflows; there is no flow identification.
However, diffserv classifiers in the middle *do* need to (re)interpret 
packet headers. That is how diffserv works.

> Since the middle is supposed to be per-hop and

Because reclassification may occur per-domain. That is how diffserv works.

> semantics for a DSCP in the FL field, 

It is *NOT* a DSCP. Please read RFC 3140. There is fundamental difference
between DSCP values (locally mappable) and PHB IDs (globally unique).

> when the diffserv WG refused
> to do so for the TC field? 

We did what the ISPs wanted: locally mappable semantics.

> If diffserv needs end-to-end agreement
> on the DSCP/PHB mappings 

It doesn't; again see RFC 3140 and reread the diffserv architecture.

> (which I believe it does for non-technical

That is precisely what the ISPs told us not to do, from the
beginning of diffserv.

    Brian

---

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

Robert Elz wrote:
...
> magnified status that requires them to be considered where no other

The only concrete proposals I have ever seen for use of the Flow Label
are for QOS. Everything else has been hand-waving. We need to decide.
It's unthinkable to leave this big mystery gap in the middle of the
IPv6 header.

...
> which should be set to a PRNG to identify flows (related packet streams).

But it is not defined in normative text, and the text we have is vague
on the actual usage - even worse than the text on the TOS byte in RFC 791,
for example. 

... 
> with random associations here, right?

Diffserv routers have no relationship with sending hosts; they are
configured within an admin domain (ISP or whatever) according to
local policy. There is no way to agree on anything except global
semantics, and for that to work we need a diffserv-specific format
for the flow label. There simply isn't any other way.

> no-one is suggesting that the flow label field is required to contain that

True, but remember the value is *not* going to be unique-per-host - it doesn't
identify a microflow. 

> actually matters to those who have agreed between themselves how to

There is no mutual agreement; diffserv is stateless and has no signalling.
If this isn't reserved in the IPv6 header, a router somewhere downstream
on the data path has to *guess* that the value is a valid diffserv flow 
label, rather than an arbitrary value that just happens to have a
diffservish value. That is hardly good engineering.

> So, we don't need something to allo each to identify what part is meant

This isn't an issue. PHB IDs are globally defined.

> They're just a random collection of bits that the sending host can set

I think I just showed why this is false. The downstream routers must be
able to interpret the bits statelessly, and that means it has to be
an encoded field.

> defined in section P.Q of this document".

There is no way we can risk using the flow label for diffserv as it is defined 
today,  since from a normative point of view it isn't defined at all,
and downstream routers have to guess.

> (which you need to be able to bill them) 

No, no, no. You have *no* such agreement with the users. You may (or may not,
in theory) have an SLA with your peer ISPs. But the mechanisms are stateless
at each point. You don't know whether a particular traffic source has set
a PRNG value or a diffserv value unless it tells you in each packet.

> and with that agreement you can

That's exactly the point - that bit has to be defined for *every* IPv6
packet. Otherwise it's guesswork.

> way, that's what you agreed with the client to do, after all.

Sure, you will always bill in the way the upstream SLA tells you to. If the
source lies, too bad for the bill-payer.

> current form, 

If that is the conclusion, diffserv cannot use it and IPv6 will have no
advantage over IPv4 for diffserv.

> and not start insisting that the value satisfy any particular

I agree. In the non-diffserv usage, unique-per-source is necessary and
sufficient (with PRNG being a possible optimisation for some router
technologies).

  Brian

---

From: Alex Conta <[email-masked]>
Date: Tue, 28 Aug 2001 12:15:12 -0400

Bob,

> I am responding because you sent the email to me directly.

It was in response to Brian, and you - your addition to Brian's list of
options. 

> The chairs try to keep the working group process open and fair.

To keep the process open and fair may be challenging. It is nice that
the chairs try. 

> requirement that the working groups output support all other IETF standards.

I didn't say "all". I was referring directly to the QoS standards, which
are part of the IP layer's set of standards (IPsec is another). It
applies to others 
as well, non-IP, like transports, etc...  

I think I qualified that already in an earlier message to Kre.

> read of the list, I don't see a consensus on any of the choices.

Brian was generous. He didn't put "f) Diffserv only" in his list.  Maybe
some people that are not convinced about Intserv/RSVP would have voted
for that. 
It would have been interesting for a consensus building process.

c) is a nice consensus building block, it can be seen as a superset of
b) It does
not exclude Intserv, it only adds Diffserv. It is a WIN-WIN (hint,
hint).

> [...]  Perhaps you only meant to include MPLS, Diff 
> In this case, I don't think that the w.g. has to do this (i.e., MUST). 
> [...]
> However, it will have to a reason more compelling than 

If this is indeed the process, then it gives an unfair power to IPv6 WG
to undersupport (could read undermine) standards created by other WGs
(Diffserv), which are IP standards, and which inter-depend with IPv6.
This is in my view a broken process. 
.
The appropriate and fair process would be, in my view, for the IPv6 WG
to standardize functions that other IP standards depend on, unless there
is a consensus on a compelling reason, that it should not do so.

> use the flow label field for any specific QOS approach(s).  

I do not think we can afford not to support specific QoS models. In
fact, it is stringent to add the Diffserv support -- there are many
vendors building IPv4 forwarding and QoS engines in silicon. Many do
IPv6 as well, and it is a struggle to make that cost/performance
comparable with IPv4.

> I am open to 
> something that makes it easier to identify flows.  

This is already done.

> This could be used for 

I wish you were more specific.
Flow related applications other than QoS in the network layer, to me, to
many, do not mean 
much, besides forwarding. And that is already done by MPLS. Based on
your response, I 
would not expect your encouraging of functions that would be friendly to
MPLS, so I am 
a bit puzzled.

Alex

---

From: Michael Thomas <[email-masked]>
Date: Tue, 28 Aug 2001 09:40:29 -0700 (PDT)

> It's unthinkable to leave this big mystery gap in the middle of the

   You know, this reminds me of having a bright shiney
   quarter burning to be spent by virtue of the fact
   that it's there. The eight bits in the ip4 header
   for TOS were standardized but not widely
   implemented. That allowed us to go back
   20 years later with a little bit more time and
   understanding to create a solution that's at
   least plausible. Considering that most QoS is
   still at the leap of faith stage, prudence
   seems like a perfectly reasonable stance.

	      Mike

---

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

Michael,

One of the alternatives on the table is to define the field
as reserved for future use. I think that would answer your point.

At the moment we have a header field described only in non-normative
text. I feel that is very confusing for implementors.

   Brian

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 28 Aug 2001 10:32:12 -0700

Brian,

It is obvious we are in violent agreement about how the current
mechanisms work. I think the difficulty arises from the use of
diffserv as a justification for the real goal of exposing the
port/protocol # that ESP specifically hides. 

> Traffic Class and Flow Label. They remain orthogonal.

Yes, diffserv is a hop-by-hop mechanism specifically targeting 
the Traffic Class field, but your arguments on this thread are 
asking for a part of the Flow Label field for diffserv use, so 
you are tying them together. What you stated above though is that 
the real goal has nothing to do with diffserv per se, but one of 
the capabilities that diffserv based networks typically take 
advantage of in the ability to deduce what the application is 
doing through snooping the port/protocol #. As I said, you are 
looking for a mechanism for the middle boxes to interpret what 
the end points are telling each other. Mixing diffserv with the 
desire to expose what ESP is hiding is the disconnect. Those 
efforts are orthogonal except in environments where people refuse 
to trust the DSCP bits but will trust the port # bits. We should 
not be breaking the architecture of ESP or the Flow Label simply 
to accommodate someone who is paranoid about one set of bits but 
trusts another set in the same header!

If the diffserv network really needs to know what the application 
is up to then it should use the signaled DCLASS approach of 
RFC2966. If it is not willing to go that approach, why are we 
trying to explicitly expose what ESP hides? Either they trust the 
application to tell them what they need to know through signaling, 
or they don't; in which case why would they believe anything in 
the Flow Label? If it is simply a matter of domain specific 
interpretation of the DSCP has proven to be an operationally 
useless concept, then the diffserv group should fix that. 
Usurping another set of bits to accomplish what the Traffic Class 
field should be used for (but can't for political reasons), is 
simply the wrong approach. Your proposal is looking for an exposed 
set of bits that will be consistent end-to-end, so people can make 
local decisions about how to deliver an end-to-end level of 
service through a set of concatenated PHB's (by randomly setting 
the DSCP in each domain). Fix the DSCP so those bits are consistent 
end-to-end and stay out of the Flow Label field. Its purpose is 
for the origin node to identify a set of packets that are related, 
nothing more.

Tony

---

From: Alex Conta <[email-masked]>
Date: Tue, 28 Aug 2001 13:35:51 -0400

>    seems like a perfectly reasonable stance.

Plenty, including your company, have used the TOS bits, for CoS, long
before the Diffserv effort.

I do not think we can afford to reserve 20 bits in the IPv6 main header.
IPv6 forwarding and QoS processing at line speeds, at 10G or higher, are
very challenging efforts. The Network Layer header must be used
efficiently for what is needed. Fields can always be re-defined, or
re-used, on a per need basis, in the future. 

Alex

---

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

Robert,

I will make just a few comments, where it adds value to what Brian
already said.

> on the actual usage - even worse than the text on the TOS byte in RFC 791,

In fact, provisions were made, to have the field mutable. For instance
transport (IPv6) checksum, and IPsec authentication skip the field, to
allow its modification en-route.

So, it does not have to be immutable. 

Non-normative text in RFC 2460 defines setting the value as a PRN, as an
aid to hashing based lookups of flow state in routers. Please note, that
in absence of a "perfect hashing function", using hashing by itself,
will not deliver the lookup result, some additional steps, like a
sequential lookup in a hash bucket, may be necessary.

However, Intserv/RSVP specifications, and Diffserv specification go into
more detail of how 
classifiers are used. Consequently mechanisms were developed for very
efficient classification processing, which hardly resemble the model
(vaguely) suggested in RFC 2460. Hardware classifiers for processing at
high line speeds are often implemented based on Content Addressable
Memories (CAMs), in which PRNs does not help at all. Unfortunately, some
take the use of PRN, like an axiom, which is wrong. In fact, Jarno,
Christian, myself, and maybe others showed on this thread, that the flow
label does not need be a PRN. Brian and I discussed it also in the
Carpenter/Conta draft.

However, PRNs have the negative effect, that prevent the use of
classification or filtering that do not have/use a signaling mechanism
to transmit the value of the PRN to the routers. 

This is one of the impediments for the use of the RFC 2460 definition
with Diffserv, or with filtering other than Intserv/RSVP.

> > no-one is suggesting that the flow label field is required to contain that

Well, the non-normative RFC 2460 requires PRN. As it has been said,
based on current knowledge and experience, there is no good enough
reason for using PRN.

Alex

---

From: Bob Hinden <[email-masked]>
Date: Tue, 28 Aug 2001 10:46:18 -0700

Alex,

>This is in my view a broken process.

Process wise I think what you are suggesting doesn't scale.  The IETF 
creates many standards.  Some of the standards are widely used 
operationally, others are lightly used, and some are not used at all.  If 
every IETF w.g. was required to support all other IETF standards, then I 
doubt the output would be very good.  Individual working groups need to be 
able to make their own decision that is appropriate for the work they are 
doing.

I understand you are only really saying that IPv6 w.g. must support the 
proposed Diffserv flow label definition as proposed in the draft, but you 
keep doing it in general terms.

If you wish to change the IETF standards process to add the requirement 
that IETF w.g. must support every other IETF standard (or perhaps that they 
must support Diffserv), then the POISED w.g. is the place to propose it.

I think you are going a bit far to suggest that the fate of Diffserv 
depends on what the IPv6 w.g. does with the flow label field.  I suspect 
that Diffserv will live or die based on IPv4 usage.  Also, as IPv6 is 
deployed much of it will be initially carried over IPv4.  Any QoS solution 
that is going to be end-to-end will have to deal with a mix of native IPv6 
and IPv4/IPv6 headers.

Bob

---

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

Bob Hinden wrote:
..
> that is going to be end-to-end will have to deal with a mix of native IPv6

Indeed, and since I don't quite see how IPSEC and NAT-PT are going to 
work together, the need that triggered this discussion (the need to
classify ESP packets in the middle of the Internet) really doesn't arise
in the case of translated packets. The concern is for a native IPv6 environment.

  Brian

---

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

> able to make their own decision that is appropriate for the work they are

Indeed. You are absolutely right, the process would have scaleability
problems 
if extended to the entire IETF.

> keep doing it in general terms.

I am talking only about standards that are inter-related,
interdependent.

I am saying, that IPv6 should support Diffserv in its entirety, and not
just pieces, and that is independent of the Carpenter/Conta proposal.

> must support Diffserv), then the POISED w.g. is the place to propose it.

As already stated, not every other, but inter-dependent. I think you
understood 
what I meant. Poised may be an option, but would have to check more on
the 
definition of the process, since I am not an expert on that.

> that is going to be end-to-end will have to deal with a mix of native IPv6

I am particularly concerned, and the proposal refers to that, about
access networks, 
where, the address space is IPv6, i.e. before tunneling over IPv4.

Alex

---

From: Michael Thomas <[email-masked]>
Date: Wed, 29 Aug 2001 09:36:49 -0700 (PDT)

Sorry if this is redundant; it's been a hard thread
   to keep up with.

 > Traffic Class and Flow Label. They remain orthogonal.

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

   If it's the former, I think I object to requiring a node to
   _have_ to reveal information (quite valuable information, if
   you consider it) in order to obtain QoS. At the very least,
   how is a non-signaled diffserv host to know whether it 
   should or should not insert the revealing information into
   the flow label? If the answer is that it always has to do
   that, you have effectively defeated one of the useful 
   protections of ESP. This would be very bad.
   
 > packet headers. That is how diffserv works.

   I'm afraid that this makes no sense at all. A
   microflow is nothing more than a tuple made up
   of some set of fields in the packet. If part of
   the protocol(s) takes some action based on that
   tuple, I'd say that it is certainly microflow
   aware, unless you add to the definition that
   a microflow also requires saved state in the
   router too. Even with that restriction, you
   are merely drawing the slim difference between
   frozen uflow classifer state  (eg, provisioned
   ACL's...) vs. dynamic classifer state (ala
   intserv).

---

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

> in the case of translated packets. The concern is for a native IPv6 environment.

   The current proposed lossage involves ESP over UDP.
   In fact, that would probably provide you with what
   you need for both v4 and v6.

	    Mike