Thanks.
The IETF LC has been requested.
Regards, Benoit
Hi Benoit,
Please find updated draft below. We have addressed all your comments.
http://datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-balancing/
Thanks,
Anoop & Ramki
*From:*[email protected] [mailto:[email protected]] *On Behalf Of
*Anoop Ghanwani
*Sent:* Thursday, April 17, 2014 11:11 AM
*To:* Benoit Claise
*Cc:* ramki Krishnan; [email protected]
*Subject:* Re: AD review of
draft-ietf-opsawg-large-flow-load-balancing (draft response)
Thanks Benoit. We'll figure out how to account for this in the draft
and will have the update posted in the next few days.
Anoop
On Wed, Apr 16, 2014 at 1:53 AM, Benoit Claise <[email protected]
<mailto:[email protected]>> wrote:
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
