Re: Carpet bombing, what's it look like now
Saku Ytti via NANOG <[email protected]> Sat, 1 Aug 2026 16:55:44 +0300
| Newsgroups | gmane.org.operators.nanog |
|---|---|
| Message-ID | <CAAeewD--E3wvbXyH7wv3FO2Mb42OC7CgXKz-C6sJtnZr2pdL_A@mail.gmail.com> |
On Sat, 1 Aug 2026 at 16:35, Vincent Bernat <[email protected]> wrote: > It makes little sense since you need to put the sampled packet header in > the flow. You could put several of them or the first one or the last > one, but why? AFAIK, all implementations of IE 315 bypass the cache. I fully agree it makes no sense. But it also makes no sense without IE 315 in most practical scenarios, and people shouldn't cache with or without IE 315 by default, they should have explicit reason to cache. We cache on some platforms, where they support it, and our flow records are almost invariably 1 packet long. That is, we are spending SERDES on the NPU to store the record in off-chip memory, let it sit there, then later spend SERDES to pick it up, and export it out. Lots of complexity, cost, thermal, pin count to gain delay, utter madness. We mostly cache because of decades of habit, because of how it's always been done. Despite the network having so much more flows that statistically we're not hitting the same flow twice anymore almost ever. Only minor thing we gain is that the export packet may contain multiple flow records (each flow record 1 packet deep record). This can help in scale or pricing in some cases, but is a minor thing. And actually non-caching node could push multiple flow records in a single export packet also, just not what PTX does. If you use 305/306, every time you trigger export, you could pull consequent packets off the wire to fill the export packet you're simultaneously serialising out. 0 cache, 0 delay and fully populated export packets. -- ++ytti _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/LABCFFERRJ5Q66626YEVDAVT56467RUS/