Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-large-flow-load-balancing (draft response)

From: ramki Krishnan <[email-masked]>
Date: Sun, 6 Apr 2014 16:42:33 -0700

Hi Benoit,

Thanks for your patience. We have addressed all your comments in the latest version. Additionally, we have done some editorial.

http://datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-balancing/

Thanks,
Ramki

From: Benoit Claise [mailto:[email-masked]]
Sent: Friday, March 28, 2014 4:24 AM
To: Anoop Ghanwani
Cc: ramki Krishnan; [email-masked]
Subject: Re: AD review of draft-ietf-opsawg-large-flow-load-balancing (draft response)

Hi Anoop, Ramki,

A gentle reminder.

Regards, Benoit
Hi Anoop,

Please post a new draft version, and I'll review the diffs.
Some more answers in-line.

Regards, Benoit

Hi Benoit,

Thanks for the detailed and careful review.  Comments inline.

Anoop

====

On Tue, Feb 18, 2014 at 7:55 AM, Benoit Claise <[email-masked]<mailto:[email-masked]>> wrote:

Dear authors,

Here is my AD review of draft-ietf-opsawg-large-flow-load-balancing

- Section 1:

   Networks extensively use link aggregation groups (LAG) [802.1AX] and

   equal cost multi-paths (ECMP) [RFC 2991] as techniques for capacity

   scaling. For the problems addressed by this document, network traffic

   can be predominantly categorized into two traffic types: long-lived

   large flows and other flows.

   ...

   This draft describes mechanisms for optimal LAG/ECMP component link

   utilization while using hash-based techniques. The mechanisms

   comprise the following steps -- recognizing large flows in a router;

   and assigning the large flows to specific LAG/ECMP component links or

   redistributing the small flows when a component link on the router is

   congested.

   It is useful to keep in mind that in typical use cases for this

   mechanism the large flows are those that consume a significant amount

   of bandwidth on a link, e.g. greater than 5% of link bandwidth.  The

   number of such flows would necessarily be fairly small, e.g. on the

   order of 10's or 100's per LAG/ECMP.  In other words, the number of

   large flows is NOT expected to be on the order of millions of flows.

   Examples of such large flows would be IPsec tunnels in service

   provider backbone networks or storage backup traffic in data center

   networks.

3 instances of "large flows": do you mean "long-lived large flows"?
If not, why do you make a distinction between long-lived large flows and other flows in the first paragraph?
I eventually understood the source of confusion when I read the terminology section:
    Large flow(s): long-lived large flow(s)

Either use capitalized term in the Intro section (actually throughout the doc.) so that we understand that the term is defined somewhere, or make it clear in the intro that large flow(s) = long-lived large flow(s)

Yes, they are all referring to long-lived large flows.  We will change the early part of Section 1 to clarify that long-lived large flows are, thereafter in the document, referred to as large flows.
Or replace large flow by long-lived flow were it makes sense in the draft.

-

   This document presents improved load distribution techniques based on

   the large flow awareness.
Improved compared to?

Improved compared to static hash-based distribution techniques that do not account for the bandwidth of the flows.  Will reword as follows:

"This document presents mechanisms for improving the load distribution problem resulting from stateless hashing as seen in the above example."
ok

-
In several places, starting with the title and abstract, you speak about mechanisms (plural).
However, looking at section 4.2, it seems that you propose a single mechanism? Or maybe you consider 4.1, 4.2, 4.3 as different mechanisms?

The title of 4.2 is perhaps misleading and should just be "Operational Overview."
ok

 Otherwise the rest of the draft discusses several mechanisms (multiple choices for large flow identification, and multiple choices for rebalancing).

-

Step 3) On receiving the alert about the congested component link,

   the operator, through a central management entity, finds the large

   flows mapped to that component link and the LAG/ECMP group to which

   the component link belongs.

   Step 4) The operator can choose to rebalance the large flows on

   lightly loaded component links of the LAG/ECMP group or redistribute

   the small flows on the congested link to other component links of the

   group. The operator, through a central management entity, can choose

   one of the following actions:

      1) Indicate specific large flows to rebalance;

      2) Have the router decide the best large flows to rebalance;

      3) Have the router redistribute all the small flows on the

   congested link to other component links in the group.

"Indicate specific large flows to rebalance", "through a central management entity", what you describe is basically traffic engineering.
Other the other hand, for 2) and 3), why do you need a central management entity?

The assumption was that the router is controlled by a central management entity for the purpose of this function, but that is clearly not a requirement.  The text will be modified to mention that a central management entity may be used (i.e. not required).
Ok.

-

   A number of routers support sampling techniques such as sFlow [sFlow-

   v5, sFlow-LAG], PSAMP [RFC 5475] and NetFlow Sampling [RFC 3954].

   For the purpose of large flow identification, sampling must be

   enabled on all of the egress ports in the router where such

   measurements are desired.
I don't understand the second sentence.
One way to read this is:  sampling must be enabled on all of the egress ports where such measurements are desired.
    Ok, this is an obvious statement. If the measurements are desired, enable them

Yes,
ok please clarify the text.

Or maybe you want to say: sampling must be enabled on all of the egress ports where such measurements are desired.
    This is a false statement: if you have the choice between sampling and non sampling, use non sampling measurements.
Or maybe you want to say: sampling must be enabled on all of the egress ports where such measurements are desired.
    This is a false statement: if I have ECMP on 2 links, and only one of them can't do non sampling, then we should not force
    sampling on both links.
You see, I'm confused.

You miss a couple of key messages:
- if unsampled measurements are available, use those.
- egress means where LAG/ECMP are enabled (this is important for the paragraph starting with "If egress sampling is not available, ingress sampling can suffice since the central management entity use")

We were not intending to discuss a mix sampling and non-sampling interfaces in the same router, but this is a reasonable point and it will be clarified (i.e. we will state that it's possible to mix sampled and non sampled interfaces as long as the function of large flow detection/identification can be performed).

-

   If egress sampling is not available, ingress sampling can suffice

   since the central management entity used by the sampling technique

   typically has multi-node visibility and can use the samples from an

   immediately downstream node to make measurements for egress traffic

   at the local node.

It's not clear if "ingress" means the ingress interface of the router itself, or the ingress interface of the downstream router.
A drawing is required.
Both options are possible:
    1. ingress interfaces on the router where LAG/ECMP is initiated
        flow monitoring must be enabled on all ingress interfaces
        flow monitoring must have a way to know the egress interfaces
2. ingress interfaces of the downstream router
        only work for LAG or ECMP single hop
        ingress interfaces = all components from LAG/ECMP (multiple ifIndex, typically)

What we meant here was that ingress sampling would have to be enable on the downstream device (hence the central management entity must come into play to identify large flows).
I still believe that a drawing would clarify things.

this entire section 4.3.3 needs some improvements

-
On one side, you wrote "Specific algorithms for placement of large flows are out of scope of this document.". On the other side, "The following parameters are required the configuration of this feature". It seems contradictory.
It's unclear why you need the following parameter:

     .  Imbalance threshold: the difference between the utilization of

        the least utilized and most utilized component links.  Expressed

        as a percentage of link speed.

Also, does ECMP/LAG always require equivalent link speed for their components?
The imbalance threshold is a measure of how much imbalance one is willing to tolerate before taking the hit of potential packet reordering in some flows.  Will clarify.

Thanks for catching the issue with link speed.  While in most cases speeds are consistent, there may be the case of composite links which combine links of different speeds (actually permitted by 802.1AX), so we will provide a generalized formula for the imbalance threshold which takes into account the individual speeds of each of the component links.

-

5.2. System Configuration and Identification Parameters

     .  IP address: The IP address of a specific router that the

        feature is being configured on, or that the large flow placement

        is being applied to.

     .  LAG ID: Identifies the LAG. The LAG ID may be required when

        configuring this feature (to apply a specific set of large flow

        identification parameters to the LAG) and will be required when

        specifying flow placement to achieve the desired rebalancing.

     .  Component Link ID: Identifies the component link within a LAG.

        This is required when specifying flow placement to achieve the

        desired rebalancing.

Nothing regarding ECMP?

Initially we were more focused on getting this done for LAG, but then we completely overlooked ECMP.  5.2, 5.3, and 5.4 would probably benefit from a bit of clean-up as follows:

Add the following to 5.2:

ECMP group: Identifies a particular ECMP group.

ECMP nexthop: Identifies a particular nexthop within an ECMP group.

Add the following line to the end of section 5.3.

When using ECMP, the nexthop within an ECMP group is used to identify the component link for placing the large flow.

Add the following to the end of Section 5.4.

When using ECMP, the ECMP group and the corresponding Nexthops along with the percentage of traffic to be assigned to each Nexthop is required.  Finally it is also possible that an ECMP Nexthop itself comprises a LAG in which case both the Nexthop and the LAG Component ID would need to be specified, and the weights of both the Nexthop's within the ECMP Group and the Component Links within the LAG would need to be adjusted.
Ok.

Regards, Benoit

-

   For high speed links, the etherStatsHighCapacityTable MIB [RFC 3273]

   can be used.

Well, only for ethernet.
Will clarify that.

EDITORIAL:
-
figure 2

OLD:

                  +-----------+ ->     +-----------+

                  |           | ->     |           |

                  |           | ===>   |           |

                  |        (1)|--------|(1)        |

                  |           | ->     |           |

                  |           | ->     |           |

                  |  (R1)    | ->     |   (R2)  |
NEW:

                  +-----------+ ->     +-----------+

                  |           | ->     |           |

                  |           | ===>   |           |

                  |        (1)|--------|(1)        |

                  |           | ->     |           |

                  |           | ->     |           |

                  |  (R1)     | ->     |   (R2)    |

Will fix.

-  The indentation in section 2 is not correct

Will fix.

- "For tunneling protocols like GRE, VXLAN, NVGRE, STT, etc.,"
You need to expand and provide references.
Will provide references.  What do mean by expand -- just expand the acronyms (already in the acronym section) or something else?

- a PBR rule

Expand.
OK
-
OLD:

                  +-----------+ ->     +-----------+

                  |           | ->     |           |

                  |           | ===>   |           |

                  |        (1)|--------|(1)        |

                  |           |        |           |

                  |           | ===>   |           |

                  |           | ->     |           |

                  |           | ->     |           |

                  |  (R1)    | ->     |   (R2)  |

                  |        (2)|--------|(2)        |

NEW:

                  +-----------+ ->     +-----------+

                  |           | ->     |           |

                  |           | ===>   |           |

                  |        (1)|--------|(1)        |

                  |           |        |           |

                  |           | ===>   |           |

                  |           | ->     |           |

                  |           | ->     |           |

                  |  (R1)     | ->     |   (R2)    |

                  |        (2)|--------|(2)        |

Will fix.

-

OLD:

The IPFIX information model [RFC 7011]

NEW:

The IPFIX information model [RFC 7012]
Will fix.
Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Mon, 14 Apr 2014 14:28:21 +0200

Hi Anoop,

Thanks for the new draft version.
I removed some of the points
>     One way to read this is:  sampling must be _enabled _on all of the
>     egress ports where such measurements are desired.
>     Or maybe you want to say: _sampling _must be enabled on all of the
>     egress ports where such measurements are desired.
>         This is a false statement: if you have the choice between
>     sampling and non sampling, use non sampling measurements.
>     Or maybe you want to say: sampling must be enabled on _all _of the
>     egress ports where such measurements are desired.
>         This is a false statement: if I have ECMP on 2 links, and only
>     one of them can't do non sampling, then we should not force
>         sampling on both links.
>     You see, I'm confused.
>
>     - egress means where LAG/ECMP are enabled (this is important for
>     the paragraph starting with "If egress sampling is not available,
>     ingress sampling can suffice since the central management entity use")
>
>
> We were not intending to discuss a mix sampling and non-sampling 
> interfaces in the same router, but this is a reasonable point and it 
> will be clarified (i.e. we will state that it's possible to mix 
> sampled and non sampled interfaces as long as the function of large 
> flow detection/identification can be performed).
You're still missing the point that unsampled measurements is better 
than sampled ones.

Is this what you mean by:

    It is possible that a router may have line cards that support a
    sampling technique while other line cards support automatic hardware
    detection of large flows.

It's not very clear.

> Will provide references.
Still to be provided
> What do mean by expand -- just expand the acronyms (already in the 
> acronym section) or something else?
Acceptable acronyms are 
https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
> OK
to be done.

Regards, Benoit

---

From: Anoop Ghanwani <[email-masked]>
Date: Mon, 14 Apr 2014 10:09:09 -0700

Hi Benoit,

I will work on the editorials shortly and I'm removing those from the
discussion.   See below:

On Mon, Apr 14, 2014 at 5:28 AM, Benoit Claise <[email-masked]> wrote:

>   On Tue, Feb 18, 2014 at 7:55 AM, Benoit Claise <[email-masked]>wrote:
>
>>  -
>>
>> One way to read this is:  sampling must be * enabled *on all of the
>>  Or maybe you want to say: *sampling *must be enabled on all of the
>>     This is a false statement: if you have the choice between sampling
>> and non sampling, use non sampling measurements.
>> Or maybe you want to say: sampling must be enabled on *all *of the
>>     This is a false statement: if I have ECMP on 2 links, and only one of
>> them can't do non sampling, then we should not force
>>     sampling on both links.
>> You see, I'm confused.
>>
>> - egress means where LAG/ECMP are enabled (this is important for the
>> paragraph starting with "If egress sampling is not available, ingress
>> sampling can suffice since the central management entity use")
>>
>
> interfaces in the same router, but this is a reasonable point and it will
> be clarified (i.e. we will state that it's possible to mix sampled and non
> sampled interfaces as long as the function of large flow
> detection/identification can be performed).
>
> You're still missing the point that unsampled measurements is better than
> sampled ones.
>

We do point this out in Section 4.3.4.
http://tools.ietf.org/html/draft-ietf-opsawg-large-flow-load-balancing-10#section-4.3.4

        As link speeds get higher, sampling rates are typically reduced
        to keep the number of samples manageable which places a lower
        bound on the detection time.  With automatic hardware
        recognition, large flows can be detected in shorter windows on
        higher link speeds since every packet is accounted for in
        hardware [NDTM
<http://tools.ietf.org/html/draft-ietf-opsawg-large-flow-load-balancing-10#ref-NDTM>].

> detection of large flows.
No, this does not address your point.  This is talking about the case where
line cards have different capabilities, rather than a line card that
supports both.

Since we already have the advantages and disadvantages listed in 4.3.4, do
you still see a need for explicitly mentioning that automatic hardware
detection is to be preferred over sampling if both are available?

We did debate the point about accuracy quite a bit among the authors.  The
question is -- does that level of accuracy really matter for the large flow
case?  Since we are dealing with flows that need to consume a certain
percent of the link bandwidth, sampling, if configured correctly, will
catch anything that is important.

Anoop

---

From: Benoit Claise <[email-masked]>
Date: Tue, 15 Apr 2014 14:04:00 +0200

On 14/04/2014 19:09, Anoop Ghanwani wrote:
> On Mon, Apr 14, 2014 at 5:28 AM, Benoit Claise <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Anoop,
>
>>         One way to read this is: sampling must be _enabled _on all of
>>         the egress ports where such measurements are desired.
>>         Or maybe you want to say: _sampling _must be enabled on all
>>         of the egress ports where such measurements are desired.
>>         Or maybe you want to say: sampling must be enabled on _all
>>         _of the egress ports where such measurements are desired.
>>             This is a false statement: if I have ECMP on 2 links, and
>>         only one of them can't do non sampling, then we should not force
>>             sampling on both links.
>>         You see, I'm confused.
>>
>>         - egress means where LAG/ECMP are enabled (this is important
>>         for the paragraph starting with "If egress sampling is not
>>         available, ingress sampling can suffice since the central
>>         management entity use")
>>
>>
>>     interfaces in the same router, but this is a reasonable point and
>>     it will be clarified (i.e. we will state that it's possible to
>>     mix sampled and non sampled interfaces as long as the function of
>>     large flow detection/identification can be performed).
>     You're still missing the point that unsampled measurements is
>     better than sampled ones.
>
>
>          hardware [NDTM  <http://tools.ietf.org/html/draft-ietf-opsawg-large-flow-load-balancing-10#ref-NDTM>].
> >>>
I've seen that, but why do you equate automatic _hardware _recognition 
to unsampled measurements.
Whether it's done in hardware of software is orthogonal.

> No, this does not address your point.  This is talking about the case 
> where line cards have different capabilities, rather than a line card 
> that supports both.
>
> Since we already have the advantages and disadvantages listed in 
> 4.3.4, do you still see a need for explicitly mentioning that 
> automatic hardware detection is to be preferred over sampling if both 
> are available?
>
> We did debate the point about accuracy quite a bit among the authors. 
>  The question is -- does that level of accuracy really matter for the 
> large flow case?
Maybe not (for the details: http://dl.acm.org/citation.cfm?id=1791959), 
but I don't understand why you want to limit this mechanism to sampling 
only. Simply telling that sampled data could be good enough, but if you 
have unsampled data, you will get a better accuracy.
> Since we are dealing with flows that need to consume a certain percent 
> of the link bandwidth, sampling, if configured correctly,
And you don't go in the details of "sampling, if configured correctly"...

Regards, B.
> will catch anything that is important.
>
> Anoop
>
>

---

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 15 Apr 2014 17:55:49 -0700

Benoit,

Please see inline.

On Tue, Apr 15, 2014 at 5:04 AM, Benoit Claise <[email-masked]> wrote:

>>>     This is a false statement: if I have ECMP on 2 links, and only one
>>> of them can't do non sampling, then we should not force
>>>     sampling on both links.
>>> You see, I'm confused.
>>>
> I've seen that, but why do you equate automatic *hardware *recognition to
> unsampled measurements.
OK, I think I see the reason for the disconnect.  In the draft we only
talked about automatic hardware recognition and sampling as methods for
large flow recognition.  It seems you're suggesting there's a third way --
unsampled measurements (likely in hardware) but use of software for the
actual recognition of large flows from those measurements?  Can you
confirm?  If so, we can add that to the draft as well.

> where line cards have different capabilities, rather than a line card that
> supports both.
>
>  Since we already have the advantages and disadvantages listed in 4.3.4,
> do you still see a need for explicitly mentioning that automatic hardware
>  The question is -- does that level of accuracy really matter for the large
> flow case?
>
Thanks for the reference.

> And you don't go in the details of "sampling, if configured correctly"...

There are suggestions in some of the references (e.g. the DevoFlow paper),
but there are also other references, e.g.
http://www.sflow.org/packetSamplingBasics/index.htm.   This is a general
sampling problem, rather than something that was introduced by this draft.
 If you think it would be useful to add something (or maybe just pointers
to the references), that can be done.

Anoop

---

From: Benoit Claise <[email-masked]>
Date: Wed, 16 Apr 2014 10:53:25 +0200

Anoop,
> Benoit,
>
> Please see inline.
>
>
> On Tue, Apr 15, 2014 at 5:04 AM, Benoit Claise <[email-masked] 
>>     I will work on the editorials shortly and I'm removing those from
>>     the discussion. See below:
>>
>>
>>>         On Tue, Feb 18, 2014 at 7:55 AM, Benoit Claise
>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>             -
>>>
>>>             One way to read this is: sampling must be _enabled _on
>>>             all of the egress ports where such measurements are
>>>             desired.
>>>             Or maybe you want to say: _sampling _must be enabled on
>>>             all of the egress ports where such measurements are
>>>             desired.
>>>                 This is a false statement: if you have the choice
>>>             between sampling and non sampling, use non sampling
>>>             measurements.
>>>             Or maybe you want to say: sampling must be enabled on
>>>             _all _of the egress ports where such measurements are
>>>             desired.
>>>                 This is a false statement: if I have ECMP on 2
>>>             links, and only one of them can't do non sampling, then
>>>             we should not force
>>>                 sampling on both links.
>>>             You see, I'm confused.
>>>
>>>             - egress means where LAG/ECMP are enabled (this is
>>>             important for the paragraph starting with "If egress
>>>             sampling is not available, ingress sampling can suffice
>>>             since the central management entity use")
>>>
>>>
>>>         We were not intending to discuss a mix sampling and
>>>         non-sampling interfaces in the same router, but this is a
>>>         reasonable point and it will be clarified (i.e. we will
>>>         state that it's possible to mix sampled and non sampled
>>>         interfaces as long as the function of large flow
>     I've seen that, but why do you equate automatic _hardware
>     _recognition to unsampled measurements.
> talked about automatic hardware recognition and sampling as methods 
> for large flow recognition.  It seems you're suggesting there's a 
> third way -- unsampled measurements (likely in hardware) but use of 
> software for the actual recognition of large flows from those 
> measurements?  Can you confirm?  If so, we can add that to the draft 
> as well.
I see two only ways: sampled and unsampled.
Both could be done in hardware (most likely on router; This is what you 
called automatic hardware recognition, AFAICT) or software.
Whether it's done in hardware of software is orthogonal to the mechanism 
in this document.

I hope this clarifies

Regards, Benoit
>>     No, this does not address your point.  This is talking about the
>>     case where line cards have different capabilities, rather than a
>>     line card that supports both.
>>
>>     automatic hardware detection is to be preferred over sampling if
>>     both are available?
>>
>>     We did debate the point about accuracy quite a bit among the
>>     authors.  The question is -- does that level of accuracy really
>>     matter for the large flow case?
>     Maybe not (for the details:
>     http://dl.acm.org/citation.cfm?id=1791959), but I don't understand
>     why you want to limit this mechanism to sampling only. Simply
>     telling that sampled data could be good enough, but if you have
>     unsampled data, you will get a better accuracy.
>
>
>>     Since we are dealing with flows that need to consume a certain
>>     percent of the link bandwidth, sampling, if configured correctly,
> There are suggestions in some of the references (e.g. the DevoFlow 
> paper), but there are also other references, e.g.
> http://www.sflow.org/packetSamplingBasics/index.htm.   This is a 
> general sampling problem, rather than something that was introduced by 
> this draft.  If you think it would be useful to add something (or 
> maybe just pointers to the references), that can be done.
>
> Anoop

---

From: Anoop Ghanwani <[email-masked]>
Date: Thu, 17 Apr 2014 11:11:10 -0700

Thanks Benoit.  We'll figure out how to account for this in the draft and
will have the update posted in the next few days.

Anoop

On Wed, Apr 16, 2014 at 1:53 AM, Benoit Claise <[email-masked]> wrote:

>>  I've seen that, but why do you equate automatic *hardware *recognition

---

From: ramki Krishnan <[email-masked]>
Date: Tue, 22 Apr 2014 11:41:22 -0700

Hi Benoit,

Please find updated draft below. We have addressed all your comments.
http://datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-balancing/

Thanks,
Anoop & Ramki

From: [email-masked] [mailto:[email-masked]] On Behalf Of Anoop Ghanwani
Sent: Thursday, April 17, 2014 11:11 AM
To: Benoit Claise
Cc: ramki Krishnan; [email-masked]
Subject: Re: AD review of draft-ietf-opsawg-large-flow-load-balancing (draft response)

Thanks Benoit.  We'll figure out how to account for this in the draft and will have the update posted in the next few days.

Anoop

On Wed, Apr 16, 2014 at 1:53 AM, Benoit Claise <[email-masked]<mailto:[email-masked]>> wrote:
Anoop,
Benoit,

Please see inline.

On Tue, Apr 15, 2014 at 5:04 AM, Benoit Claise <[email-masked]<mailto:[email-masked]>> wrote:
On 14/04/2014 19:09, Anoop Ghanwani wrote:
Hi Benoit,

I will work on the editorials shortly and I'm removing those from the discussion.   See below:

On Mon, Apr 14, 2014 at 5:28 AM, Benoit Claise <[email-masked]<mailto:[email-masked]>> wrote:
Hi Anoop,

Yes,

We were not intending to discuss a mix sampling and non-sampling interfaces in the same router, but this is a reasonable point and it will be clarified (i.e. we will state that it's possible to mix sampled and non sampled interfaces as long as the function of large flow detection/identification can be performed).
You're still missing the point that unsampled measurements is better than sampled ones.

        hardware [NDTM<http://tools.ietf.org/html/draft-ietf-opsawg-large-flow-load-balancing-10#ref-NDTM>].
I've seen that, but why do you equate automatic hardware recognition to unsampled measurements.
Whether it's done in hardware of software is orthogonal.

OK, I think I see the reason for the disconnect.  In the draft we only talked about automatic hardware recognition and sampling as methods for large flow recognition.  It seems you're suggesting there's a third way -- unsampled measurements (likely in hardware) but use of software for the actual recognition of large flows from those measurements?  Can you confirm?  If so, we can add that to the draft as well.
I see two only ways: sampled and unsampled.
Both could be done in hardware (most likely on router; This is what you called automatic hardware recognition, AFAICT) or software.
Whether it's done in hardware of software is orthogonal to the mechanism in this document.

I hope this clarifies

Regards, Benoit

No, this does not address your point.  This is talking about the case where line cards have different capabilities, rather than a line card that supports both.

Since we already have the advantages and disadvantages listed in 4.3.4, do you still see a need for explicitly mentioning that automatic hardware detection is to be preferred over sampling if both are available?

We did debate the point about accuracy quite a bit among the authors.  The question is -- does that level of accuracy really matter for the large flow case?
Maybe not (for the details: http://dl.acm.org/citation.cfm?id=1791959), but I don't understand why you want to limit this mechanism to sampling only. Simply telling that sampled data could be good enough, but if you have unsampled data, you will get a better accuracy.

Thanks for the reference.
Since we are dealing with flows that need to consume a certain percent of the link bandwidth, sampling, if configured correctly,
And you don't go in the details of "sampling, if configured correctly"...

There are suggestions in some of the references (e.g. the DevoFlow paper), but there are also other references, e.g.
http://www.sflow.org/packetSamplingBasics/index.htm.   This is a general sampling problem, rather than something that was introduced by this draft.  If you think it would be useful to add something (or maybe just pointers to the references), that can be done.

Anoop

---

From: Benoit Claise <[email-masked]>
Date: Tue, 22 Apr 2014 23:49:28 +0200

Thanks.
The IETF LC has been requested.

Regards, Benoit
> *From:[email-masked] [mailto:[email-masked]] *On Behalf Of 
> *Anoop Ghanwani
> *Sent:* Thursday, April 17, 2014 11:11 AM
> *To:* Benoit Claise
> *Cc:* ramki Krishnan; [email-masked]
> *Subject:* Re: AD review of 
> draft-ietf-opsawg-large-flow-load-balancing (draft response)
>
> Thanks Benoit.  We'll figure out how to account for this in the draft 
> and will have the update posted in the next few days.
>
> Anoop
>
>         On Mon, Apr 14, 2014 at 5:28 AM, Benoit Claise
>                 Or maybe you want to say: _sampling _must be enabled
>                 on all of the egress ports where such measurements are
>                 desired.
>                 links, and only one of them can't do non sampling,
>                 then we should not force
>                     sampling on both links.
>                 You see, I'm confused.
>
>                 sampling is not available, ingress sampling can
>                 suffice since the central management entity use")
>
>     OK, I think I see the reason for the disconnect.  In the draft we
>     only talked about automatic hardware recognition and sampling as
>     methods for large flow recognition.  It seems you're suggesting
>     there's a third way -- unsampled measurements (likely in hardware)
>     but use of software for the actual recognition of large flows from
>     those measurements?  Can you confirm?  If so, we can add that to
>     the draft as well.
>
> Both could be done in hardware (most likely on router; This is what 
> you called automatic hardware recognition, AFAICT) or software.
>         No, this does not address your point.  This is talking about
>         the case where line cards have different capabilities, rather
>         than a line card that supports both.
>
>         Since we already have the advantages and disadvantages listed
>         in 4.3.4, do you still see a need for explicitly mentioning
>         that automatic hardware detection is to be preferred over
>         sampling if both are available?
>
>         authors.  The question is -- does that level of accuracy
>         really matter for the large flow case?
>