Re: [Int-area] Feedback for draft-carpenter-flow-label-balancing-01

[Brian E Carpenter <[e-mail]>]

Julia,

Many thanks for the review.

On 13/11/2012 21:00, Julia Renouard wrote:
> Way overdue promised feedback for
> draft-carpenter-flow-label-balancing-01 - from IETF '84.
> 
> 
> 
> Here are some broader thoughts:
> 
> The biggest limitation in implementing this, as a vendor, is
> understanding a) how widely adopted the flow label is
> currently 

Very little. That's why the idea is that the flow label should
be included as part of the entropy but can only become the main
component over time. It's a chicken and egg problem.

> and b) the actual entropy we're seeing in the wild.

As it happens I've done some work related to this as part of
suggesting a hash algorithm better than the appendix of RFC
6437: https://researchspace.auckland.ac.nz/handle/2292/13240

> If you have any data on adoption or samplings of v6 packet
> headers that might demonstrate it is in use, this would be
> useful information to include.  Do we know if off the shelf
> stacks are implementing this now?  

Basically, no. These things take time to propagate. If load
balancers are known to support it, this will help propagation.

> Or implementing it
> correctly?   "Correct" usage would also be a concern.  Since
> this is not a part of the compliance and certification tests
> and 6437 is a newer RFC, I would have concerns about the
> correct usage of this field.

You also have to consider what would be the consequences of
incorrect use.
(1) flow label set to zero: no impact on header entropy.
(2) flow label set to a not-well-distributed value: partial
improvement in header entropy.
(3) flow label set inconsistently within a given flow: breakage.
But this would pretty much have to be malicious.

> 
> Another implementation assumption that may or may not affect
> its usefulness is the guarantee that the flow label is not
> changed.  There is concern that intermediate nodes - perhaps
> full proxies or FW's might indeed be rewriting or using the
> flow label for other purposes.  Despite the admonition, some
> might read it as only applying to stateless forwarding nodes.
> Any of these cases would break the LB's flow assumptions and
> break that flow essentially.  Something that might be
> interesting to address is any possible heuristics to detect
> this condition and "fall back" to standard flow association
> algorithms.

I agree, and that is also true for (3) above, so I think some
such heuristics are needed anyway. However, that's so bound up
in the design of a specific load balancer that I'm not sure what
can be said in general.

> 
> 
> 
> Specific notes and feedback:
> 
> 
> 
> Should you might want to reference RFC 6294.  I guess it
> doesn't say much about LB but seems a gap in any case.

As general background, sure. I find that in some ways to be the
most depressing RFC I've written ;-).

> 
> 
> Section 4:
> 
> "Note that balancers usually do not need to consider the 
> destination address as it is always the same, i.e., the
> server address."
> 
> Well, this is not entirely true.  LB's can be servicing
> different types of servers or pools of servers or services
> behind the LB.  If this is a core assumption behind the rest
> of the document or section, you may need to address this.  If
> this is not a core assumption - in other words if the rest of
> the section does not rely on this assumption, then you may
> not need to make this assertion.  I'd be interested in a
> discussion of what cases an LB may benefit from the 3-tuple
> instead of just the 2-tuple.  Perhaps none, but the assertion
> above leads me ask.

Yes, maybe it's just a distraction to mention this.

> 
> 
> 
> I would pull out and address the NAT question in a separate
> paragraph.  I'm wondering if it is worth providing guidance
> to NAT designers here.  I also wouldn't be so dismissive of
> NAT66.  While I don't disagree that currently the use-cases
> are not compelling, the IPv6 use-cases are still growing and
> people come up with new and interesting applications that
> continue to surprise.

OK

> 
> 
> 
> Summary:
> 
> Is it worth pursuing?  Perhaps - it is an interesting summary
> of ideas and a good reminder of this field but I'm not sure
> if this draft brings anything particularly new to the table.
> It simply condenses it into a given use-case.  Perhaps it has
> interop value if it also reinforces or documents current
> practices and the behavior required by 6437 such that we get
> more consistency in stack implementations and flow-label
> usage.
> 

Fair enough. I think the main purpose of the document is to make
people like you consider the issue - the IETF can't tell vendors
what to do, after all.

> 
> Which area?  I'm not sure.  Perhaps Transport but I can't
> quite judge that.

Yes, it's a topic whose place in the IETF is unclear.

> 
> I hope this was helpful.  My apologies for taking so long.

*Very* helpful, and no apology needed.

Regards
   Brian Carpenter

> Julia Renouard
> 
>