Anoop,
Benoit,
Please see inline.
On Tue, Apr 15, 2014 at 5:04 AM, Benoit Claise <[email protected]
<mailto:[email protected]>> 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 <[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.
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
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
