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/