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

‘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

‘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

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

Setup steps 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 Step 1: logon ‘hrn23511’ Assign an IP-address to the ‘eth1’ interface and bring it UP (using ‘sudo /sbin/ifconfig’), then lauch ‘nicwatch eth1’ 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)

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

W. Richard Stevens “A book on networking needs a real network to work with along with access to the Internet” “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)

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%

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)

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’

‘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

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

‘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

‘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

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

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”?