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

[Anoop Ghanwani <[e-mail]>]

Benoit,

Please see inline.


On Tue, Apr 15, 2014 at 5:04 AM, Benoit Claise <[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]> 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]>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.


>
>> 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