He's just so enthusiastic about what he's talking about. Not only is the information solid, but he also uses the right analogies to make it easily understandable. Bravo
I like the way he teachs.. evrytime smile on his face .. N it's showing that , sir is actually wants to make the concepts clear to their students .. Well job.. N well explain .. ☺
This guy's courses are the best out there, I watched his CCENT and CCNA courses and I enjoyed them a lot, I so much fun and so much to learn, he's just an amazing teacher.
im extremely confused at how seq and ack numbers still work. so to put it mathematically, ack number = seq number + number of bytes sent + 1 so from 2:33 to 2:43, seq number = 0 number of bytes sent = 1000 so ack number = 0 + 1000 + 1 = 1001 (which is true as mentioned in the video) However, earlier in the video, for the three way handshake, (lets talk about the syn phase specifically) seq number = 100 number of bytes sent = 1 so shouldn't ack number be 100 + 1 + 1 = 102?
it is not supposed to maintain the sequence number when the client sends a ack segment? Because the ack segment does not consume sequence number alright? it is not carrying data.
It's about client server relationship which are basically works well in Linux OS,are the stacks are also involved in storing the bytes of data that the register/memory holds using the accumulator?
As for the ruclips.net/video/LyDqA-dAPW4/видео.html when the instructor says that acknowledgement always "whatever your sequence was, plus 1" is not actually the truth. Just made a dump in wireshark to double check. When the server_A sends, for example to server_B, 100 bytes having seq number = 10 (consider handshake is completed) server_A will get the acknowlegement 110 from the server_B (not 111) and the next packet server_A sends will have the seq number 110 so no increment by one whatsoever. The seq number equals the ack got from receiver. seq number accumulates the data already sent by the side it belongs to.
If Host A sends 1000 bytes starting with seq=0, shouldn't Host B send him ack=1000 and not 1001? 1000 Bytes go from numbers 0-999, so Host B awaits data starting with seq=1000...
The maximum MTU of an interface will depend on the hardware platform, for example IEEE 802.3 standards require a minimum MTU of 1500 bytes. That being said, the numbers in the demo pertain to “Sequence Numbers”, not necessarily sending the size of the payload, just an “Acknowledgement Number” confirming having received the data.
His explanation of flow control is misguided. This idea of "throttling" the window size based on what is being ACK'ed is part of congestion control, not flow control. In flow control, the receivers sends its window size, and the receiver adjusts accordingly.
If only my networking professor taught like this guy does. Great video, thank you for posting!
Keith Barker is his name mostly on CBT nuggets he also has his own channel on youtube
He's good
He is Keith Barker, magic in how he explains. Been watching him on CBT Nuggets for years !!
he is PRO
lool 7 years later and I just stumbled on this video, and man can that man teach
I bet all those students are great network engineers now
He's just so enthusiastic about what he's talking about. Not only is the information solid, but he also uses the right analogies to make it easily understandable. Bravo
Is this information still relevant today? Any changes?
@@ayyubyube bro I’ve quit networking lmao I’m sorry idfk what any of this video means
15 seconds in and I can see how passionate he is toward his field of study, I hope my lecturer is just 10% like him :(
I like the way he teachs.. evrytime smile on his face .. N it's showing that , sir is actually wants to make the concepts clear to their students .. Well job.. N well explain .. ☺
Sahi ho
Cisco is the gold standard for network documentation. Even on other vendors I've used Cisco KB articles or videos to understand concepts.
Keith Barker one of the best IT trainers. Thank you!
dude I didn't even recognize him !
The difference enthusiasm has when teaching is incredible! My uni needs more talent like this.
This guy's courses are the best out there, I watched his CCENT and CCNA courses and I enjoyed them a lot, I so much fun and so much to learn, he's just an amazing teacher.
Where are the CCNA courses from this instructor ?
great explanation. he was soo interesting to listen to. i could sit there all day and learn from him.
not all the heroes wear capes. Thank you sir
never thought networking could actually be this engaging!
He's none other than Keith barker.cisco legend.hats off sir
This is the best explanation I found on this topic on the entire internet.
We are so happy to hear that!
i just simply fallen in love with this video and the channel
It's just 1:35 and I am already impressed by how he teaches
this man can teach... i like how he pointed out how its unnatural information too
Never took such few time to understand the logic of the tcp c-s connection establishment, thank you so much, I was struggling a bit.
oh man i wish i had a teacher like this guy.
oh man this is like the best explanation ever!
Sooo well explained. thank you, Cisco!
thanks for the great explanation, greetings from Indonesia
Where are the CCNA courses from this instructor ?
Wow I loved it!!!! Thanks for sharing this!
Awesome lecturer !
Great explanation
My Cisco trainer was nowhere as eloquent as Keith Barker is... very lucky students to have him
im extremely confused at how seq and ack numbers still work.
so to put it mathematically,
ack number = seq number + number of bytes sent + 1
so from 2:33 to 2:43,
seq number = 0
number of bytes sent = 1000
so ack number = 0 + 1000 + 1 = 1001 (which is true as mentioned in the video)
However, earlier in the video, for the three way handshake, (lets talk about the syn phase specifically)
seq number = 100
number of bytes sent = 1
so shouldn't ack number be 100 + 1 + 1 = 102?
Hi Matthew,
Please ask your question in our study group: learningnetwork.cisco.com/community/learning_center/featured-groups
ARP is involved after DNS if the IP to mac mapping is not already cached.
This was amazing!
Best teacher
Great professor!
Great video, but I have some feedback/suggestions. When you refer to devices using this and that, it tends to confuse me.
thank you so much, you are a live saver!!
it is not supposed to maintain the sequence number when the client sends a ack segment? Because the ack segment does not consume sequence number alright? it is not carrying data.
That was a pretty good overview.
It's about client server relationship which are basically works well in Linux OS,are the stacks are also involved in storing the bytes of data that the register/memory holds using the accumulator?
so in a single three-way handshake equal to a single(one) packet data?
He is really good, thank you!
it's so clear and cool
this is quite interesting! thank you!
Hello Keith!
Nice video! Thanks!
great teacher
I could do this all day ....
I want that pen!
Great teacher!
If only my university lecturers taught like this...
He is best always
great video. really helpful
good explanation .
I love TCP!
He is the man
Super helpful, thanks
Pretty clear!
Where he from? Cisco or nike?
I have a question, The protocol TCP must send a conection each time that send a frame????
The following troubleshooting guide may be helpful to you: www.cisco.com/en/US/docs/internetworking/troubleshooting/guide/tr1907.html
Its Keith Barker!
Informative video. Stuff only a network engineer can understand ☺
It's Keith Barker
Gotta take a shot. He said "In the real world".
As for the ruclips.net/video/LyDqA-dAPW4/видео.html when the instructor says that acknowledgement always "whatever your sequence was, plus 1" is not actually the truth.
Just made a dump in wireshark to double check. When the server_A sends, for example to server_B, 100 bytes having seq number = 10 (consider handshake is completed) server_A will get the acknowlegement 110 from the server_B (not 111) and the next packet server_A sends will have the seq number 110 so no increment by one whatsoever. The seq number equals the ack got from receiver. seq number accumulates the data already sent by the side it belongs to.
awsome
tcp protocol test
does telnet use TCP ..?
srujan kumar yes, it does.
but telnet used UDP right ..?
Gordon Coves
Is that Keith Barker?
yes
heck yeah one of the best lecturers bar none
Jeremy is better :D I cannot used to for Keith voice :D ... But he is good too ;)
Mr Smradoch can understand think he gets over exited when teaching. can't fault him for that.
yea i know :) i was just sayin i like more Jeremy, he has some interestning power :) ..
wow. crisp n perfect
Is that Martin shkreli???
I was thinking wesley crusher.
udp is the future with http3
1:30
The guy asked the same question as I did... And my professor malfunctioned at that point :)
Brigitte Ford
McDermott Isle
Wait, is he the CBT Nugget guy?
Keith Barker Sir
Tcp communications is more polite than some people I know....
Tia Burgs
Princess Fields
Bernier Trail
IS FROM CBT NUGGETS
Jonathon Unions
He looks like keith barker. Okay he is keith barker 😆
If Host A sends 1000 bytes starting with seq=0, shouldn't Host B send him ack=1000 and not 1001? 1000 Bytes go from numbers 0-999, so Host B awaits data starting with seq=1000...
The maximum MTU of an interface will depend on the hardware platform, for example IEEE 802.3 standards require a minimum MTU of 1500 bytes. That being said, the numbers in the demo pertain to “Sequence Numbers”, not necessarily sending the size of the payload, just an “Acknowledgement Number” confirming having received the data.
His explanation of flow control is misguided. This idea of "throttling" the window size based on what is being ACK'ed is part of congestion control, not flow control. In flow control, the receivers sends its window size, and the receiver adjusts accordingly.
keith barker fat to fit transformation
I found this actual session.
ruclips.net/video/u-Vg3CCUHZE/видео.html
31200 Melyssa Gateway