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
