Thanks, PO.
I should add that after I posted, I continued my reading, and a couple of
pages later, Comer goes into a detailed explanation about how this works.
Let me try to explain in my own words, and let's see if I "get it".
Starting with me as a user. I want to download a Windows NT service pack -
mucho megabytes.
Before the file transfer actually begins, the TCP deamons on my PC and the
Microsoft server agree on a window size. I'm going to use round numbers to
male the math easier. We agree that the window size is 64K bytes - the
server will send me 64K bytes before it expects an ack from me. Let's
further say for argument's sake that the MTU throughout the network path is
1000 bytes. I'm also going to skip calculations involving headers and stuff
because I want to keep this simple. But I do understand that TCP and IP
header sizes are accounted for by the sending TCP deamon.
OK, the window size is 64K bytes, and the packet size is going to be 1000
bytes. Therefore TCP can send 64 packets ( segments ) before expecting an
ack.
All right - file transfer begins. My machine receives the first packet. It
sends an ack that tells the sender that of that 64K byte window, I have
received bytes 1 through 1000. Now, suppose some packets arrive out of
sequence. Let's say I receive packet 20 before I receive packet 19 ( of the
64 packets accounted for in the TCP window my ack tells the sender that I
have received bytes20,001 through 21,000. If I never ack packet 19, ( or
rather, the bytes contained within that stream ) then only packet 19 is
retransmitted by the sender.
The fact that a number of packets ( number of bytes ) can be sent before
requiring acknowledgement makes the whole process a lot more efficient.
That's where I got confused. For whatever reason I had come to believe that
TCP acknowledged based on packets. I believe I understand this now. TCP
operates on packets ( segments is the more correct term ) and acknowledges
that it has received so many bytes out of the byte count indicated by the
window size.
Amazing how it makes sense when you 1) read the material and 2) apply a bit
of thought.
Thanks again
Chuck
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
Priscilla Oppenheimer
Sent: Saturday, June 02, 2001 12:37 PM
To: [EMAIL PROTECTED]
Subject: Re: TCP Sliding Windows question [7:6899]
TCP sequences bytes. A lot of people assume that TCP sequences packets or
segments, but that's not true.
The sequence number in a TCP header is the sequence number of the first
byte in the payload. It's not a segment number. The ACK is the number of
the next byte of payload expected. It's not a segment number. The sliding
window keeps track of how many bytes have been sent and acknowledged.
The 3-way handshake kind of breaks this rule, which is probably why people
get confused. They never go past the 3-way handshake. With the 3-way
handshake, there are no payload bytes. The recipient's ACK number is
nonetheless one more than the other side's SEQ number.
Follow the sequence number and ACKs in the following trace, after you get
past the 3-way handshake in packets 1-3:
1 MyPC Server TCP HTTP S= 2821020, L= 0, A= 0
2 Server MyPC TCP HTTP S=2134278484, L= 0, A= 2821021
3 MyPC Server TCP HTTP S= 2821021, L= 0, A=2134278485
4 MyPC Server TCP HTTP S= 2821021, L= 384, A=2134278485
5 Server MyPC TCP HTTP S=2134278485, L= 0, A= 2821405
6 Server MyPC TCP HTTP S=2134278485, L= 156, A= 2821405
7 MyPC Server TCP HTTP S= 2821405, L= 0, A=2134278641
8 MyPC Server TCP HTTP S= 2821405, L= 304, A=2134278641
9 Server MyPC TCP HTTP S=2134278641, L= 0, A= 2821709
10 Server MyPC TCP HTTP S=2134278641, L= 156, A= 2821709
11 MyPC Server TCP HTTP S= 2821709, L= 0, A=2134278797
Priscilla
At 02:10 PM 6/2/01, Chuck Larrieu wrote:
>I am reading Doug Comer's excellent book Internetworking with TCP/IP vol 1.
>Highly recommended, and I wish I had followed the good advice of several
>other people on this list, and read the book a year ago.
>
>I have a question on sliding windows as Comer describes it: "The TCP
sliding
>window mechanism operates at the octet level, not at the segment or packet
>level" Comer goes on to describe the operation of the mechanism, and
>indicates that acknowledgements occur octet for octet.
>
>This strikes me as highly inefficient, and something that would render TCP
>unusable in networks of any size. Because acknowledgements are based on
>sequence numbers, there would have to be a TCP header for every octet. Not
>good at all.
>
>I am no doubt missing something fundamental here. Perhaps TCP stack
>implementations are written in such a way that the "octets" being sent and
>acknowledge via the sliding window mechanism are really segments / packets?
>I.e. hundreds of octets at a time?
>
>Can someone enlighten me?
>
>Chuck
>
>One IOS to forward them all.
>One IOS to find them.
>One IOS to summarize them all
>And in the routing table bind them.
>
>-JRR Chambers-
________________________
Priscilla Oppenheimer
http://www.priscilla.com
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=6913&t=6899
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
