Re: 400G forwarding - how does it work?

dip wrote: I have seen cases where traffic behaves more like self-similar. That could happen if there are small number of TCP streams or multiple TCPs are synchronized through interactions on bloated buffers, which is one reason why we should avoid bloated buffers. Do you have any good point

Re: 400G forwarding - how does it work?

Saku Ytti wrote: When many TCPs are running, burst is averaged and traffic is poisson. If you grow a window, and the sender sends the delta at 100G, and receiver is 10G, eventually you'll hit that 10G port at 100G rate. Wrong. If it's local communicaiton where RTT is small, the window is not

Re: 400G forwarding - how does it work?

On Mon, 8 Aug 2022 at 13:03, Masataka Ohta wrote: > If RTT is large, your 100G runs over several 100/400G > backbone links with many other traffic, which makes the > burst much slower than 10G. In Ohtanet, I presume. -- ++ytti

Re: 400G forwarding - how does it work?

Saku Ytti wrote: If RTT is large, your 100G runs over several 100/400G backbone links with many other traffic, which makes the burst much slower than 10G. In Ohtanet, I presume. which is, unlike Yttinet, the reality. Masataka Ohta

Re: 400G forwarding - how does it work?

On Mon, 8 Aug 2022 at 14:02, Masataka Ohta wrote: > which is, unlike Yttinet, the reality. Yttinet has pesky customers who care about single TCP performance over long fat links, and observe poor performance with shallow buffers at the provider end. Yttinet is cost sensitive and does not want to

Re: 400G forwarding - how does it work?

Saku Ytti wrote: which is, unlike Yttinet, the reality. Yttinet has pesky customers who care about single TCP performance over long fat links, and observe poor performance with shallow buffers at the provider end. With such an imaginary assumption, according to the end to end principle, the

Re: 400G forwarding - how does it work?

On Mon, 8 Aug 2022 at 14:37, Masataka Ohta wrote: > With such an imaginary assumption, according to the end to end > principle, the customers (the ends) should use paced TCP instead I fully agree, unfortunately I do not control the whole problem domain, and the solutions available with partial c

Re: 400G forwarding - how does it work?

You keep using the term “imaginary” when presented with evidence that does not match your view of things. There are many REAL scenarios where single flow high throughout TCP is a real requirements as well as high throughput extremely small packet size. In the case of the later, the market is e

RE: 400G forwarding - how does it work?

Also, for data center traffic, especially real-time market data and other UDP multicast traffic, micro-bursting is one of the biggest issues especially as you scale out your backbone. We have two 100GB switches, and have to distribute the traffic over a LACL link with 4 different 100GB ports on

Re: 400G forwarding - how does it work?

On Sun, Aug 7, 2022 at 11:24 PM Masataka Ohta wrote: > > sro...@ronan-online.com wrote: > > > There are MANY real world use cases which require high throughput at > > 64 byte packet size. > > Certainly, there were imaginary world use cases which require > to guarantee so high throughput of 64kbps

Re: 400G forwarding - how does it work?

On Mon, Aug 8, 2022 at 5:39 AM wrote: > You keep using the term “imaginary” when presented with evidence that does > not match your view of things. > > There are many REAL scenarios where single flow high throughout TCP is a > real requirements as well as high throughput extremely small packet si

Re: IERS ponders reverse leapsecond...

Are the people involved in that consensus engineering types? - Original Message - > From: "Forrest Christian (List Account)" > To: "John Levine" > Cc: "nanog list" > Sent: Thursday, August 4, 2022 4:51:42 PM > Subject: Re: IERS ponders reverse leapsecond... > Having at least a part of

Spoofer Report for NANOG for Jul 2022

In response to feedback from operational security communities, CAIDA's source address validation measurement project (https://spoofer.caida.org) is automatically generating monthly reports of ASes originating prefixes in BGP for systems from which we received packets with a spoofed source address.

Re: IERS ponders reverse leapsecond...

Tom Scott ponders the leap second. And Timezones, and and https://www.youtube.com/watch?v=-5wpm-gesOY - Original Message - > From: "jra" > To: nanog@nanog.org > Sent: Wednesday, August 3, 2022 11:09:25 AM > Subject: IERS ponders reverse leapsecond... > General press loses its *

Re: IERS ponders reverse leapsecond...

On Wed, Aug 3, 2022 at 9:22 AM Jay R. Ashworth wrote: > > > Occurs to me that "the last second of today" is approximately a million > times > more likely as a scheduling target than "the next to last second"; they > should > drop 23:59:5*8* instead. You’re probably one of those folks who wonder

Re: IERS ponders reverse leapsecond...

On 8/3/2022 8:09 AM, Jay Ashworth wrote: General press loses its *mind*: https://www.cbsnews.com/news/earth-spinning-faster-than-usual-shortest-day-ever/#app Have you tested leap second handling, especially

Re: IERS ponders reverse leapsecond...

I've been thinking about this problem for several decades. I believe I have a Good solution to it. It's the General Timestamp API effort at Network Time Foundation. If you have been paying any attention, you will immediately realize that the effort is stalled because of a lack of funding.