Saturday, August 15, 2015

Pancake of the Day: A Protocol for Packet Network Intercommunication

    This paper by Vinton G. Cerf and Robert E. Kahn describes the internal structure of a packet switching network and explains the protocol that they used to make individual networks communicate with one another thus giving birth to the internet.

    First, they identified the characteristics of an individual packet switch network - ways of addressing, data size, time delays, restoration from failures procedures, and status information, routing and fault detection and isolation. Keep in mind that these features could be implemented in different ways in other networks. If that's the case, how would these networks be able to communicate with each other? Imagine a Chinese tourist asking a French baker about the price of his eclair while the baker is selling his baguette to a German passer-by who is asking a Finnish girl for directions and all of them are using their native languages!

    To address the issue on the differences in networks, the authors introduced a gateway. What does it do? Gateways receive a packet of data from one network and reformat the packet according to the requirement of the network where the packet would be sent. It's as if a gateway is a translator who knows how to speak in Chinese, French, German, and Finnish.

    Furthermore, the paper also discusses how transmission control program (TCP) handles the sending and receiving of messages of the processes within a network and within an internetwork. The protocol maximized the use of TCP - in network or port addressing,  chopping messages in segments, reassembling and sequencing the segments, retransmitting segments during losses, flow control, and connections and associations. The algorithms for these processes were discussed in detailed by the authors. TCP is like flour to pastries and bread!

   I really enjoyed the paper. I was in awe while reading the algorithms about TCP processes, the creation of gateways, the headers in segments, etc. The details about the information header are complete. The fields answer the need for segmentation, retransmission, etc. I just have a question to the people behind packet network intercommunication project: How did you come up with these solutions? Honestly, I want to see the source codes. I want to know how they implemented the protocol.

   Also, some parts of the paper weren't clear to me. I must have missed out some details and didn't understand the explanation. I have two questions.

   1. In the part about gateways fragmenting packets, what if the source network has a smaller packet size than the destination network? So imagine the diagram given in the paper.

    Network A will send packets to Network C. The packets will traverse through Network B. Assume Network B has a smaller packet size so Gateway M fragments the packet to smaller pieces. Then going to Network C, if Network C has a bigger packet size than Network B, how will Gateway N send the packets? Gateways don't reassemble the packets. Does that mean the packets will be sent to Network C as smaller pieces due to fragmentation done by Gateway M? So the packet size in Network C will not be maximized? Will TCP in Network B fix the issue?

   2. In the part about flow control, the paper says that "the flow control mechanism can reduce the window even while packets are en route from the sender whose windows is presently larger." Why? Acknowledgements in the process header from the receiver to the sender has a "suggested window". If this suggested window was received by the sender and then sends the packets according to the suggestion, why would the receiver reduce the window? Or did I just mixed up the information from the paper and that the idea of  "suggested window" is actually the implementation of reducing the window? Nonetheless,  why would there be a need to reduce the window? When do you reduce the window or enlarge a window?

Pancakes! (with extra toppings)
    What if the internet was built in a different way? What if the researchers prioritized a different feature in the internet? What if instead of having a gateway that chop the packets, we have some sort of a program that will shrink them (like that shortens url)? 


  1. This comment has been removed by the author.

  2. Hi Drio,

    Your review is very engaging.

    With regards to your first question, I think the packet size that will be sent to Network C will be in smaller pieces as a result of the earlier fragmentations done. As i've understood allowing the gateway to reassemble the packets in order to take advantage of the larger packet size can lead to buffering problems and potential deadlocks. Also, what if there is another Network(D) after Network C and Network D has smaller packet size? The Gateway needs to fragment again these packets which may cause more delay in the transmission.

    For your second question, I think allowing the receiver to adjust the window helps the receiver to control the flow of data as it deemed necessary. It can expand the window if there is no delay in the network and packets arrive concurrently and it can reduce the window if the sequence of arrival of related packets are very far from each other.

    I hope these can help :)