TCP Error Recovery/Windowing stuff

ccnxjrccnxjr Member Posts: 304
in CCNA & CCENT
As often as I read it over in Odom's book, i just can't quite get it.
Can anyone briefly explain it or refer to a well written article (almost 8th grade level readability).
Much appreciated.

Basically if i send packets from host A with sequence numbers 2300, 2800, 3200 , to Host B.
What would the ACK be?
How would i know what packets Host B missed?

Something along those lines, I think I got the big picture , the details are a little fuzzy , especially since I saw a few questions of that nature pop up in practice , and they almost exclusively refer to Odom's book icon_neutral.gif

(pages 140-143, "CCENT/CCNA ICND1" second edition in case your wondering if i actually read it....)
· Share on FacebookShare on Twitter

Comments

  • Forsaken_GAForsaken_GA Member Posts: 4,024
    ccnxjr wrote: »
    As often as I read it over in Odom's book, i just can't quite get it.
    Can anyone briefly explain it or refer to a well written article (almost 8th grade level readability).
    Much appreciated.

    Basically if i send packets from host A with sequence numbers 2300, 2800, 3200 , to Host B.
    What would the ACK be?
    How would i know what packets Host B missed?

    Something along those lines, I think I got the big picture , the details are a little fuzzy , especially since I saw a few questions of that nature pop up in practice , and they almost exclusively refer to Odom's book icon_neutral.gif

    (pages 140-143, "CCENT/CCNA ICND1" second edition in case your wondering if i actually read it....)

    Well it depends on the window size and on the TCP implementation. If Host B had enough to take all the packets you've sent, then it would ACK back with 3200 and Host A would know that everything up to that point has been received.

    If Host B only had received everything up to 2800 and the stuff from 2801 to 3200 was lost, it would ACK back with 2800, and eventually Host A would realize that it needed to resend some stuff, cut the window in half, and begin the slow start process
    · Share on FacebookShare on Twitter
  • Forsaken_GAForsaken_GA Member Posts: 4,024
    If you really want to get into the guts of how TCP works, pick up one (or both) of these books

    Amazon.com: TCP/IP Illustrated, Volume 1: The Protocols (9780201633467): W. Richard Stevens: Books

    Amazon.com: Internetworking with TCP/IP Vol.1: Principles, Protocols, and Architecture (4th Edition) (9780130183804): Douglas E. Comer: Books

    They're both pretty good. The Comer book is pretty much theoretical, which is what I suspect you need to get your head wrapped around the concepts, and it's also dirt cheap (less than 10 bucks, including shipping, if you buy it used).

    The Stevens book is more practical, and alot more techy, but it will also teach you to use tcpdump, which is a skill that every network engineer needs.
    · Share on FacebookShare on Twitter
  • jmc012jmc012 Member Posts: 134
    ccnxjr wrote: »
    As often as I read it over in Odom's book, i just can't quite get it.
    Can anyone briefly explain it or refer to a well written article (almost 8th grade level readability).
    Much appreciated.

    Basically if i send packets from host A with sequence numbers 2300, 2800, 3200 , to Host B.
    What would the ACK be?
    How would i know what packets Host B missed?

    Something along those lines, I think I got the big picture , the details are a little fuzzy , especially since I saw a few questions of that nature pop up in practice , and they almost exclusively refer to Odom's book icon_neutral.gif

    (pages 140-143, "CCENT/CCNA ICND1" second edition in case your wondering if i actually read it....)

    With forward acknowledgment and no errors it would ack back 3600 letting it know which sequence it expects next. WIth errors it would ack the same segment number it missed and then continue on with say 3600.
    · Share on FacebookShare on Twitter
  • Met44Met44 Member Posts: 194
    Vanilla TCP uses cumulative ACKs, which would mean you acknowledge all packets that you have already received by sending an ACK for the next sequence number you expect. If you expect to receive 100, 200, and 300, and you only receive 100 and 300, you send an ACK 200. You received 100 and are waiting on 200. At this point, the sender only knows you have received 100; it doesn't know that you have 300 -- indeed, you could have ignored it because it was out of sequence. However, if you expect to receive 100, 200, and 300, and you do receive all three sequences, you send an ACK for the next sequence number you expect, 400. The key is that only consecutive sequence numbers are ACKed. How the sender handles retransmission may vary. The cumulative ACK logic is what most people think of when they think of acknowledgement and retransmission in TCP. See the original TCP RFC for more information: http://www.ietf.org/rfc/rfc0793.txt.

    Selective ACKs are a more modern way to acknowledge data. This approach prevents some of the inefficiencies of cumulative ACKs when multiple packets are dropped. It probably isn't that important for the CCNA, but it's the way things really work in most modern implementations. See RFC 2018 if you are interested in more detailed information on selective ACKs: http://www.ietf.org/rfc/rfc2018.txt.

    The Stevens TCP/IP Illustrated book is an excellent reference. I initially picked it up for its section on TCP, but found that it only covers cumulative ACKs. With good reason though: the book predates TCP selective ACKs. Oops. This is still a great recommendation; it's a good book for what it is. Just realize that there are a lot of nuances and additions to TCP that have been brewing since this book was written.
    · Share on FacebookShare on Twitter
  • ccnxjrccnxjr Member Posts: 304
    Think I got it now.
    Gonna hit the test sims again.
    Thanks for your help!

    So basically the "ACK" tells the sender, what packet to send?
    If it sends a whole slew of 'em it the receiver will send an ACK for the next packet to follow, whether it be a missed packet or brand one.
    · Share on FacebookShare on Twitter
  • typeshtypesh Member Posts: 168
    Forsaken_GA wrote: »
    If you really want to get into the guts of how TCP works, pick up one (or both) of these books

    Amazon.com: TCP/IP Illustrated, Volume 1: The Protocols (9780201633467): W. Richard Stevens: Books


    Hey Forsaken,

    Awesome book! Read this post, previewed it on Google Books, and decided to pick it up. It's really interesting and has helped me understand the protocol suite a lot more. Hard to put it down sometimes :) Thanks for the recommendation!
    · Share on FacebookShare on Twitter
  • Forsaken_GAForsaken_GA Member Posts: 4,024
    Yeah, both books are excellent, though Stevens can get a little technical, and if you don't have much of a Unix background, it can be a little daunting (and parts of it *are* a bit dated).

    However, I think Stevens should be required reading for everyone just because of the introduction it gives you to tcpdump. That and nmap are two tools *every* network engineer should be proficient with
    · Share on FacebookShare on Twitter
Sign In or Register to comment.