Re: TCP torture testing

2025-01-17 Thread joel
If you want to go nuts, check out Scapy > On Jan 17, 2025, at 13:13, Brandon Martin wrote: > > Does anyone know of a good way to simulate oddball TCP happenings like: > > * Out of order delivery > * Variable delivery delays > * (Especially) Unusual segmentation e.g. splitting part of a stream t

Re: TCP torture testing

2025-01-17 Thread Brandon Martin
On 1/17/25 14:29, William Herrin wrote: Well... In theory, TCP closes the segment at the end of the application's send() and sets the PSH flag. Likewise, on the receiving side the recv() returns before filling the buffer upon receipt of a segment with the PSH flag set. Every segment this thing

Re: TCP torture testing

2025-01-17 Thread Brandon Martin
On 1/17/25 13:42, Lukas Tribus wrote: Does anyone know of a good way to simulate oddball TCP happenings like: * Out of order delivery * Variable delivery delays I would suggest to take a look at linux tc-netem Yeah, tc will do most of this without too much fuss. * (Especially) Unusual segme

Re: TCP torture testing

2025-01-17 Thread William Herrin
On Fri, Jan 17, 2025 at 10:42 AM Lukas Tribus wrote: > This is more difficult because a TCP proxy (as in a userspace > application) does not do the TCP segmenting, the kernel does. Sure the > application may set flags like TCP_NODELAY to toggle Nagle, but beyond > that the application has not real

Re: TCP torture testing

2025-01-17 Thread Lukas Tribus
Hello, On Fri, 17 Jan 2025 at 19:13, Brandon Martin wrote: > > Does anyone know of a good way to simulate oddball TCP happenings like: > > * Out of order delivery > * Variable delivery delays I would suggest to take a look at linux tc-netem > * (Especially) Unusual segmentation e.g. splitting

TCP torture testing

2025-01-17 Thread Brandon Martin
Does anyone know of a good way to simulate oddball TCP happenings like: * Out of order delivery * Variable delivery delays * (Especially) Unusual segmentation e.g. splitting part of a stream that would and should normally be sent in a single segment into several smaller segments sent back-to-ba

Weekly Global IPv4 Routing Table Report

2025-01-17 Thread Routing Table Analysis Role Account
This is an automated weekly mailing describing the state of the Global IPv4 Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG UKNOF, TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to bg

Looking for Peering Contact at AS16509

2025-01-17 Thread W. Bontekoe via NANOG
Hi, I'm trying to connect with someone responsible for managing peering relations in EU for AS16509 (Amazon). Unfortunately, several attempts to reach them via the address on peeringdb (peering-e...@amazon.com) have been unanswered. Greatly appreciate if an appropriate contact could kindly r

Re: AT&t ABF NYC

2025-01-17 Thread nanog
At the risk of pointing out the obvious, only a small percentage of people would be expected to use the 25Mbps plan. It sounds pretty typical: if you want access to all the money in this lucrative market, you have to cover the whole market, even at the very lowest end where you'll lose money, b

Re: Free pass NANOG

2025-01-17 Thread Lu Heng
Hi everyone, I wanted to say a quick thank you to everyone who responded to my offer of extra passes for NANOG. All the passes have now been allocated, and I’m really glad they’ve gone to people who can use them. I’ve been thinking about why this doesn’t happen more often. Most of the other spo

RPKI's 2024 Year in Review

2025-01-17 Thread Job Snijders
Dear all, Happy new year everyone! Having just closed the book on another orbit around the sun - let's look back at how RPKI did in 2024! In this memo I'll share some RPKI statistics, summarize highlights from the IETF Standards Development process, and reflect on emerging trends. Year to Year G