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

[Benoit Claise <[e-mail]>]

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