I use the example all the time, but not for interviewing. What's sad is that
the answers seem to be quoting from some set of textbooks or popular
explanations of the Internet that really have got it all wrong, but which many
professionals seem to believe is true.
The same phenomenon appears
On Mon, 20 Sep 2021, Valdis Klētnieks wrote:
On Sun, 19 Sep 2021 18:21:56 -0700, Dave Taht said:
what actually happens during a web page load,
I'm pretty sure that nobody actually understands that anymore, in any
more than handwaving levels.
This is my favorite interview question, it's
On Sun, 19 Sep 2021 18:21:56 -0700, Dave Taht said:
> what actually happens during a web page load,
I'm pretty sure that nobody actually understands that anymore, in any
more than handwaving levels.
I have a nice Chrome extension called IPvFoo that actually tracks the IP
addresses contacted
I just wanted to comment on how awesome this thread was, and how few
people outside this group deeply grok what was discussed here. I would
so like
to somehow construct an educational TV series explaining "How the
Internet really works" to a wider, and new audience, consisting of
animations,
--- Begin Message ---
Thanks for this. I plan to purchase the second volume to go with my copy of
volume 1. There is (always) more to learn and your expertise is very
helpful.
Bob
PS. As a side note, I've added support for TCP_NOTSENT_LOWAT in iperf 2.1.4
--- Begin Message ---
Just an FYI,
iperf 2 uses a 4 usec delay for TCP and 100 usec delay for UDP to fill the
token bucket. We thought about providing a knob for this but decided not
to. We figured a busy wait CPU thread wasn't a big deal because of the
trend of many CPU cores. The threaded
On Mon, Jul 12, 2021 at 1:32 PM Ben Greear wrote:
> 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
--- Begin Message ---
From: Bob McMahon via Bloat
> Date: Wed,2021-07-14 at 11:38 AM
> One challenge I faced with iperf 2 was around flow control's effects on
> latency. I find if iperf 2 rate limits on writes then the end/end
> latencies, RTT look good because the pipe is basically empty, while
--- Begin Message ---
Ok, adding support for TCP_WINDOW_CLAMP and TCP_NOTSENT_LOWAT into iperf 2
seems useful for TCP WiFi latency related testing. These option names are
quite obfuscated. I can't see many but some ultimate networking geeks
knowing what these actually do.
Here are some proposed
--- Begin Message ---
Thanks for this. I find it both interesting and useful. Learning from those
who came before me reminds me of "standing on the shoulders of giants." I
try to teach my kids that it's not so much us as the giants we choose - so
choose judiciously and, more importantly, be
Bob -
On Tuesday, July 13, 2021 1:07pm, "Bob McMahon" said:
> "Control at endpoints benefits greatly from even small amounts of
> information supplied by the network about the degree of congestion present
> on the path."
>
> Agreed. The ECN mechanism seems like a shared thermostat in a
--- Begin Message ---
"the infinite TCP flow that converges to a steady behavior is purely
academic"
We find this to be mostly true. Sadly, the tools such as iperf drove to
this condition. While still useful, not realistic.
We added, in iperf 2, the ability to test TCP bursts (--burst-size and
--- Begin Message ---
"Control at endpoints benefits greatly from even small amounts of
information supplied by the network about the degree of congestion present
on the path."
Agreed. The ECN mechanism seems like a shared thermostat in a building.
It's basically an on/off where everyone is
Ben,
it depends on what one tries to measure. Doing a rate scan using UDP (to
measure latency distributions under load) is the best thing that we have but
without actually knowing how resources are shared (fair share as in WiFi, FIFO
as nearly everywhere else) it becomes very difficult to
--- 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.
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
--- 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
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
--- 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
--- 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
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
--- 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
> On 10 Jul, 2021, at 2:01 am, Leonard Kleinrock wrote:
>
> No question that non-stationarity and instability are what we often see in
> networks. And, non-stationarity and instability are both topics that lead to
> very complex analytical problems in queueing theory. You can find some
>
--- Begin Message ---
"Holland, Jake via Bloat" writes:
> Hi David,
>
> That’s an interesting point, and I think you’re right that packet
> arrival is poorly modeled as a Poisson process, because in practice
> packet transmissions are very rarely unrelated to other packet
> transmissions.
>
>
--- Begin Message ---
Hi David,
That’s an interesting point, and I think you’re right that packet arrival is
poorly modeled as a Poisson process, because in practice packet transmissions
are very rarely unrelated to other packet transmissions.
But now you’ve got me wondering what the right
25 matches
Mail list logo
