NeoPen and Surface Book (what I use) have it natively too. I like the true pen and paper because it gives me great control. But NeoPen has highlighting ability which I'll use to highlight a particular part of the diagram.
LOLOLOLOLOLOL. I didn't take my Jabra headset off. The microphone is actually a stand-alone although it looks like it's part of the Jabra unit. Like I said, I'll get better!
As a network guy I found this conceptual video very useful for a deeper understanding of what is going on at the two endpoints as they have a chat - Thank you.
My pleasure! I hope to visit the land down under one of these days. Would you believe that I had three trips that had to be canceled for various reasons?
I have been greatly looking forward to this course. I would like to learn more about buffer bloat you mentioned toward the end. Thanks for your time in creating this content.
I hope that one day, I can communicate my ideas clearly, precisely, and passionately like you, Mr. Bae. Thanks for the informative video. I'm a fan from New Zealand!
Jamie, thanks for the kind words. Also, a few days ago, I learned that NZ'ers eat more ice cream per capita than anyone else! And since I watch Scott Brown Carpentry all the time, I'm picking up some local lingo. Like "Smoko time" 😁
Hi Hansang! Great to see your series starting at the very basic. My first book was the Comer (at the time it was red) I was watching your video on a phone this morning and the drawing was really too small to read. If you can try to zoom in (Reminds me of some wireshark videos you did at 1920x1080 pixels.) Looking forward to Wireshark wednesday...
Merci, Francois! Yeah, at Sharkfest, I was able to go to full screen. So I'll play with it and see how I can make it more legible. Good to hear from you! And D'OH! Wireshark Wednesday, so much better. I do these videos with one take so nothing is scripted. But Wireshark Wed is soooo obvious! :)
10:48 which one of the statement is right, 1) The packet is pushed to the wire and a copy of the packet is sent to the send buffer 2) The application sends the packet to the send buffer and then a copy is made from send buffer to the wire. I am also having confusion on who makes these copies of packet, the application or the OS. Can there is a corruption of packets on wire/send buffer. Appreciate your answer in advance.
The application tells the OS what buffers to use. So the app writes to the socket, and the OS and TCP stack take care of the rest. Application has no idea what the OS/TCP is doing. It just flushes the buffer and calls it a day.
Fantasic session :-) How can we monitor the state/size/utilization of receive or sent buffer. I have come across a issue where the OS (Windows 2012) shows significantly large incoming packet discards; and we need to know if the packets were discarded because the buffer was full or application not being able to consume the packets. Thanks again and looking forward to more sessions.
Hey Hansang, I am a big fun since your riverbed webnars. It really helped me in my job in traffic analisys. I love to see you on these independet effort I commend you and thank you because it is a noble cause to help others. I have a questions about calculating packets and connections per second, on a x size bandwith link. I read this document from Cisco which it was good to understand more on the device's interface capabilities but I would to know how to calculate an estimate as close to reallity as possible of how many packets would fill a pipe. tools.cisco.com/security/center/resources/network_performance_metrics
That's a topic worthy of multiple sessions because there's actually quite a bit that goes into it. Serialization delay, propagation delay, microbursts etc. So stay tuned and I'll hit those topics. The Cisco link does take into account that lot of tools don't, like IFG. I'll get into those topcis as well.
@@hansangb Hey Hansang, thank you very much for taking the time to answer my question around bandwith but really it was more about throughput and how many packets of X size would fill a pipe of Y "size/speed" at a give time. In other words you could see it as how much time it takes for a packet to cross the cricuit and the next packet up and so on, taking into acount all those factors as serialization, buffer, media type etc, but maybe more simplistically just as overall math rule. If I want to for example as the link suggested I want to size a Firewall based on how many packets its datasheets says it can handle per second, plus the total (new connections/sessions + existing ) Oh and by the way I know there is discrepancies between a session and connections from a vendor estand point so I would like to hear you take on it. Hopefully I am making sense I am sorry to bother specially because I know I am not the only one asking questions. I can write to you directly if you provide your email.
Hi Cory, A RFC is a 'request for comment' and is a way to define standards. Have a look at tools.ietf.org/rfc/index to see what's out there. The standards help different systems exchange information (from various levels) and how stuff should be build to ensure they 'understand' each other. HTH
Please ask any questions you have here. I'll make a quick "answer video" on Sunday...I mean SYN+ACK Sunday!
Use epic pen app to show examples on paper.
NeoPen and Surface Book (what I use) have it natively too. I like the true pen and paper because it gives me great control. But NeoPen has highlighting ability which I'll use to highlight a particular part of the diagram.
I think I know a few things about TCP but I still like to watch Hansang talking about it. Well done! :)
LOL! Thank you brother! I'll vouch for your knowledge of packet analysis! Top Shelf that's for sure!
Same here Jasper. It's always good to hear different approaches.
LOLOLOLOLOLOL. I didn't take my Jabra headset off. The microphone is actually a stand-alone although it looks like it's part of the Jabra unit. Like I said, I'll get better!
This is going to be great!! Thank you for starting from the beginning!
It's a little different than digging in to a trace file. It'll get better, I promise!
Amazing explanation.. learned a lot in only 20 mins
Thank you Omari, more to come!
Thank you for explaining the TCP send and receive buffer concept so clearly Mr. Hansang, greetings from Europe.
My pleasure!
As a network guy I found this conceptual video very useful for a deeper understanding of what is going on at the two endpoints as they have a chat - Thank you.
It really is my pleasure! More to come and we'll hit the packets soon.
Thank you for making this. We really appreciate you. I watched all your Sharkfest presentations.
We'll get to Sharkfest like videos soon. Stay tuned
Great job Hansang!! Reinforcing the basics really helps. Thanks and looking forward to your future videos.
Happy to hear that! We'll talk about why buffers can impact performance so much next.
Love your work Hansang; appreciate you taking the time to do this. Always learn a lot from your sessions :-)
From Australia
My pleasure! I hope to visit the land down under one of these days. Would you believe that I had three trips that had to be canceled for various reasons?
Excited to see this first video published Hangsang!
Thank you Brendan. Please say hello to Lenny for me!
Thanks, Hansang it's a really simple way of explaining complected things
Thank you Sandeep. I want to build the right foundation because all the knowledge kicks in when troubleshooting.
Wonderful session. Eager to learn more about buffer-bloat and MSS.
Looking forward to upcoming videos.
More to come!
I have been greatly looking forward to this course. I would like to learn more about buffer bloat you mentioned toward the end. Thanks for your time in creating this content.
Coming soon! It's an advanced'ish topic so be patient with me.
Glad to see you on youtube. Great! ----from ex-RVBD China SE : )
Hey, thanks! Hope you guys are all safe and sound! If you see Patrick and team, tell themI said hello!
I hope that one day, I can communicate my ideas clearly, precisely, and passionately like you, Mr. Bae. Thanks for the informative video. I'm a fan from New Zealand!
Jamie, thanks for the kind words. Also, a few days ago, I learned that NZ'ers eat more ice cream per capita than anyone else! And since I watch Scott Brown Carpentry all the time, I'm picking up some local lingo. Like "Smoko time" 😁
What an insightful session!! Learned a lot. Great work! Keep going.
Thank you Bablu, that's very kind of you to say. And thanks for subscribing.
Great start! Thank you very much for doing this.
My pleasure!
Excited Hansang looking forward to going through the course
We'll build slowly, but we'll get to the fun stuff soon.
Hi Hansang!
Great to see your series starting at the very basic.
My first book was the Comer (at the time it was red)
I was watching your video on a phone this morning and the drawing was really too small to read.
If you can try to zoom in (Reminds me of some wireshark videos you did at 1920x1080 pixels.)
Looking forward to Wireshark wednesday...
Merci, Francois! Yeah, at Sharkfest, I was able to go to full screen. So I'll play with it and see how I can make it more legible. Good to hear from you! And D'OH! Wireshark Wednesday, so much better. I do these videos with one take so nothing is scripted. But Wireshark Wed is soooo obvious! :)
Excellent, will wait for all your future releases
More to come!
Very good presentation and practical knowledge of this concept. Thank you
Thank you so much. I finally uploaded the new video in this series. It only took 18 months or so! :) ua-cam.com/video/q3hEwWQurXI/v-deo.html
I like it, looking forward to more tcp sessions!
Coming soon!
Thank you for sharing some of your skill
!
Thank you!
Thank you Hansang. Hope to see you sometime at SF.
Oh how I miss BIg Nate's BBQ! It was so good too. Rudy's in San Antonio was a "little bit" better, but I *loved* Big Nates!
Many thanks Hansang. Much appreciated.
You are very welcome
Awesome! Can't wait for more!
More to come! thanks for watching
10:48 which one of the statement is right, 1) The packet is pushed to the wire and a copy of the packet is sent to the send buffer 2) The application sends the packet to the send buffer and then a copy is made from send buffer to the wire. I am also having confusion on who makes these copies of packet, the application or the OS. Can there is a corruption of packets on wire/send buffer. Appreciate your answer in advance.
The application tells the OS what buffers to use. So the app writes to the socket, and the OS and TCP stack take care of the rest. Application has no idea what the OS/TCP is doing. It just flushes the buffer and calls it a day.
Fantasic session :-) How can we monitor the state/size/utilization of receive or sent buffer. I have come across a issue where the OS (Windows 2012) shows significantly large incoming packet discards; and we need to know if the packets were discarded because the buffer was full or application not being able to consume the packets. Thanks again and looking forward to more sessions.
Will be answered on the Q&A video coming out today or tomorrow.
Thanks to @Kary Rogers for introducing you to us.
Good man, that Kary!
Thanks Monday = MTU
Yayyy.. finally it started
Thanks for waiting! It'll come more regularly now.
Can you please elaborate on what happens when receiver buffer size is huge and it's impacts..? I was just curious more
Yup, see pinned comment. Thanks
Monday = MTU :)
I know, right? What a fail on my part! :)
Hey Hansang, I am a big fun since your riverbed webnars. It really helped me in my job in traffic analisys. I love to see you on these independet effort I commend you and thank you because it is a noble cause to help others.
I have a questions about calculating packets and connections per second, on a x size bandwith link. I read this document from Cisco which it was good to understand more on the device's interface capabilities but I would to know how to calculate an estimate as close to reallity as possible of how many packets would fill a pipe. tools.cisco.com/security/center/resources/network_performance_metrics
That's a topic worthy of multiple sessions because there's actually quite a bit that goes into it. Serialization delay, propagation delay, microbursts etc. So stay tuned and I'll hit those topics. The Cisco link does take into account that lot of tools don't, like IFG. I'll get into those topcis as well.
@@hansangb Hey Hansang, thank you very much for taking the time to answer my question around bandwith but really it was more about throughput and how many packets of X size would fill a pipe of Y "size/speed" at a give time. In other words you could see it as how much time it takes for a packet to cross the cricuit and the next packet up and so on, taking into acount all those factors as serialization, buffer, media type etc, but maybe more simplistically just as overall math rule. If I want to for example as the link suggested I want to size a Firewall based on how many packets its datasheets says it can handle per second, plus the total (new connections/sessions + existing ) Oh and by the way I know there is discrepancies between a session and connections from a vendor estand point so I would like to hear you take on it. Hopefully I am making sense I am sorry to bother specially because I know I am not the only one asking questions. I can write to you directly if you provide your email.
M for MTU
I heard that due to COVID19 outbreak handshakes are no longer allowed! So my boss ordered me to turn off TCP/IP and only use UDP.
noice!
multiplexing mondays ;)
Ahhhh, the good old days of using MLPPP!
Mangled packet monday.
Here's the thing...I even *SAID* MSS in my video. Others suggested MTU Monday. /* smh */ So I'll just take the L :)
Monday = MTU and MSS
Hello, came across your channel just minutes ago. What is an RFC?
Hi Cory,
A RFC is a 'request for comment' and is a way to define standards. Have a look at tools.ietf.org/rfc/index to see what's out there. The standards help different systems exchange information (from various levels) and how stuff should be build to ensure they 'understand' each other. HTH
Thanks DNS Guy! I'll be mentioning Cricket Liu's book in future episodes. Like I say, Every Kiss may begin with a K, but every app begins with DNS! :)
Thank you both. 🙂
Monday MTU
why no more videos ?????
It's been a minute! :) ua-cam.com/video/q3hEwWQurXI/v-deo.html