Re: [OPSAWG] draft-ietf-opsawg-large-flow-load-balancing: new version needed to address the IETF LC comments

[Warren Kumari <[e-mail]>]

On Thu, Dec 26, 2013 at 2:16 PM, ramki Krishnan <[e-mail]> wrote:
> Dear Benoit,
>
>
>
> The last call comments and your comments are addressed in the latest version
> of the draft.
>

I think that you missed Pete's comments in
http://www.ietf.org/mail-archive/web/opsawg/current/msg02881.html
In addition to his note that "last part of that sentence needs
clarification" it also has a typo ("distribution at with multi-node" -
extra 'at'?)

I *think* that you captured all of Benoit's comments, but will leave
it to him to confirm.
I think that you also cover Wes' comments from
http://www.ietf.org/mail-archive/web/opsawg/current/msg02916.html, in
section 5.6.2, but it wouldn't hurt to check with him (CCed).


The nits checker still complains that it cannot find the publication
date, presumably because there are 6 authors.
The RFC Editor policy (at http://www.rfc-editor.org/policy.html ) says:
"There is no rigid limit on the size of this set, but there is likely
to be a discussion if the set exceeds five authors, in which case the
right answer is probably to list one editor."
You can duke it out with RFC Ed, but personally I'd suggest just
reading the "Author Overload" section and implementing one of the
options.

W


>
>
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-balancing/
>
>
>
> Thanks,
>
> Ramki
>
>
>
> From: OPSAWG [mailto:[e-mail]] On Behalf Of Benoit Claise
> Sent: Thursday, December 12, 2013 5:37 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [OPSAWG] draft-ietf-opsawg-large-flow-load-balancing: new version
> needed to address the IETF LC comments
>
>
>
> Dear draft-ietf-opsawg-large-flow-load-balancing authors,
>
> I started to AD review of draft-ietf-opsawg-large-flow-load-balancing (Sorry
> for the delay btw).
> Then I reviewed the WG LC feedback (email from Melinda, "[OPSAWG] WG last
> call for "Mechanisms for Optimal LAG/ECMP Component Link Utilization in
> Networks", on August 24th), and I realized that I have the same feedback as
> Dan Romascanu in
> http://www.ietf.org/mail-archive/web/opsawg/current/msg02891.html
>
> Then I reviewed all the WGLC feedback, and it appears that this document was
> sent on my plate, while the most up to date draft version 5 still doesn't
> address the WGLC feedback.
> For example:
> http://www.ietf.org/mail-archive/web/opsawg/current/msg02897.html
>
> "It refers to all of them, i.e. LAG, ECMP, and even the (hierarchical)
> combination.  We can try and provide some clarification around that.  We
> will add 802.1AX as a reference for LAG."
>
> Please post a revised version that addresses the WGLC comments.
>
> While you are at it (and since I reviewed 1/3 of the document), here is part
> of my feedback.
> I'll restart my AD review with the next version
>
> Regards, Benoit
>
> =================================================================
>
> - You use the term flow is a lot. Your definition is in line with the Flow
> definition in RFC 7011 (IPFIX).
>
> Why not reuse it?
>
> Even your specific flow definition could re use the same "Flow" definition
> from RFC 7011
>
>
>
>    Large Flow(s): long-lived large Flow(s)
>
>
>
>    Small Flow(s): long-lived small Flow(s) and short-lived small/large
> Flow(s)
>
>
>
> - How many flow categories do you want to stress?
>
> 1. Introduction:
>
>    Network traffic can be predominantly categorized into two traffic
>
>    types: long-lived large flows and other flows (which include long-
>
>    lived small flows, short-lived small/large flows)
>
> 1.2. Terminology
>
>    Large flow(s): long-lived large flow(s)
>
>    Small flow(s): long-lived small flow(s) and short-lived small/large
>
>                   flow(s)
>
> 2. Flow Categorization
>
> In general, based on the size and duration, a flow can be categorized
>
> into any one of the following four types, as shown in Figure 1:
>
>    (a) Short-Lived Large Flow (SLLF),
>
>    (b) Short-Lived Small Flow (SLSF),
>
>    (c) Long-Lived Large Flow (LLLF), and
>
>    (d) Long-Lived Small Flow (LLSF).
>
>
>
> Please be consistent. This is slightly confusing.
>
> This only makes sense with the sentence at the end of section 2.
>
>    In this document, we categorize Long-lived large flow(s) as "Large"
>
>    flow(s), and all of the others -- Long-lived small flow(s) and short-
>
>    lived small/large flow(s) as "Small" flow(s).
>
>
>
> Proposal (to make it clear earlier in document):
>
> OLD:
>
>    Network traffic can be predominantly categorized into two traffic
>
>    types: long-lived large flows and other flows (which include long-
>
>    lived small flows, short-lived small/large flows)
>
>
>
> NEW:
>
>    Network traffic can be predominantly categorized into two traffic
>
>    types: long-lived large flows and other flows. These other flow,
>
>    which include long-lived small flows and short-lived small/large flows,
>
>    are considered as small flows in this document.
>
>
>
>
>
>
>
> EDITORIAL
>
> -
>
> Please expand LAG/ECMP in the abstract. While ECMP is known, LAG is not.
>
>
>
> -
>
> (load/mix and comma)
>
> OLD:
>
>    If the traffic load constitutes flows such that the result of the
>
>    hash function across these flows is fairly uniform so that a similar
>
>    number of flows is mapped to each component link, if, the individual
>
>    flow rates are much smaller as compared to the link capacity,
>
> NEW:
>
>    If the traffic mix constitutes flows such that the result of the
>
>    hash function across these flows is fairly uniform so that a similar
>
>    number of flows is mapped to each component link, if the individual
>
>    flow rates are much smaller as compared to the link capacity,
>
>
>
> -
>
> EDITORIAL
>
> OLD:
>
>  Where: ->-> small flows
>
>         ===> large flow
>
>
>
> NEW:
>
>  Where: ->   small flow
>
>         ===> large flow
>
>
>
> Alternatively, make it clear in the figure that "-> -> ->" means 3 small
> flows, by having each flow on a new line.
>
>
>
> In the same figure, what does "--/---/-" mean?
>
>
>
> -
>
>    To demonstrate the limitations of local optimization, consider a two-
>
>    level fat-tree topology with three leaf nodes (L1, L2, L3) and two
>
>    spine nodes (S1, S2) and assume all of the links are 10 Gbps.  Let L1
>
>    have two flows of 4 Gbps each towards L3, and let L2 have one flow of
>
>    7 Gbps also towards L3.  If L1 balances the load optimally between S1
>
>    and S2, and L2 sends the flow via S1, then the downlink from S1 to L3
>
>    would get congested resulting in packet discards.  On the other hand,
>
>    if L1 had sent both its flows towards S1 and L2 had sent its flow
>
>    towards S2, there would have been no congestion at either S1 or S2.
>
>
>
> A figure would be appreciated.
>
>
>
> - as a courtesy for the RFC editors, please order the references
>
>
>
> - idnits complains about the date.
>
>
>
> - RFC 5101 -> RFC 7011
>
>
>
>
> _______________________________________________
> OPSAWG mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsawg
>