Subject: RE: Flow label draft issues & new text

From: [email-masked]
Date: Wed, 11 Sep 2002 15:44:07 +0300

Hi Brian,

> To summarise: a source that chooses to use coarser flow labels deprives
> itself of downstream load balancing, but gains in downstream service
> differentiation. The draft is intended to allow that tradeoff rather
> than force one choice or the other.

I fully agree with you on this.  I think that the current flow label 
draft sets some basic guidelines on flow label uses, which is a good thing.
Further specifications can state how the flow label can be used.  There
is definate interest in this work in NSIS.  One simple goal of NSIS may
be a refinement of RSVP, possibly RSVP ver 2 (whatever that might entail)
which provide transparancy across intserv/diff serv/no serv networks.
If there would be NSIS-aware routers, they could use the flow label
for service differtiation.  

However, until we get better guidelines on the flow label, it will be hard
to get folks to do anything with it.

br,
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: [email-masked]
Date: Wed, 11 Sep 2002 17:22:22 +0300

Margaret Wasserman wrote:
> >[BC] Probably, but near the source or destination this is 
> not necessarily
> >true. In a non-diffserv, non-intserv scenario, using the triplet
> >{source, dest, flow label} to split the traffic could be interesting.
> 
> And, how do load balancing routers determine that this is a 
> non-diffserv,
> non-intserv scenario?
> 

Presumably by not having a matching classifier for the flow. At least in
the intserv case the path could/should be nailed down at the flow state
set-up phase, so the "default load balancing" would not be applied at all,
but the flow state would include the next hop information.

	Jarno

---

From: [email-masked]
Date: Fri, 13 Sep 2002 13:14:22 +0300

Margaret Wasserman wrote:
> This seems a lot simpler than the current doc, and would allow
> routers to make some immediate use of the flow label field to
> limit situations where they need to parse into the packet to
> find upper-layer ports (parse once, and cache the value based
> on src/dst/flow label).
> 

What you described above is equivalent to the "opportunistic" flow set-up mechanism included originally in RFC 1883. The practice was abandoned already in RFC 2460.

	Jarno

---

From: [email-masked]
Date: Fri, 13 Sep 2002 13:16:26 +0300

Tony,

I'm ok with both of the text improvements you proposed.

Thanks,

	Jarno

> -----Original Message-----
> From: ext Tony Hain [mailto:[email-masked]]
> Sent: Thursday, September 12, 2002 10:04 PM
> To: 'Michael Thomas'; 'Margaret Wasserman'
> Cc: 'Brian E Carpenter'; Rajahalme Jarno (NRC/Helsinki);
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: Flow label draft issues & new text
> 
> 
> Michael Thomas wrote:
> > ... snip
> >  > What doesn't work is if there may be non-zero values in 
> > the flow label  > that actually don't label flows.  How is a 
> > load-balancing or load-spreading  > router supposed to know 
> > that this isn't a flow label?
> > 
> >    Er, well, it _doesn't_. I guess I just don't
> >    attach any special meaning to the word "flow";
> >    that is, a flow is whatever the host says is a
> >    flow. If it's bizarre, then well, why should
> >    the router care? Again, other than maybe gaming
> >    fair queuing algorithms[*], why do routers
> >    actually care about what constitutes the
> >    sematics of the flow? It's really in the host's
> >    best interest to be network friendly, right? To 
> >    give routers information which increases the
> >    probability of forwarding its packets in the
> >    manner it hopes for, right?
> > 
> >  ... snip 
> >    Er, but the flow label *is* an element of a
> >    packet classifier, or rather perhaps a
> >    replacement for the current method of classifying
> >    packets. I thought as far as routers are
> >    concerned, flow label were opaque and that no
> >    internal semantics were visible.
> > 
> 
> 
> Mike is right, as far as middle-boxes are concerned the FL is opaque
> unless they have been given specific state to believe otherwise. There
> is no reason a load-spreader would have a problem with frequent reuse,
> or even all nodes deciding to use the same value for HTTP as 
> long as it
> is basing its decisions on the Src/Dst/FL rather than just the FL. 
> 
> 
> I do have comments on the text.  I would like to see the following
> changed from:
> 4.  Flow Labeling Requirements
> (4)  The source SHOULD assign each new transport connection (e.g.
>         TCP, SCTP) to a new flow.
> 
> to:
> (4)  The source SHOULD assign each unrelated transport 
> connection (e.g.
>         TCP, SCTP) to a new flow.
> 
> This would keep it from conflicting with (3).
> 
> 
> 5.  Flow State Establishment Requirements
> ...
>  To enable co-existence of different methods in IPv6 nodes, the
>    methods MUST meet the following basic requirements:
> ...
> (3)  The IPv6 node facility keeping track of the Flow Label and the
>         associated Source and Destination Addresses MUST be utilized
>         when assigning Flow Label values to new flows (see section 4
>         above).
> 
> That wording seems awkward, how about:
> (3)  The IPv6 source node MUST provide a facility for keeping track 
> of the Flow Label values associated with particular Source and 
> Destination Addresses for use when assigning Flow Label to new flows 
> (see section 4 above).
> 
> 
> Tony
> 
> 
>

---

From: [email-masked]
Date: Fri, 13 Sep 2002 13:23:19 +0300

I'm taking no position here on whether labeling like presented below should or should not be done, but...

Margaret Wasserman wrote:
>          - All HTTP packets get the same flow label.
> 
>                  How would this work with a load spreader that is
>                          trying to spread connections between a group
>                          of web servers?
> 

Even if the server farm shared a common "anycast" destination address, the different source address of each host will make the hash of fl/src/dst different. The hash value would remain stable as well, so no problem for this usage.

>          - The flow label contains a packet classifier.
> 
>                  This *might* be okay, if values aren't reused too
>                          often, and if a single connection always uses
>                          the same value.
> 

You probably meant diffserv per-hop-behavior-id, but even then the above mentioned hash value would remain stable for the microflow.

	Jarno