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

[Benoit Claise <[e-mail]>]

Thanks.
The IETF LC has been requested.

Regards, Benoit
>
> 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:*[e-mail] [mailto:[e-mail]] *On Behalf Of 
> *Anoop Ghanwani
> *Sent:* Thursday, April 17, 2014 11:11 AM
> *To:* Benoit Claise
> *Cc:* ramki Krishnan; [e-mail]
> *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 <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
> Anoop,
>
>     Benoit,
>
>     Please see inline.
>
>     On Tue, Apr 15, 2014 at 5:04 AM, Benoit Claise <[e-mail]
>     <mailto:[e-mail]>> 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
>         <[e-mail] <mailto:[e-mail]>> wrote:
>
>         Hi Anoop,
>
>         Thanks for the new draft version.
>         I removed some of the points
>
>             On Tue, Feb 18, 2014 at 7:55 AM, Benoit Claise
>             <[e-mail] <mailto:[e-mail]>> wrote:
>
>                 -
>
>                     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,
>
>                 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).
>
>         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>].
>
>         >>>
>
>     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
>
>
>
>
>             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.
>
>         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
>