sort of continuing, although on an IPX track
was reading Radia Perlman's book the other day, and she mentions that SPX
has a window size of 1. Now, I seem to remember from my DOS/Win3.11 days
that there was some kind of SPX burst facility available (with addition TSR
drivers). Wasn't really au-fait with networking back int those days, but
would I be right in assuming that this adds some kind of sliding window
functionality to SPX?
thanks
Andy
----- Original Message -----
From: "Priscilla Oppenheimer"
To:
Sent: Saturday, June 02, 2001 11:44 PM
Subject: RE: TCP Sliding Windows question [7:6899]
> 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=6919&t=6899
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
