Observing TCP behavior

1. Observing TCP behavior On using our classroom’s network hardware capabilities to perform experiments with TCP sockets

2. ‘slowecho.cpp’ • This is a TCP ‘echo-server’ which sends back data it receives, one-byte-at-a-time, with a user-specified time-delay after any byte has been transmitted • The user specifies a desired time-delay (in microseconds) by typing a command-line argument when this server is launched; e.g., for a one-second time-delay, type $ ./slowecho 1000000

3. ‘peekdemo.cpp’ • This is a ‘client’ for the ‘slowecho’ server, but instead of using the ‘read()’ function, it uses ‘recv()’ and it supplies ‘MSG_PEEK’ as the flag-argument, thus allowing users to watch the data arriving from ‘slowecho’ while it sits in the socket’s receive-queue • It also shrinks the size of its TCP socket’s receive-buffer, for a dramatic new demo

4. Packet ‘sniffing’ • If we turn off the socket’s ‘window scaling’ option, so the ‘window size’ field in every outgoing acknowledgement-packet’s TCP Header expresses the number of bytes of available space remaining in this client’s receive-buffer, we will create an concrete visualization for the window-size’s role

5. Setup steps We will need to use a ‘quiet’ network (e.g, our ‘eth1’ interfaces) so we won’t be distracted by seeing hundreds of irrelevant network-packets! (So those interfaces will need to configured with private IP-addresses) Step 1: logon ‘hrn23511’ Assign an IP-address to the ‘eth1’ interface and bring it UP (using ‘sudo /sbin/ifconfig’), then lauch ‘nicwatch eth1’ Step 2: logon ‘hrn23511’ Disable TCP ‘window scaling’; and then launch ‘slowecho’ with a one-second time-delay Step 3: logon ‘hrn23512’ Assign an IP-address to ‘eth1’; Launch our ‘peekdemo’ client specifying the IP-address for ‘hrn23511’ as the target-server

6. What to watch? to server from client ACK window size sequence number to server from client ACK window size sequence number

7. W. Richard Stevens “This book is the result of my being asked lots of questions on TCP/IP for which I could find no quick answers. It was then that I realized that the easiest way to obtain the answers was to run small tests, forcing certain conditions to occur, and just watch what happens.” Preface, page xix “TCP/IP Illustrated, Volume 1: The Protocols” Addison-Wesley (1994) “A book on networking needs a real network to work with along with access to the Internet”

8. The ‘silly window’ syndrome • This situation arises when data-bytes are sent one-at-a-time within TCP/IP packets • Such packets have at least 20 bytes of IP Header plus 20 bytes of TCP Header, yet only 1 byte of data, thus a 40-to-1 ratio of “protocol overhead” to “useful information” • On Ethernet, with14 more bytes of header, this yields an efficiency-rate of under 2%

9. The Nagle algorithm • It’s a means for improving the efficiency of TCP/IP networks, by reducing the number of packets that need to be transmitted • It combines several small-sized outgoing packets and sends them out all at once • (It can interact poorly with TCP’s ‘delayed acknowledgement’ algorithm, so a way to disable it is quite commonly provided)

10. pseudo-code // A high-level description of John Nagle’s algorithm for congestion control if there is any available data to send { if the window-size is >= MSS and available data >= MSS send a complete MSS packet now else { if there is unacknowledged data still in transit enqueue data in the send buffer until an ACK arrives else send available data immediately } } // NOTE: Here MSS denotes the TCP socket’s ‘Maximum Segment Size’

11. ‘usenagle.cpp’ • This program allows us to see the default behavior of Linux’s TCP implementation, by using our ‘nicwatch’ packet-sniffer • Unless it has been overridden by a TCP ‘socket option’, Linux employs the Nagle algorithm as a way to cut down on the number of TCP packets being exchanged • Use this with our ‘tcpserver.cpp’ program

12. Three windows again Launch our ‘nicwatch’ packet sniffer here Launch our ‘tcpserver’ application here Launch our ‘usenagle’ application here

13. ‘nodelay.cpp’ • This is a modified version of the code we used in the previous ‘usenagle’ program • It overrides use of the Nagle Algorithm by using the ‘TCP_NODELAY’ socket option • With ‘nicwatch’ you can see the effect on the total number of packets exchanged when we use this client with our original ‘tcpserver.cpp’ application

14. ‘corkdemo.cpp’ • This is a very different modification of our ‘usenagle’ program, which makes use of the TCP_CORK socket-option rather than TCP_NODELAY • With ‘nicwatch’ you will see a dramatically different result when you count the total number of packets that are exchanged with our earlier ‘tcpserver’ application

15. Applications • Connection-oriented applications such as ‘telnet’ need a quick response to any key a user presses (i.e., TCP_NODELAY) • But an application that transfers bulk data such as ‘ftp’ is more efficient if lots of the data is transmitted within each individual packet (i.e., the TCP_CORK option) • Nagle is compromise between these two

16. In-class exercises • Apply the same 3-window setup that we used for observing the Nagle Algorithm • How many packets are needed when you execute our ‘nodelay.cpp’ application? • How many packets are needed when you execute our ‘corkdemo.cpp’ application? • Do you think it make sense to regard the Nagle Algorithm as a “compromise”?