The Shark and the Moon

The shark is the well known protocol analyzer Wireshark, and the moon is Lua, which is a very clever scripting language developed in Brazil, whose name is the Portuguese word for "moon" (in Italian we call it "luna"... not very different!).

Lua can be used to customize Wireshark from script, and since this is a very useful thing if you implement protocols, I decided to learn something about the Brazilian moon and about how to use it to illuminate preys for the shark. That is, how to use Lua to dissect protocols that are not supported by Wireshark because they are new or proprietary.

As an exercise, and in order to have a reference example for future use, I designed a trivial protocol (which I named... "Example Protocol"), then I wrote the corresponding dissector, and generated a capture file to test it.

Here is the dissector script, here is the capture file, and below is a snapshot of the output from Wireshark (click on it to enlarge):

TCP SWS avoidance

Communication is interaction, so the responsibility for a communication problem is often shared between the communicating parts (although not always equally shared...).

The Silly Window Syndrome makes no exception to this general rule:

"In brief, SWS is caused by the receiver advancing the right window edge whenever it has any new buffer space available to receive data and by the sender using any incremental window, no matter how small, to send more data." (RFC 1122)

Therefore, countermeasures for SWS avoidance are to be taken at both sides, and RFC 1122 recommends the Clark's solution for the receiver, and the Nagle algorithm for the sender. In a few words, they consist in respectively waiting to have enough space before advertising an increase of the receive window, and in waiting to have enough data before sending a segment.

These are the effects on the test I presented in the last post, when repeated with the above solutions enabled (click to enlarge):

The flow graph on the left is the same as the last post, where no countermeasure is taken and SWS occurs. The capture file of this test can be downloaded here.

The flow graph in the middle shows the effects of Clark's solution: the window is updated only when there is enough space for a smart update - in this case half of the receive buffer - and the sender immediately makes use of it (capture file here).

The flow graph on the right shows the effect when also the sender takes action against SWS, by waiting to have enough data to send a full segment, according to Nagle's algorithm (capture file here).

TCP Silly Window Syndrome

While playing with my TCP implementation, I deliberately provoked a "Silly Window Syndrome" (SWS), just to see how it looks like.

To do so, I established a TCP connection between two endpoints A and B, both with the SWS-avoidance countermeaures disabled, and then I made the application at A rapidly issue 5 "send" calls of 1000 bytes each, and the application at B retrieve the received data at the rate of 100 bytes each 200 ms (fast producer vs. slow consumer). The TCP B had a receive buffer of 2400 bytes, and to see things more clearly I disabled the delayed ack and made A send data with the PSH flag unset.

Here is what happened when I ran the test (click on the thumbnails to enlarge, and here for the capture file):

          

The first segments soon filled the receive window, closing it (packets #8 and #9). After that, as soon as the receiver-side application consumed 100 bytes, the window was re-opened with this "silly" low value (#10) and this caused the sender to issue a small segment (#11) that filled the window again. The sequence of re-opening / small segment / closing was then repeated on and on, until all the data was transferred.

And this is the so-called "Silly Window Syndrome".

When it occurs, data is transferred in many small packets instead of few full-sized packets, resulting in an inefficient (possibly disastrous) use of the network.

TCP Packet Mood

In these weeks I am working at the good old Transmission Control Protocol (TCP)  and I find it a very formative activity, despite the age of the protocol.

Among the several enhancements added to it during the last thirty years, this one is particularly interesting: the option to denote Packet Mood (RFC 5841), which was proposed exactly one year ago "in an attempt to anthropomorphize the bit streams on countless physical layer networks throughout the world" (put it shortly, it adds the capability to express feelings on a per-packet basis).


What makes this feature interesting (at least in my opinion) is that the authors of the RFC forecast the creation of "a new technical job class of network psychologists". Since I do like new jobs ;-), I decided to give my humble contribution, and to implement the Packet Mood option in my TCP.

From the first tests it seems to work fine, and fortunately I found out that Wireshark supports it too (thanks, guys!). You can see an example of an emotional TCP connection in the snapshot below (click on the thumbnail to enlarge)...

... and download the pcap capture file by clicking here.

Connection Oriented SCCP

As a continuation of the last post I wrote, in this one I present another couple of capture files showing, this time, brief examples of  SCCP connection oriented services.

The first log shows the complete lifecycle - i.e. establishment / data transfer / release - of a class 2 connection, while the other one shows that of a class 3 connection. The two logs can be viewed with Wireshark configured in the same way as for the connectionless examples.

Protocol class 2 provides a simple connection oriented service with no freals except for segmentation and reassembly, while class 3 adds flow control and detection of losses and mis-sequencing of user messages, although with no error recovery mechanism.

Please note that in the class 3 example I chose a very small window size just to keep it short and simple.

Connectionless SCCP

In these days I'm testing my new implementation of the ITU-T Signalling Connection Control Part (SCCP).

Despite its name, SCCP provides its users with both connection oriented and connectionless services, and thus it plays, in the SS7 suite, the roles played by TCP and UDP in the TCP/IP suite. In addition, it has routing capabilities also.

The connectionless services are provided in terms of two protocol classes, namely class 0 and class 1, which are almost identical except for the sequence control which is provided by class 1 only. This sequence control mechanism relies on the MTP3 Signalling Link Selection (SLS) parameter. At each node, the MTP3 layer ensures that user messages with a given SLS and addressed to the same DPC are, in normal conditions, always routed in the same way. Thus, by delivering a stream of datagrams with the same SLS, these should traverse the SS7 network following the same path, without overtaking one each other.

Here are two capture files showing the same stream of datagrams delivered first using class 0, and then using class 1. One can see that in the first case the SLS changes at each UDT (for load sharing) while in the second it is fixed (for in-sequence delivery).

The capture files can be viewed using Wireshark and following the instructions at the end of this post (DLT=148 set to MTP2).

Coming soon... SCCP connection oriented protocol classes.

An SCTP association

Among other things, last year I've been working at an implementation of the IETF Stream Control Transmission Protocol (SCTP), which is a new internet transport protocol: an alternative to UDP and TCP, suited to carry signalling over IP.

My implementation is (by now) limited to RFC 4960 features, but this is enough to produce some basic example like the one contained in this capture file, in which one can see a complete (although short) life cycle of an SCTP association: establishment / transfer of user data / shutdown.