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

From: Julia Renouard <[email-masked]>
Date: Tue, 13 Nov 2012 21:00:42 +0000

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 and b) the actual entropy we're seeing in the wild.  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?  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.

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.

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.

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.

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.

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.

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

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Nov 2012 09:54:26 +0000

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.
> 
> 
> 
> 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.

> 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 ;-).

> 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

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