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 protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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.
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.
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
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
