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 MyPCServer TCP HTTPS= 2821020, L=0, A= 0 2 Server MyPCTCP HTTPS=2134278484, L=0, A= 2821021 3 MyPCServer TCP HTTPS= 2821021, L=0, A=2134278485 4 MyPCServer TCP HTTPS= 2821021, L= 384, A=2134278485 5 Server MyPCTCP HTTPS=2134278485, L=0, A= 2821405 6 Server MyPCTCP HTTPS=2134278485, L= 156, A= 2821405 7 MyPCServer TCP HTTPS= 2821405, L=0, A=2134278641 8 MyPCServer TCP HTTPS= 2821405, L= 304, A=2134278641 9 Server MyPCTCP HTTPS=2134278641, L=0, A= 2821709 10 Server MyPCTCP HTTPS=2134278641, L= 156, A= 2821709 11 MyPCServer TCP HTTPS= 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=6904&t=6899 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: TCP Sliding Windows question [7:6899]
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 MyPCServer TCP HTTPS= 2821020, L=0, A= 0 2 Server MyPCTCP HTTPS=2134278484, L=0, A= 2821021 3 MyPCServer TCP HTTPS= 2821021, L=0, A=2134278485 4 MyPCServer TCP HTTPS= 2821021, L= 384, A=2134278485 5 Server MyPCTCP HTTPS=2134278485, L=0, A= 2821405 6 Server MyPCTCP HTTPS=2134278485, L= 156, A= 2821405 7 MyPCServer TCP HTTPS= 2821405, L=0, A=2134278641 8 MyPCServer TCP HTTPS= 2821405, L= 304, A=2134278641 9 Server MyPCTCP HTTPS=2134278641, L=0, A= 2821709 10 Server MyPCTCP HTTPS=2134278641, L= 156, A= 2821709 11 MyPCServer TCP HTTPS= 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.
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
Re: TCP Sliding Windows question [7:6899]
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
Re: Subject: Re: TCP Sliding Windows question [7:6899]
Comments within and below. > 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). Are you referring to packet burst? In essence, this is what you described(watch wrap): http://support.novell.com/cgi- bin/search/searchtid.cgi?/2947728.htm It was my understanding that many folks wanted to disable this capability and the article makes mention of this in a note on the bottom: "Note: Customers have reported that the MS Client for NetWare may cause high utilization on NetWare servers.. Disabling the Packet Burst functionality of the MS Client resolves the high utilization problem. According to one customer, the following registry edit disables Packet Burst on the MS Client:" Still, the intent was good. Many folks also associate sliding windows with SPX. Technically, that is not correct. True windowing did not really happen until SPX II, which also facilitated orderly closure of the connection (if requested). 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? SPX II to be more precise. In a way, one can regard packet burst as a windowing mechanism, but it was not as refined as SPX II (IMHO). The real issue is why Novell missed the boat on IP. Too little, too late. I am a big fan of Novell Netware. It is a rock solid NOS. Unfortunately market share typically dictates what will be used. The Beta vs. VHS wars are a prime example. Yes, I still have a working Betamax :-) v/r, Paul Werner Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=6954&t=6899 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Subject: Re: TCP Sliding Windows question [7:6899]
Priscilla's explanation is right on the money I have added a few comments to expand on some areas that were not mentioned. See below. > 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. Very correct. The only way to see this is to "count the bytes" as the go across the wire. To help a little bit, I have included an ASCII capture summary for a TTCP transfer (watch wrap): http://www.west- point.org/users/usma1983/40768/chesinc/docs/ttcp2.txt This is not a theoretical capture, rather a real 10 minute transfer between two windows hosts using a direct connection with a crossover cable. If you look at the first sequence number, you will see it is SEQ=20602846 . Look at the window size and the packet length size (8760 and 1460 respectively). We should expect to see five more packets cross the wire before an ACK is sent. You will note that the next sequence number (SEQ=20604306) reflects an additional 1460 bytes. Finally, look at the ACK. Note that the ACK is indicating, "Hey, I want to see the **Next** 1460 bytes, hence the number ACK=20611606. This is considered a positive or expectational acknowledgement. The almost full headers are here(watch wrap): http://www.west- point.org/users/usma1983/40768/chesinc/docs/ttcp.txt > 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. What is equally important is that the ISN (Initial sequence number) should be a truly random value, so as not to allow hackers to spoof a connection. There are some pretty well documented cases where this was not done, most recently with the CBOS on the 600 series routers. Also, one point of note is the issue of selective acknowledgements and negative acknowledgements. Originally, most Internet hosts did not have a TCP/IP stack that incorporated SACKs. With the advent of Solaris 8 and Win 98, SACKs were employed in major operating systems. The effect of the selective acknowledgment (as opposed to the negative acknowledgement is as follows. In the instance where you had the transfer I mentioned above, consider the situation where I received segments 1 and 2, missed segment 3, then received segments 4, 5, and 6. Would it not be a little bit more efficient to tell the server that I at least got segments 1 and 2? That is the point behind SACKs. In the case of negative acknowlegements, the intent would be to say to the server, "okay, big guy, it looks like I got everything except segment number 2. Whaddya say we resend segment number 2 just to make things complete?" Negative acknowledgments are not supported, and likely will not be supported unless the TCP specification is rewritten. Frankly, a good sliding window and SACKs seems to be sufficient for optimization. I **Strongly** agree with Priscilla's endorsement of TCP/IP Illustrated, by W. Richard Stevens. Unfortunately, it is copyrighted September, 1994. It will never be updated by the original author, since he passed away recently. My understanding is that his wife is trying to find somebody suitable to make a next edition (which is long overdue). I hope a suitable person will be found. The Stevens book is a *must* read if you want to understand TCP/IP. v/r, Paul Werner Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=6960&t=6899 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
