Subject: RE: Flow label draft issues & new text

From: [email-masked]
Date: Fri, 23 Aug 2002 10:17:53 +0300

Thomas,

Current text has the following paragraph in section 2 (Introduction):

"The minimum level of IPv6 flow support consists of labeling the
flows. IPv6 source nodes can label known flows (e.g. TCP connections,
RTP streams), even if the node itself would not require any flow-
specific treatment. Doing this enables load spreading and receiver
oriented resource reservations, for example. Requirements for flow
labeling are given in section 4."

From the above it should be clear that the intent of the draft is to explicitly allow for load balancing, or "load spreading".

Currently, the text in "Terminology and Definitions" defining "flow state establishment method" includes "algorithmic" methods for establishing flow state.

The problem with this is that load balancing does not need any flow-specific state, but state per interface (this state could be algorithmically generated, but it is not flow-specific state). Indeed, it would be rather dangerous if a router would create new flow-specific state for every different packet header it is forwarding.

To make the draft clear and explicit, I think we need to remove the algorithmic flow state establishment method, and maybe clearly state somewhere that load balancing does not need flow-specific state. As far as I recall, the only motivation to add the algorithmic definition was to allow for load spreading. After these changes the draft would (still) define what we want, but there would be no room for multiple interpretations.

Regards,

	Jarno

> -----Original Message-----
> From: ext Thomas Narten [mailto:[email-masked]]
> Sent: 21. elokuuta 2002 17:40
> To: Rajahalme Jarno (NRC/Helsinki)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Flow label draft issues & new text 
> 
> 
> > "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 unable to classify a
> > packet to an existing flow SHOULD NOT establish any flow-specific
> > state unless so instructed by a flow state establishment
> > method. With some flow state establishment methods, signaling new
> > state simultaneously clearing the old state from the new path may be
> > sufficient. A mechanism with a sufficiently long timeout period
> > before reusing the Flow Label values can also be used."
> 
> How does the above text relate to the idea (which I thought the WG was
> interested in) in allowing the Flow Label field to be used for load
> balancing (i.e., hash the src/dest/label to select the next-hop when
> there are more than one). Seems like load balancing might not be
> allowed by the above wording. Is that the intent?
> 
> Note in the case of simple load balancing, there is no flow state
> establishment method.
> 
> Thomas
> 

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 23 Aug 2002 13:30:48 +0200

below...

[email-masked] wrote:
> Currently, the text in "Terminology and Definitions" defining "flow state establishment
> method" includes "algorithmic" methods for establishing flow state.
> 
> The problem with this is that load balancing does not need any flow-specific state, but
> state per interface (this state could be algorithmically generated, but it is not
> flow-specific state). 

Not true; server load balancing solutions definitely do detect flows
and establish corresponding state. Indeed they *must* do so (to direct 
all packets from a given transport session to the same host). 

> Indeed, it would be rather dangerous if a router would create new flow-specific state for
> every different packet header it is forwarding.

It would be useless too. But who suggested such a thing?

> 
> To make the draft clear and explicit, I think we need to remove the algorithmic flow state
> establishment method, 

I would agree with that. However, if you do, I would also remove the
"(e.g. RSVP)" in the reference to dynamic flow state establishment. 
As I just mentioned, some load balancers do dynamically detect flow
state. 

> and maybe clearly state somewhere that load balancing does not need flow-specific state. 

Definitely not, since it isn't true.

> As far as I recall, the only motivation to add the algorithmic definition was to allow for
> load spreading. After these changes the draft would (still) define what we want, but there
> would be no room for multiple interpretations.

Yes, after the first change (delete "algorithmic"). But your second proposed change
would make the document inaccurate.

   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, 23 Aug 2002 19:10:00 +0700

Date:        Fri, 23 Aug 2002 13:30:48 +0200
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

  | Not true; server load balancing solutions definitely do detect flows
  | and establish corresponding state. Indeed they *must* do so (to direct 
  | all packets from a given transport session to the same host). 

That's true for v4, and the way things are currently done - but using the
flow label with v6, it doesn't need to be.

That is, the router can hash the source addr, and flow label, modulo the
number of paths/destinations and pick the N'th of those based upon the
hash.   It can repeat that, deterministically, as required, and needs no
state at all.

Perhaps what is relevant here is what is meant by "state" - which I
interpret as some record in the router of a particular packet that has
gone before (that is, after the packet no longer exists in the router,
there is some memory left behind that shows that it passed through).

The idea is that without some specific flow processing method, routers
shouldn't use the flow label to form such state (if the router wants,
it could still go hunt for the port numbers, and use that) because without
a way to flush that state, doing so might interfere with some defined
use of the flow label for other purposes.

That is, in basic (non flow processing supporting) systems, the flow label
should be treated as semantic free as possible, otherwise later designers
of flow mechanisms are going to have to work around brain damage that exists.

  | > and maybe clearly state somewhere that load balancing does not need
  | > flow-specific state. 
  | Definitely not, since it isn't true.

It is if they use the flow label for balancing (that is, the packet flow
labels are the state, but they're maintained by the source host, not by
the router).

If they're not using the flow label, then they're irrelevant to this draft.

kre

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 23 Aug 2002 15:41:13 +0200

I don't disagree with anything that you say, but it doesn't
change my view of what should be in the document (i.e.
nothing specific about load balancing).

    Brian

---

From: Robert Elz <[email-masked]>
Date: Fri, 23 Aug 2002 20:57:02 +0700

Date:        Fri, 23 Aug 2002 15:41:13 +0200
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

  | I don't disagree with anything that you say, but it doesn't
  | change my view of what should be in the document (i.e.
  | nothing specific about load balancing).

That's fine, I agree with that.   What does need to be there is something
more general that says what shouldn't be done, without (seeming to) prohibit
what is still OK - without getting to specific cases.

kre