Introduction To Nodes
Nodes in experiment represents a network entity which is capable of doing the following:
- Generating Data Flow
- Routing
- Receive and response with control packets
Generating Data Flow
A node in eLab is using an application to generate a data flow. The type of applications the user can add to a node are:
- FTP
- CBR
Each applications is using a different transport protocol , FTP is using TCP as the transport protocol while CBR is using UDP.
Figure 1.1 Protocol under CBR application is disabled because there is only one option (UDP)
When choosing to set the transport protocol for FTP the options are much bigger since TCP have many different versions. The user have to specify in which protocol version he would like use.
Figure 1.2 TCP versions
Table 1.1 summarize the differences between the TCP versions
Table 1.1 TCP Versions
| Name | Description |
|---|---|
| TCP | TCP by default use Tahoe version which is one of the first TCP versions. |
| TCP-FullTcp | Full TCP is different from the other version in the following ways:
|
| TCP-Reno | Improved to Tahoe version on the way TCP handle packet loss. |
| TCP-Newreno | Improves retransmission during the fast recovery phase of TCP Reno. |
| TCP-Sack1 | TCP with selective repeat (follows RFC2018) |
| TCP-Vegas | Vegas version introduce a new way to set TCP timeout. Until the mid 1990s, all TCPs set timeouts and measured round-trip delays were based upon only the last transmitted packet in the transmit buffer and with Vegas in which timeouts were set and round-trip delays were measured for every packet in the transmit buffer |
| TCP-Fack | Reno TCP with "forward acknowledgment'' http://www.psc.edu/networking/papers/fack_abstract.html |
| TCP-Linux | a TCP sender with SACK support that runs TCP congestion control modules from Linux kernel |
Routing
By default all nodes in eLab supports routing. The routing algorithm in eLab is based on the shortest path.
When a packet arrive to a node it will automatically be forwarded to the closest node on the path.
Receive and response with control packets
When the user choose to connect the application to a node, the receiving node will automatically be able to response with control packets and parse data packets. The base TCP receiver node is responsible for returning ACKs back to the sender. It generates one ACK per packet received. The base UDP receiver will parse data packets but will not generate any control packets back to the sender.
| << Introduction To Experiment | Introduction to Link >> |
