I was simply explaining forwarding engineering 101, which seemed to be being forgotten in the tread. Beyond that I don’t much care on way or the other. Stewart > On 27 Nov 2018, at 10:40, Joe Touch <touch@xxxxxxxxxxxxxx> wrote: > > Take that to the standards wg. Don’t stick your head in the sand and try to do an end run in ops. And don’t call any of this a security issue that it isn’t. > > Joe > >> On Nov 27, 2018, at 2:17 AM, Stewart Bryant <stewart.bryant@xxxxxxxxx> wrote: >> >> >> >>> On 27/11/2018 01:47, Joe Touch wrote: >>> If you can’t handle options, then you’re just lying about the tbps. >> >> When the required application performance exceeds the ability of the hardware >> designers to deliver it economically (or may be at any price) something has to give. >> At that point either the protocol gets modified, or it goes end of life. >> >> - Stewart >> >>> Joe >>> >>>> On Nov 26, 2018, at 5:18 PM, Nick Hilliard <nick@xxxxxxxxxx> wrote: >>>> >>>> Joe Touch wrote on 26/11/2018 21:59: >>>>> Rate limiting is quite different from 100% discards. When abuse >>>>> happens, it's clearly safe to react. >>>> data plane speeds are measured in terabits/sec. Control plane capacity for dealing with punted packets is measured in kilobits. As end user and data plane speeds increase, rate-limiting for problematic packets will tend towards towards 100% loss. >>>> >>>> It doesn't matter if your packet stream is subject to 20% loss, or 100%, or 100% for 20% of the time - beyond a certain point, the end user experience will languish in an indistinguishable morass of unusability. >>>> >>>> Nick >>>> >>>> _______________________________________________ >>>> Tsv-art mailing list >>>> Tsv-art@xxxxxxxx >>>> https://www.ietf.org/mailman/listinfo/tsv-art >> >
