Hey Chris! Awesome explanation, very intuitive. One correction though. The Bandwidth Delay product should be in Bytes (or bits) and not Bytes per second. Other than that, great!
Hey! For this video, no. I didn't end up deciding to share them with the YT audience, but.. there are several other ones on my channel that act similar. Sorry.
Chris, how would one go about simulating network congestion like this, as a way to help test a web app's robustness in the wild [when it has a low keepalive]?
This is awesome content. Thank you for sharing this knowledge. There is one thing that messes with me; is there a rule/standard, when the receiver sends an Ack? I read a few things. Every other full segment, a certain amount of time, then the thing with the delayed ack's.. Is there a kind of an idle time between the congestion windows where the receiver decides to send the Ack's?
Hey and that is a great question. So it is most common to see a TCP stack ack every other received segment, however this is adjustable in most operating systems. In some applications, I see the receiving TCP ack a whole block of data, like 10 MSS segments for example. Here is an article that shows how and where this value can be adjusted in Windows 10. docs.microsoft.com/en-us/troubleshoot/windows-server/networking/registry-entry-control-tcp-acknowledgment-behavior
3:16 And here we are in 2021, customers crave speed and are willing to pay extra to have a 1Gbit network connection delivered to their home aaand... then they expect that a single 2.4GHz AP (badly placed as well, no cables around the house!) to cover their entire flat/home. And they don't want any cables installed. Because "wHo UsES caBLeS iN 2021?". Ah, the blissful ignorance of consumers :-)
Apart from awesome content, the presentation is cherry on the cake. It is very engaging and lovely.
Wow, thank you!
Echoing everyone else here - this is a fantastic talk. Thank you so much!
Sure thing! Thanks for the comment and for stopping by my channel. Please like/share/subscribe.
53:30 thank you! I’ve been searching for the answer to this question!
u r my mentor. i want to learn more about bandwidth delay product
Jut subscribed yesterday since I am planning to deeper in Wireshark and this video is Amazing!
Great to have you here Lucas, enjoy!
Thank You Chris. Please keep posting such videos.
Thanks for this presentation. I learned some of the material the hard way 😂.
Glad it was helpful!
Absolutely Awesome 😊 Thank you very much for detailed explanation !!
Thank you! Glad you liked it.
This content is amazing - Chris, you are a life saver !
Thanks for the comment!
I would say WOW!! What an explanation with really good example. Keep uploading on such bottleneck topics. Thank You Chris
Thanks for the comment Anas!
Thankyou Chris, great explanation
Glad it was helpful!
Good Job Chris. Content is excellent.
Really enjoying this content - Thanks Chris.
You bet Scott - I'll keep working on more.
@@ChrisGreer Is it normal to see a keep-alive with a reset after it in a trace?
Excellent Chris
Thanks!
Hey Chris! Awesome explanation, very intuitive. One correction though. The Bandwidth Delay product should be in Bytes (or bits) and not Bytes per second. Other than that, great!
Hello Babies, I appreciate you pointing that out - I have been meaning to fix that error. Unfortunately it is tough at this point.
Excellent content. Learnt a lot. Thank you Chris.
Thanks for the comment Shruthi! I'm really glad you liked it.
Hi Chris,
Where did 150 ms come from?
In the first example you gave.
Hope you can help me.
You are a Rock Star
Thanks Asif! I appreciate the comment.
Is there any way to get the packet files to do the exercise as we follow the video? Huge thanks for your talk by the way ;-)
Hey! For this video, no. I didn't end up deciding to share them with the YT audience, but.. there are several other ones on my channel that act similar. Sorry.
Chris, how would one go about simulating network congestion like this, as a way to help test a web app's robustness in the wild [when it has a low keepalive]?
Genius. Best explanation since 2018 from a guy called Chris Greer i guess. :)
Thanks Andreas!
This is awesome content. Thank you for sharing this knowledge.
There is one thing that messes with me; is there a rule/standard, when the receiver sends an Ack? I read a few things. Every other full
segment, a certain amount of time, then the thing with the delayed ack's.. Is there a kind of an idle time between the congestion windows where the receiver decides to send the Ack's?
Hey and that is a great question. So it is most common to see a TCP stack ack every other received segment, however this is adjustable in most operating systems. In some applications, I see the receiving TCP ack a whole block of data, like 10 MSS segments for example. Here is an article that shows how and where this value can be adjusted in Windows 10. docs.microsoft.com/en-us/troubleshoot/windows-server/networking/registry-entry-control-tcp-acknowledgment-behavior
Thank you, I learn a lot today!
Excellent!
Was the session after the break recorded?
audience was dead bro, I would have shouted my lungs out :p great job though, Chris!
Thanks Patgame - no worries I could hear you shout across UA-cam! Appreciate the comment.
Excellent.
Thank you!
Great Content thanks
buen videito :)
Thank you
You're welcome
This is just great
3:16 And here we are in 2021, customers crave speed and are willing to pay extra to have a 1Gbit network connection delivered to their home aaand... then they expect that a single 2.4GHz AP (badly placed as well, no cables around the house!) to cover their entire flat/home. And they don't want any cables installed. Because "wHo UsES caBLeS iN 2021?". Ah, the blissful ignorance of consumers :-)
No kidding!
TAKE TIME SHOULD DIRECT TO THE POINT ON TOPIC TO IM GONNA FELT SLEEPY LISTENING
Your hose analogy is completely wrong. It makes no sense. You should rethink it.