Subject: Re: Flow label draft issues & new text

From: Margaret Wasserman <[email-masked]>
Date: Thu, 01 Aug 2002 15:29:33 -0400

Hi Jarno,

>The method by which the flow state is cleared from the IPv6 nodes is to be defined by the flow state establishment method used to set up the state. This implies that IPv6 nodes SHOULD NOT establish any flow-specific state unless so instructed by a specific flow state establishment method. 

I don't agree with the "SHOULD NOT" above...

There are some potential uses for flow identification that do not rely on
any sort of flow establishment mechanism or signalling, such as the use of
flow labels for load balancing.

To have a useful flow label for these mechanisms, an IPv6 node simply labels 
all of the packets in a given TCP/SCTP connection or UDP communication with 
the same flow label,making some basic effort not to re-use flows too often -- 
such as starting with a random number and monotonically increasing it for 
each new connection or communication.  

It would be fairly trivial to assign a flow label in this fashion -- not
much harder than setting it to zero.  So, you get a reasonable return for
very little work.

Of course, this type of non-unique flow labeling isn't consistent with using
flow labels to cache next-hop information, for example.  For those more
sophisticated needs, a real flow establishment (and maintenance) method may
be needed.  But, I don't think that we should require a more sophisticated
method to be present in order to use the flow label at all.

Margaret

--------------------------------------------------------------------
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: [email-masked]
Date: Fri, 02 Aug 2002 12:08:29 +0900

>much harder than setting it to zero.  So, you get a reasonable return for

	I agree with Margaret.  KAME has been doing this (automatically
	assign flow labels to TCP/connected UDP traffic) for a long time,
	so that we can help traffic analysis/diffserv researchers.
	(they can't correlate traffic due to the use of ESP, or SSH)
	draft-itojun-ipv6-flowlabel-api-01.txt has more details on it.

itojun

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 02 Aug 2002 10:40:18 +0200

I think in the end this is an argument about nothing. 

>  This implies that IPv6 nodes SHOULD NOT establish any
> flow-specific state unless so instructed by a specific flow state establishment method. 
> 

What Margaret and itojun refer to are flow state establishment methods that
happen to consist of algorithms built into the sending node (rather than
signaling mechanisms or pre-configured flow states).  These algorithms
must avoid duplicate labels, just as signaled or pre-configured
methods must. So the sentence is in fact a no-op and can be deleted.

While I'm writing, I agree with all of Jarno's other changes.

   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: Robert Elz <[email-masked]>
Date: Fri, 02 Aug 2002 15:59:12 +0700

Date:        Fri, 02 Aug 2002 10:40:18 +0200
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

  | I think in the end this is an argument about nothing. 

I think I agree with that.

  | > This implies that IPv6 nodes SHOULD NOT establish any flow-specific
  | > state unless so instructed by a specific flow state establishment method. 
  | 
  | What Margaret and itojun refer to are flow state establishment methods that
  | happen to consist of algorithms built into the sending node (rather than
  | signaling mechanisms or pre-configured flow states).  These algorithms
  | must avoid duplicate labels, just as signaled or pre-configured
  | methods must. 

Yes, when you consider only the source nodes.   There the method you
describe is correct, and the concerns expressed aren't a problem.
The wording could perhaps be improved to make that clear.

But...

  | So the sentence is in fact a no-op and can be deleted.

I don't agree with that - I read the relevant sentence as being directed
at intermediate nodes (routers), not at the end nodes (hosts).   That is,
I thought that it was trying to say that routers should not just "notice"
that there seems to be a flow passing by, and attempt to do magic things
to that flow, because there's no way to flush the state they establish to
do that.   That is, there needs to be some kind of setup mechanism (anything
from RSVP to an RFC) that defines just how the flows are established, and
when they should be torn down again.

Don't delete it, just make its scope clearer.

kre

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 05 Aug 2002 11:14:56 +0200

> Don't delete it, just make its scope clearer.

Since intermediate nodes are not allowed to change the flow label,
it never even occurred to me to think of it in that context.

Send text.

   Brian