A Delay Tolerant Network Architecture for Challenged Internets May 18, 2009

(i) The three most important things the paper says:

1) With challenged networks, you cannot assume that an end to end routing path exists.  Rather, routes can be better thought of as a “cascade of time-dependent contacts”.  They also parameterize contacts in terms of time available, capacity, latency, direction and most importantly a concept of “predictability” is built in.  This was an important observation as it allows DTP to take into account a challenged network’s end system characteristics like low duty cycle operations.   These were factors that existing solutions for challenged networks didn’t consider (e.g. PEP).

2) DTP chooses to use a “hop by hop” custody transfer of messages instead of “end to end”.  In a custody transfer mechanism, once a message arrives at the next hop (usually a DTP device), the sender’s job is considered complete.  This allows messages to be delivered reliability even in situations when only segments of a particular path may be on at a time.  Consider a case in which a sensor network needs to transfer information, however they all come powered on at different intervals.  This is yet another consideration that existing solutions didn’t consider.

3) Another factor that they considered in their solution that was not previously conceived was security between hop points in a challenged network.  They choose to implemenet security in the form of public/private key exchange between hops.  By doing it this way, DTP routers only need to store public keys of nodes of distance one away.  Therefore it makes key management much more simple.  Furthermore, it also supports the “hop by hop” custody transfer that they decided on earlier.

(ii) The most glaring problem with the paper:

The biggest problem with the paper is they “hand waved” a lot of the detailed proofs and explanations.  For instance, they mention that re-transmission issues can be solved with a “time out”, however no futher evidence or proof was given.  In addition, they said that taking into account “contacts” in different regions connected by DTP will allow the DTP to make good routing choices.  However no detail was given about how or what algorithms can be used to make that process reliable.  Some of these “hand waved” points are critical to the accuracy of this paper.

(iii) The future research directions of the work:

An interesting follow on work would be how their choice to use “hop by hop”, for reliability, can actually have an opposite effect.  Considering the overhead cost of a transferring messages via custody transfers, the next hop to the DTP can be compromised.  In such situation when it is compromised, would sending it via end to end solution afford more success?  Also does this change when messages sizes are small?  In the case of small messages, the overhead cost with custody transfer may cause delays that may prevent the message from ever being delivered.

TCP Vegas: End to End Congestion Avoidance on a Global Internet May 15, 2009

1. Conditions for retransmission — instead of using actual timer for timeout in every case or automatically retransmitting after n duplicate ACKs, assert interval between when a packet was sent and when a corresponding duplicate ACK was seen is within round-trip time.
2. Congestion control — instead of blindly increasing congestion window size until congestion is detected, decreasing the window size to compensate, then repeating the cycle, TCP Vegas makes an estimate based on non-congested round-trip time and the current congestion window size, and compares to the number of unrelated bytes sent between a packet and its ACK.
3. Slow-start — to set a more accurate threshold window for switching to linear expansion of the congestion window from exponential expansion, the experimental Vegas* is proposed. Vegas* sends four packets and waits for ACKs; as they arrive, it schedules congestion window size increases in the future and adjusts the threshold window based on the corresponding bandwidth estimates.

A protocol for Packet Network Interconnection April 7, 2009

1. Gateways are the only nodes that require knowledge of outside networks.

In the protocol proposed by the paper, nodes called gateways are used to interconnect different networks that implement different protocols. One of the more appealing features of this protocol is the fact that gateways are the only nodes in a network that need to have knowledge of external, connected networks. The other nodes in the network are insulated from having to support any additional protocol. They need not have knowledge of addressing methods, error-checking methods, packet size or other features that define the protocol of a connected network. The gateway performs all address translations and if required embeds the inter-network packet in a header defined the protocol of the local network so that all the nodes in the network need to do is route the packet according to the new home-network header (if added).

2. Packets may need to be fragmented as they cross networks. Efficient accounting and protocol to support this

Packets may need to be split as they pass through gateways of different networks to meet the maximum-packet size requirement of the current network. The paper makes note of this fact and in all methods that it proposes ensure that this is taken into account and accommodated. It provides for ES flag so that if a packet containing a complete segment is split at a gateway, the receiving TCP knows how to reassemble the segment and identify the packet containing the last segment. This also allows for the original checksum for the complete segment to be used. No checksum needs be calculated for each smaller packet formed. The TCP also knows the packet that contains the checksum for the segment. It also proves an efficient (for most purposes) and fair method of accounting and charging for packets carried by a network that takes into account this fact. It says that the price of carrying a packet through a network is proportional to the size of the packet. This way, even if a single packet is split into 5 smaller ones, the transmitting network only has to pay 1/5^th the price of carrying a the complete packet for each of the smaller packets. Hence, fairness is maintained.

3. Window method supports retransmission, duplication detection, flow-control and inter-connected networks

The paper uses windows to achieve both re-transmission/duplication detection and flow-control. Though the window strategy isn’t original to the paper, the paper does a good job of identifying the method that would work efficiently with the underlying structure (inter-connected networks implementing different protocols) and could be used to realize multiple features that a communication network needs to provide (flow control and duplication detection)

Over sights/Short comings:

The paper imposes a common ‘inter-network header’ on all its packets. Though this simplifies the protocol to a great extent, it also implies that all nodes on all inter-connected networks need to have a common addressing scheme with the nodes on one network aware of the addresses of nodes on another network.. This also implies that, if a preexisting network needs to be connected to this inter-connection of networks, all its host nodes might need to modify their TCP layers to form packets with headers in the ‘inter-network header’ format.

In the protocol proposed, packets could get fragmented so that some of the packets have no checksums. It is possible that at the next gateway, these packets might enter a network that supports larger packet size. At the gateway to such a network, these fragmented packets may need to be recombined. When the gateway to such a network, combines fragment packets to form a larger packet, it is possible that 2 or more packets with no checksum in them get combined. This would lead to large packets being formed without a checksum which in turn would reduce the error detection capability of the protocol and the network.

Future Work:

Support for inter-connected networks that do not require their packets to have a common internetwork header. This way, additional networks could be added to the existing interconnected system of networks with minimum effort.

The paper also assumes that the candidate networks provide for certain features such as acknowledgments and a common re-transmission policy. It would help if an additional abstraction layer could be provided that didn’t impose specific policies on the individual networks and allowed them to continue with the policies defined by their protocol.