Computers and Technology

When introducing data communications concepts and protocols to students I think it is beneficial to demonstrate, and more importantly, allow students to play with real protocols. In the lab I teach (ITS332), as well as assignments for some lecture courses, we use Wireshark to capture traffic generated by several Internet applications (e.g. ping, Secure Shell, web browsing, iperf). This allows students to see the actual packets being sent across a network, and start to understand the protocol rules and formats used.

Unfortunately sometimes what we see in Wireshark is not what we expect. One case in which this occurs is when TCP/IP operations are offloaded by the operating system to the Network Interface Card (NIC). Common operations for offloading are segmentation and checksum calculations. That is, instead of the OS using the CPU to segment TCP packets, it allows the NIC to use its own processor to perform the segmentation. This saves on the CPU and importantly cuts down on the bus communications to/from the NIC. However offloading doesn't change what is sent over the network. In other words, offloading to the NIC can produce performance gains inside your computer, but not across the network.

How does this affect what Wireshark captures? Consider the figure below illustrating the normal flow of data through a TCP/IP stack without offloading. Lets assume the application data is 7,300 Bytes. TCP breaks this into five segments. Why five? The Maximum Transmission Unit (MTU) of Ethernet is 1500 Bytes. If we subtract the 20 Byte IP header and 20 Byte TCP header there is 1460 Bytes remaining for data in a TCP segment (this is the TCP Maximum Segment Size (MSS)). 7,300 Bytes can be conveniently segmented into five maximum sized TCP segments.

After IP adds a header to the TCP segments the resulting IP datagrams are sent one-by-one to the "Ethernet layer". Note that TCP/IP are part of operating system, while most functionality of Ethernet is implemented on the NIC. However network drivers (lets consider them part of the OS) also perform some of the Ethernet functionality. The network driver creates/receives Ethernet frames. So in the above example, assuming segmentation offloading is not used, the 7,300 Bytes of application data is segmented into 5 TCP/IP packets containing 1460 Bytes of data each. The network driver encapsulates each IP datagram in an Ethernet frame and sends the frames to the NIC. It is these Ethernet frames that Wireshark (and other packet capture software, like tcpdump) captures. The NIC then sends the frames, one-by-one, over the network.

Now consider when segmentation offloading is used (as in the figure below). The OS does not segment the application data, but instead creates one large TCP/IP packet and sends that to the driver. The TCP and IP headers are in fact template headers. The driver creates a single Ethernet frame (which is captured by Wireshark) and sends it to the NIC. Now the NIC performs the segmentation. It uses the template headers to create 5 Ethernet frames with real TCP/IP/Ethernet headers. The 5 frames are then sent over the network

The result: although the same 5 Ethernet frames are sent over the network, Wireshark captures different data depending on the use of segmentation offloading. When not used, the 5 Ethernet frames are captured. When offloading is used, Wireshark only captures the single, large frame (containing 7,300 bytes of data).

To further illustrate segmentation offloading, and how to control it in Linux, consider the following tests performed on two Ubuntu computers, basil and ginger, connected on an Ethernet LAN. On basil (which has IP address 10.10.1.22) netcat in server mode is used to receive data:

sgordon@basil$ nc -l 5001

On ginger netcat in client mode is used to send 10,000 Bytes of data (stored in a file) to the server.

sgordon@ginger$ nc -p 5002 10.10.1.22 5001 < 10000bytes.txt 

tcpdump is used to see the captured IP packets, and in particular the size of the TCP segments. I could have used Wireshark, but the text output of tcpdump> is easier to include in this page. ethtool is used to view and change the status of segmentation offloading (in this example, generic segmentation offload or GSO).

First note that ethtool shows us that generic segmentation offload is on.

sgordon@ginger$ sudo ethtool -k eth0
Offload parameters for eth0:
Cannot get device flags: Operation not supported
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: off
udp fragmentation offload: off
generic segmentation offload: on
large receive offload: off

Now, after running the netcat client, lets see the output from tcpdump (for clarity I have omitted the option fields from selected TCP segments):

sgordon@ginger$ sudo tcpdump -i eth0 -n 'not port 22'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
18:30:24.899687 IP 192.168.1.2.5002 > 10.10.1.22.5001: S 679249855:679249855(0) win 5840 
18:30:24.900583 IP 10.10.1.22.5001 > 192.168.1.2.5002: S 1420594303:1420594303(0) ack 679249856 win 5792 
18:30:24.900612 IP 192.168.1.2.5002 > 10.10.1.22.5001: . ack 1 win 92
18:30:24.900713 IP 192.168.1.2.5002 > 10.10.1.22.5001: . 1:2897(2896) ack 1 win 92
18:30:24.900735 IP 192.168.1.2.5002 > 10.10.1.22.5001: . 2897:4345(1448) ack 1 win 92 
18:30:24.902575 IP 10.10.1.22.5001 > 192.168.1.2.5002: . ack 1449 win 68 
18:30:24.902591 IP 192.168.1.2.5002 > 10.10.1.22.5001: P 4345:7241(2896) ack 1 win 92 
18:30:24.903597 IP 10.10.1.22.5001 > 192.168.1.2.5002: . ack 2897 win 91 
18:30:24.903607 IP 192.168.1.2.5002 > 10.10.1.22.5001: . 7241:8689(1448) ack 1 win 92 
18:30:24.903613 IP 192.168.1.2.5002 > 10.10.1.22.5001: P 8689:10001(1312) ack 1 win 92 
18:30:24.903617 IP 10.10.1.22.5001 > 192.168.1.2.5002: . ack 4345 win 114 
18:30:24.905573 IP 10.10.1.22.5001 > 192.168.1.2.5002: . ack 5793 win 136 
18:30:24.905587 IP 10.10.1.22.5001 > 192.168.1.2.5002: . ack 7241 win 159 
18:30:24.906628 IP 10.10.1.22.5001 > 192.168.1.2.5002: . ack 8689 win 181 
18:30:24.906637 IP 10.10.1.22.5001 > 192.168.1.2.5002: . ack 10001 win 204 

Each line is showing a captured packet. The TCP segments containing data can be identified by the sequence numbers (I've made them bold). The number in parentheses indicates the number of bytes in this TCP segment. We can see from the capture that our 10,000 Bytes of data is broken into 5 segments containing: 2896, 1448, 2896, 1448, 1312 Bytes each. But wait ... 2896 Bytes in a TCP segment when the MSS is 1460? (in fact, with TCP header options, like SACK and timestamp, the MSS in this capture is 1448). This is Generic Segmentation Offloading going to work: the OS is sending large segments, as captured above, and letting the NIC do the real segmentation.

So now lets turn Generic Segmentation Offloading off using ethtool:

sgordon@ginger$ sudo ethtool -K eth0 gso off

And run the netcat transfer again and look at the tcpdump output this time:

sgordon@ginger$ sudo tcpdump -i eth0 -n 'not port 22'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
18:33:02.644356 IP 192.168.1.2.5002 > 10.10.1.22.5001: S 3144010294:3144010294(0) win 5840 
18:33:02.645427 IP 10.10.1.22.5001 > 192.168.1.2.5002: S 3901655238:3901655238(0) ack 3144010295 win 5792 
18:33:02.645471 IP 192.168.1.2.5002 > 10.10.1.22.5001: . ack 1 win 92 
18:33:02.645542 IP 192.168.1.2.5002 > 10.10.1.22.5001: . 1:1449(1448) ack 1 win 92 
18:33:02.645558 IP 192.168.1.2.5002 > 10.10.1.22.5001: . 1449:2897(1448) ack 1 win 92 
18:33:02.645567 IP 192.168.1.2.5002 > 10.10.1.22.5001: P 2897:4345(1448) ack 1 win 92 
18:33:02.647415 IP 10.10.1.22.5001 > 192.168.1.2.5002: . ack 1449 win 68 
18:33:02.647433 IP 192.168.1.2.5002 > 10.10.1.22.5001: . 4345:5793(1448) ack 1 win 92 
18:33:02.647439 IP 192.168.1.2.5002 > 10.10.1.22.5001: . 5793:7241(1448) ack 1 win 92 
18:33:02.648437 IP 10.10.1.22.5001 > 192.168.1.2.5002: . ack 2897 win 91 
18:33:02.648446 IP 192.168.1.2.5002 > 10.10.1.22.5001: . 7241:8689(1448) ack 1 win 92 
18:33:02.648451 IP 192.168.1.2.5002 > 10.10.1.22.5001: P 8689:10001(1312) ack 1 win 92 
18:33:02.648460 IP 10.10.1.22.5001 > 192.168.1.2.5002: . ack 4345 win 114 
18:33:02.650414 IP 10.10.1.22.5001 > 192.168.1.2.5002: . ack 5793 win 136 
18:33:02.650428 IP 10.10.1.22.5001 > 192.168.1.2.5002: . ack 7241 win 159 
18:33:02.651469 IP 10.10.1.22.5001 > 192.168.1.2.5002: . ack 8689 win 181 
18:33:02.651476 IP 10.10.1.22.5001 > 192.168.1.2.5002: . ack 10001 win 204

Now this is what we expect to see - 7 TCP segments each no larger than 1448 Bytes.

Whats the conclusion of all this? What is taught in lectures and textbooks is not always what you see in practice. I suggest turning offloading optimisations off to demonstrate the basic concepts, and then turn them back on again to illustrate the practical performance optimizations applied at the expense of theoretical layering principles.

Its always nice to see and deal with other people using Unix-based operating systems. If a student comes to me for help with a software problem, although I'll try to help no matter what OS, I am much more interested in spending time with them if they are using a Unix-based OS (Ubuntu, MacOS, etc). This is mainly because that is what I know best. Of recent, more students have Ubuntu installed, either as dual-boot or in a virtual machine, on their personal laptops. And they are starting to learn that the Windows GUI way is not the only way. I am encouraging the further exploration of Linux in my networking lab (ITS332) where 90% of the tasks are completed on the command line in Ubuntu (the other 10% using Wireshark in Ubuntu). In other courses, although I don't require the students to use any specific operating system, I demonstrate how easy it is to complete networking tasks in Unix-based OSes, such as measure the throughput of TCP in a network with varying packet loss rates (three command line operations using iperf and tc).

One of the local Unix gurus at SIIT is Yoichi. As well as doing his research, he has been active in labs and teaching introductory computing to SIIT/Thammasat students. He has started to blog about some of the simple, yet very powerful things that can be done via the command line in Ubuntu. Yoichi and other teaching assistants and graduate students are spreading the word in SIIT that Windows is not the only operating system available. And their efforts are starting to show as more students are coming to me for help on a network or programming assignment with their laptop booted into Ubuntu.

Wan was in search of a netbook for use at home and work, so after a couple of days online and wandering around Zeer Rangsit IT Plaza, she finally settled on the Samsung NC 10. It looks good, has a nice sized keyboard, received good reviews online, and was priced well against other netbooks (Asus, Acer, Lenovo, Dell, etc.).

The specs are about the same as equivalent class netbooks from other companies:

• Atom N270 processor
• 1GB RAM, easily upgradeable to 2GB if needed
• 10.1inch screen
• 160GB hard drive
• IEEE 802.11b/g, Bluetooth, 100Mb/s Ethernet

The final price was 12400 Baht, which included an external DVDRW drive (which has yet to arrive).

As Wan has been using Ubuntu on my home PC for a while, the first thing I did with the netbook was install Ubuntu Desktop 9.04. I overwrote the existing Windows XP Home install, which I didn't think there would be any use for (However, I latter regretted this - I should've left it dual-boot. It turns out to update the laptop BIOS, Samsung software must run under Windows. Oh well, if an update is really needed it won't be too hard to backup Ubuntu and install Windows from the recovery CD).

I've had a few hours of setting it up and using it, and so far it seems like a good buy. The main thing I need to learn about is the Ubuntu power management features, where some fine-tuning is needed to conserve battery but also give reasonable (and constant) brightness settings.

Some sites with info on the Samsung NC10 and Ubuntu include:

• Samsung NC10 at Wikipedia
• SammyNetbook
• Ubuntu NC10 Community page
• Ubuntu on the Samsung NC10

On Wednesday I was at Sukhothai Hotel in Bangkok to be interviewed for the daily English talk show Morning Talk. I spoke about the IT and Computer Science activities at SIIT, including some of the interesting topics we teach (mobile Java applications, BitTorrent), the National Software Contest (NSC), and the scholarship opportunities. In the NSC this year two of our groups one prizes - one for a Thai Wikipedia question answer system, and the other for a mobile application that speaks messages sent to the phone (good for driving or for people that have trouble reading).

Before the interview I had a 10 minute chat with the host, Kipsan Beck, before we got into the recorded discussion. I was pretty nervous so don't remember much of what I said - but the hotel looked nice! You can watch the full interview online now or try to download from the Maxnet site (Episode from Monday 23 March 2009).

On Wednesday I attended the NTC Scholarship ceremony in Phayathai, where Jirawat Thaenthong received funding for the remainder of his studies. I am Jirawat's advisor for his PhD studies on mobile networking. The National Telecommunications Commission (NTC) is the telecommunications regulator in Thailand, and in the past year set up the Telecommunications Research and Industrial Developmenent Institute (TRIDI) to fund research in the field. One of the first areas of funding was scholarships. Jirawat was one of the 22 recipients (7 PhD, 15 Masters) from across Thailand. Well done, Jirawat!

Wow, that was close! I decided to delete an old fat32 partition that I used to share data between linux (first Fedora, now Ubuntu) and Windows on my dual boot PC. Since Ubuntu supports NTFS partitions, I hardly ever used it. I used Partition Manager Professional in Windows to delete the partition. No worries.

However, I also decided to resize my /boot partition under Ubuntu. When I recently upgraded to Ubuntu 8.04, the process was stalled several times because I didn't have enough space on the /boot partition (initially 100Mb). This was very annoying because I had to move some files from /boot and restart the entire Ubuntu upgrade (several minutes wasted each time). So I used Partition Manager to also increase the /boot partition to 200MB. No worries.

After buying a new Video Card for my PC, I still had some serious problems. When starting my computer, fans, the CPU, hard drive and other devices seemed to start, but nothing was displayed on the monitor. This was similar to what triggered me to buy a new video card - maybe I wasted 3000 Baht!

Over the past couple of weeks I had a very crude fix to this problem: when booting, it seemed if I continually pressed Escape (maybe also other keys), the computer would start, that is POST would complete and the operating system start. However this didn't always work. It seemed every day I had to try 5 or 6 times to get the computer to boot. Not good!

Today I tried a bit harder to fix the problem. After checking all the cables and connections, and checking a bit on the web, I think I narrowed it down to two possible problems:

1. The internal battery and/or CMOS RAM were faulty (I had noticed about 1 week ago that the system time was incorrect one day). I followed the ASUS motherboard instructions of resetting the RAM. Unplug the power from the PC; remove the battery; change the jumper from default to RESET for 10 seconds; change back to default; put the battery back in; and start the computer.
2. One of the RAM DIMM slots was faulty. At the same time as doing the internal battery check, I also removed a new stick of 1GB RAM that I bought at the same time as the video card.

Restarted after these two changes and the computer booted immediately, without any input from the keyboard. This looked good. I put the second 1GB stick of RAM back in and the old problems occurred (this points to the RAM/DIMM being the problem, not the battery/CMOS - but my gut feeling says it was wise to reset the CMOS as well). So then after trying the second (new) 1GB of RAM by itself in the first slot (this worked), and concluded the second slot may be faulty. Now I have both 1GB sticks in the two second (black) DIMM slots, rather than the two first (yellow) DIMM slots. Everything seems to be working ok, but lets wait and see after a few days...

Lets hope this is the last of my computer problems for a few months.

Before coming to Thailand, some people told me that things (clothes, electronics, minds) would not survive the conditions well here, compared to Australia. Well, that is starting to show, especially for electronics. Since arriving, some of the things that have failed:

Video Camera. Within the first month of being here, my Canon MV730i digital video camera stopped working. Since I haven't had much use for it (instead preferring the still camera), it has sat in the bottom of my cupboard gathering dust. I have a strong belief that, in the same way in stopped working for no apparent reason, it will magically fix itself one day if I leave it alone.

Digital Camera. In August 2007 towards the end of Mum and Dads visit, my Canon IXUS 50 digital still camera shat itself. More specifically, the automatic lens would not extend/retract correctly. Well, this was very upsetting, being about 2 years old and in general quite a useful camera (although the quality of pictures, especially without good lighting, is not so good). So I went to the Canon support centre at Zeer Rangsit and

Linux distribution which is relatively easy to install and use. I have tried Ubuntu and it does provide a user friendly Linux distro, detecting hardware automatically so that things like sound and networking work straight away.

Background

Zeer Rangsit is an IT mall in Pathumthani, about 10 minutes north of the old Don Muang Airport (and 30 minutes south of Thammasat University).

Association of Computing Machinery. US-based professional organisation for computing researchers and professionals.

Institute of Electrical and Electronic Engineers