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

[Anoop Ghanwani <[e-mail]>]

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

>>>


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