Subject: RE: IPv6 Flow Label Specification

From: [email-masked]
Date: Wed, 10 Jul 2002 18:48:45 +0300

Hi Pekka,

> [...]
> > For example, I much prefer that the application (or signaling
> > protocol) set the following:
> [...]
> > 	2) re-use of flow label values
> 
> (Hopefully I didn't misunderstand this point.)
> 
> The flow label space is far from infinite.  It's hypocritical 
> to believe a node would not need to consider a case when it needs to start 
> using some flow labels that may have been previously used.

I don't disagree with you - however my point was I thought that the
application should be involved in what value of the flow label is used.

John

--------------------------------------------------------------------
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 Haberman <[email-masked]>
Date: Wed, 10 Jul 2002 11:59:54 -0400

Hi John,

> application should be involved in what value of the flow label is used.

Is it really the case that the application needs to be involved in
choosing the flow label value?  Or is it more reasonable to say that
the app needs to be able to indicate that it wants to use *a* flow
label?

I can see the flow label management issue being more efficient in
the IPv6 stack itself.

Of course, there is also an issue of whether two applications on
the same machine communicating with the same peer machine would want
to share a flow label.

Brian

---

From: [email-masked]
Date: Thu, 11 Jul 2002 05:32:31 +0900

>I can see the flow label management issue being more efficient in

	FYI, draft-itojun-ipv6-flowlabel-api-01.txt provides no way to
	set flowlabel value from the userland.  the (sending) kernel decides
	the value.  receiver apps can inspect the value.

itojun

---

From: Brian Haberman <[email-masked]>
Date: Wed, 10 Jul 2002 16:48:34 -0400

>         the value.  receiver apps can inspect the value.

Exactly.  I prefer that rather than one that requires the apps to make
a decision on the value.

Brian

---

From: Derek Fawcus <[email-masked]>
Date: Thu, 11 Jul 2002 08:12:23 +0100

> the app needs to be able to indicate that it wants to use *a* flow

I see it more of a case of being able to apply more than one use to
a labeled flow.  i.e. say you want intserve and some other processing
to happen on a particular flow.  This basically requires that the
signalling protocols simply communicate the value,  not be involved
in choosing the value.

Well strictly _one_ signalling app/protocol could choose the value,
but then two such apps/processes would have trouble being applied
at the same time.

Hence referring to the following text in section 4:

   (2)  to assign a specific Flow Label for a new flow, and

assuming this means 'assign a specific Flow Label value',  and not
simply a specific Flow Label,  I think the text should be deleted.

Similarly the text:

   With [RSVP] or [SDP] either the source or the destination of the flow
   could have a preference for the Flow Label value to be used. For
   example, a destination with multiple sources sending packets to it
   could require all the sources to use the same Flow Label value in
   order to collapse the classifier state to a single flow state entry,
   instead of having separate classifier state for each source (ref. the
   Wildcard-Filter reservation style in [RSVP]). Therefore the source
   SHOULD honor the destination's request to mark the packets with the
   Flow Label value specified.

should also be changed.

First it refers to the destination requiring a specific flow label value,
I don't buy that.  Why would the destination care about the flow label,
it's the end node,  and as such has access to all infomation in the packet.

Secondly,  it is again requiring that a specific value be able to be
chosen / forced by the destination,  this again could interfere with
some other processing/handling also being applied at the same time to
the specified flow (as mentioned above).

I would also remove 'or requested' from the next paragraph.

DF

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Jul 2002 11:11:26 +0200

Strong disagreement below...

> simply a specific Flow Label,  I think the text should be deleted.

Absolutely not. This is text is essential to include certain possible
ways of using the Flow Label. It allows a host (quite likely an application)
to assign a specific, pre-defined, Flow Label value to a new flow that
needs that particular value (which might for example be an IANA-defined
value, or a value defined in a specific SLA). 

This sentence absolutely has to stay in.

>    Flow Label value specified.

No it shouldn't...

> it's the end node,  and as such has access to all infomation in the packet.

The text says why: it wants to treat multiple flows from multiple sources
alike. It don't want to have to peek into every packet.
> the specified flow (as mentioned above).

When we understand all the use cases, ten years from now, maybe
we can use that argument. But today we need to ensure that we don't
accidentally exclude use cases.

> I would also remove 'or requested' from the next paragraph.

No, for the same reasons. It isn't appropriate for us to
exclude future options.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Jul 2002 11:14:59 +0200

> Exactly.  I prefer that rather than one that requires the apps to make

We certainly shouldn't *require* apps to make a decision, but (see my
previous message) we must make it possible for them. Therefore,
the API must provide an option for the sender to set the value. In any case,
draft-itojun-ipv6-flowlabel-api-01.txt will have to be reviewed after we
reach consensus on draft-ietf-ipv6-flow-label

   Brian

---

From: [email-masked]
Date: Thu, 11 Jul 2002 18:16:39 +0900

>the API must provide an option for the sender to set the value.

	the problem is, we need to provide a way for apps to pick a non-
	conflicting value to do that, and it gets very messy.  that is the
	reason why my draft does not provide ways for apps to pick the value.

>In any case,

	yes, that is why it is expired state.

itojun

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Jul 2002 11:38:13 +0200

>         reason why my draft does not provide ways for apps to pick the value.

That is unavoidable, and not so messy if the current draft-ietf-ipv6-flow-label
is followed (IMHO).

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Alex Conta <[email-masked]>
Date: Thu, 11 Jul 2002 11:28:35 -0400

While I agree with Brian, I simply want to add the point that a
mechanism that allows a "flow label value" be selected either by the
application or by the ip stack, would be quite similar to the way "port
number" selection works.

Alex

different than the model used for having an application choose