Subject: Re: [Int-area] [Gen-art] Gen-ART LC Review of draft-ietf-intarea-flow-label-balancing-01

From: Brian E Carpenter <[email-masked]>
Date: Mon, 07 Oct 2013 10:51:06 +1300

Ben,

(CC's adjusted.)

I've commented below on your comments. A revised version is coming shortly.

On 01/10/2013 11:28, Ben Campbell wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> 
> 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
> .
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-ietf-intarea-flow-label-balancing-01
> 
> Reviewer: Ben Campbell
> Review Date: 2013-09-30
> IETF LC End Date: 2013-09-30
> 
> Summary: This draft is essentially ready for publication as an informational RFC. I have some minor and editorial comments that may be worth considering prior to publication.
> 
> Major issues:
> 
> None.
> 
> Minor issues:
> 
> -- General: 
> 
> Is this draft intended only to apply to HTTP load balancers, or is it generic to any application protocol? I think you intend the 2nd, but there's quite a bit of HTTP specific text throughout. If that's correct, it might be helpful to explicitly mention it, or to make the HTTP specific parts more generic. (e.g. "application-layer proxy" vs "HTTP proxy".)

The reality is that these techniques mainly apply to HTTP, although in
theory they're more general. Added a sentence to the Introduction.

> Nits/editorial comments:
> 
> -- general:
> 
> I personally find it easier to read and understand drafts that use the TCP/IP architecture layer names rather than OSI numbers. The names have more intrinsic meaning, and since we are talking about TCP/IP architecture stuff, that model seems to fit better.

"Layer 3/4" seems to be the usual term in load balancer descriptions. Added a
clarification where the phrase is first used.

> -- section 1, 1st paragraph:
> 
> It might be helpful to actually define "load distribution" and/or "load balancing".

Added a sentence.

> -- section 2, 1st paragraph:
> 
> I got a little confused by the reference locations. In particular, I expected the citation at the end of the first sentence to point to the flow label spec, not IPv6 in general. I think it would be more clear to add the 6437 reference immediately after the first occurrence of "IPv6 flow label", and remove  "... and it is defined in [RFC6437]" from the second sentence.

OK

> -- section 3, first bullet list item:
> 
> Is it worth mentioning SRV here?

I don't think so, because you can play load balancing tricks with AAAA
or CNAME too.

> -- section 3, 3rd bullet list item:
> 
> -- is "raw HTTP" the same as "plaintext HTTP"?

Yes, but I suggest "unencrypted" to be completely clear.

> -- section 3, 4th bullet: 2nd sentence: 
> 
> Please expand ECMP. 

OK

> -- "According to the specific scenario, it will spread new sessions..."
> 
> I suggest "Depending on the specific scenario..."
> 
> The antecedent for "it" is slightly ambiguous.

OK

> The use of the term "spread" makes it sound like a given session might get spread across multiple destinations. Maybe something along the lines of "assign new sessions to specific destinations across..."

OK

> -- " 'Persistance' is defined as guaranteeing that..."
> 
> s/ guaranteeing/"the guarantee"

OK

> -- "... run to completion on a specific server"
> 
> Would it be more precise to say that all packets for a particular session are delivered to the same server?

Well, the goal is completion, right up to the FIN/ACK.

> -- section 3, bullet list nested in numbered list shortly before the diagram:
> 
> Please put blank lines between the list entries.

OK

> 
> -- section 3, preamble to diagram:
> 
> What is a "maximum layout"?

Deleted "maximum" because it adds no information.

> 
> -- section 3, last paragraph:
> 
> Can you elaborate on why usage by proxies is unlikely to be cost effective? I can guess why, but it would be better to say it explicitly rather than leaving the reader to draw the conclusion.

Added "because they must in any case process the application layer header"

> -- section 4, last item in bullet list:
> 
> You say that forwarding the flow label has no performance benefit. That may be true locally for the proxy, but if a load balancer exists between the proxy and the server, there may be an overall benefit.

We're thinking of a proxy that is part of the server farm site, where there
usually is no load balancer "behind" it. Your comment is correct of course
for proxies elsewhere in the Internet, and we would have been wise to mention
that in RFC 6437. We can tweak the sentence.

> -- section 4, first paragraph after bullet list:
> 
> You assert that logic for handling extension headers can be omitted. I assume you mean from the actual program flow for the specific case, not from the code altogether, right? You would still need that logic for the zero value flow label case, wouldn't you?

Yes, we can tweak the sentence.

> -- section 4, last paragraph, last sentence:
> 
> s/ "statistical assumption" / "assumption that label collisions will be statistically rare"

OK

> -- section 5, 2nd paragraph: "Specifically, the specification [ ] states..."
> 
> Is that an intentional Tom Swiftie? :-)

Actually we can change the actual text.

    Brian

---

From: Ben Campbell <[email-masked]>
Date: Tue, 8 Oct 2013 15:04:47 -0500

Hi Brian, thank's for the response. A couple of comments below; I've removed sections that do not appear to need further comment.

On Oct 6, 2013, at 4:51 PM, Brian E Carpenter <[email-masked]> wrote:

[...]
> I don't think so, because you can play load balancing tricks with AAAA

I'm okay with not specifically mentioning it--but SRV weight field and selection algorithm does seem a bit more closely tailored to load balancing than playing tricks with other record types.

[...]

> Actually we can change the actual text.

:-)