At 02:31 PM 6/2/01, Chuck Larrieu wrote:
>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.
The two communicating stations do not agree on a window size. Each side has
its own window size. A low-end PC might start with a small window size. A
big UNIX ;-) server would likely start with a large window size. I took out
the window size parameter in my example below to simplify matters, but my
Windows 98 PC started with a window size of 8760 bytes. The server started
with 17520 bytes. The window size is advertised in each packet. It
specifies how many bytes the station is ready to receive at this time. It
can slide closed as a station gets overwhelmed. Hopefully it slides back
open as the station hands off bytes from its buffers to the application.
>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.
Each side specifies the size of the segment it can receive in the 3-way
handshake. The Max Segment Size (MSS) is a TCP option, one of the few ever
used. It does not count the TCP or IP header. In my example, both my PC and
the server said the their maximum segment size was 1460 bytes. So, in that
sense, they took into account the TCP and IP header sizes and understood
the MTU, as you say.
>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.
Segment size is 1000 bytes, OK.
>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.
There's no need to send an ACK yet if the window size is 64 K.
>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.
Packets aren't numbered, so your wording is bugging me, and I don't think
the concept is quite right either. The ACK specifies the byte I expect to
receive next. It is a single number, not a range. If bytes are missing, I
have to keep the ACK at the first byte of the hole. The sender resends
everything from there on.
If I advertised a window size of 64 K and an MSS of 1000, then I don't have
to ACK each packet. I may have time to sort out packets that are out of
order as opposed to missing, if that's what you're getting at.
>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 right. That's the main thing to understand.
>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.
Don't confuse reliability with flow control. ACKs are used for reliability.
Windows are used for flow control.
You may have better luck with Stevens, "TCP/IP Illustrated." If you can,
block out some time to study this with a Sniffer. That's how I learned it.
Then you can start learning about Nagle, etc.!
Priscilla
>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
________________________
Priscilla Oppenheimer
http://www.priscilla.com
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=6915&t=6899
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
