Re: [Cerowrt-devel] [Cake] [Bloat] Little's Law mea culpa, but not invalidating my main point

2021-07-12 Thread Bob McMahon via Cerowrt-devel
--- Begin Message --- Agreed that UDP is important but it's also much easier to test and debug for WiFi coders. We find it's the connect() and TCP control loop that challenges WiFi logic systems on end hosts. APs are a whole different story per things like OFDMA. Nothing is simple anymore it

Re: [Cerowrt-devel] [Bloat] Little's Law mea culpa, but not invalidating my main point

2021-07-12 Thread Bob McMahon via Cerowrt-devel
--- Begin Message --- We in WiFi find UDP, while useful, also has severe limitations. The impact to the TCP control loop matters a lot for things like aggregation. Visualizations can be useful but also a bit limiting. We use stats techniques such as PCA which is more mathematical and less visual.

Re: [Cerowrt-devel] [Cake] [Bloat] Little's Law mea culpa, but not invalidating my main point

2021-07-12 Thread David Lang
I have seen some performance tests that do explicit DNS timing tests separate from other throughput/latency tests. Since DNS uses UDP (even if it then falls back to TCP in some cases), UDP performance (and especially probability of loss at congested links) is very important. David Lang On

Re: [Cerowrt-devel] [Bloat] Little's Law mea culpa, but not invalidating my main point

2021-07-12 Thread Ben Greear
UDP is better for getting actual packet latency, for sure. TCP is typical-user-experience-latency though, so it is also useful. I'm interested in the test and visualization side of this. If there were a way to give engineers a good real-time look at a complex real-world network, then they

Re: [Cerowrt-devel] [Bloat] Little's Law mea culpa, but not invalidating my main point

2021-07-12 Thread Bob McMahon via Cerowrt-devel
--- Begin Message --- I believe end host's TCP stats are insufficient as seen per the "failed" congested control mechanisms over the last decades. I think Jaffe pointed this out in 1979 though he was using what's been deemed on this thread as "spherical cow queueing theory." "Flow control in

Re: [Cerowrt-devel] [Bloat] Little's Law mea culpa, but not invalidating my main point

2021-07-12 Thread Ben Greear
Measuring one or a few links provides a bit of data, but seems like if someone is trying to understand a large and real network, then the OWD between point A and B needs to just be input into something much more grand. Assuming real-time OWD data exists between 100 to 1000 endpoint pairs, has

Re: [Cerowrt-devel] [Bloat] Little's Law mea culpa, but not invalidating my main point

2021-07-12 Thread Bob McMahon via Cerowrt-devel
--- Begin Message --- To be clear, it's a OS write() using a socket opened with TCP and the final OS read() of that write. The write size is set using -l or --length. OWD requires --trip-times option. Bob On Mon, Jul 12, 2021 at 11:21 AM Bob McMahon wrote: > iperf 2 supports OWD and gives full

Re: [Cerowrt-devel] [Bloat] Little's Law mea culpa, but not invalidating my main point

2021-07-12 Thread Bob McMahon via Cerowrt-devel
--- Begin Message --- iperf 2 supports OWD and gives full histograms for TCP write to read, TCP connect times, latency of packets (with UDP), latency of "frames" with simulated video traffic (TCP and UDP), xfer times of bursts with low duty cycle traffic, and TCP RTT (sampling based.) It also has

Re: [Cerowrt-devel] [Bloat] Little's Law mea culpa, but not invalidating my main point

2021-07-12 Thread David P. Reed
  On Monday, July 12, 2021 9:46am, "Livingood, Jason" said: > I think latency/delay is becoming seen to be as important certainly, if not a > more direct proxy for end user QoE. This is all still evolving and I have to > say is a super interesting & fun thing to work on. :-)   If I could

Re: [Cerowrt-devel] [Bloat] Little's Law mea culpa, but not invalidating my main point

2021-07-12 Thread Livingood, Jason via Cerowrt-devel
--- Begin Message --- > 2) Users are pissed off, because they clicked on a web page, and got nothing > back. They retry on their screen, or they try another site. Meanwhile, the > underlying TCP connection remains there, pumping the network full of more > packets on that old path, which is