-
Notifications
You must be signed in to change notification settings - Fork 1
Eon overview
EON (Eye Of Needle) is a transport layer that sits on top of UDP. This layer offers both datagram-based and stream-based functionality, using two different protocols. The datagram-based protocol is referred to as ‘DEON’ and the stream-based protocol as ‘SEON’. These layers are very similar to UDP and TCP respectively, and use similar data formats and terminology. However, some aspects of TCP have not been implemented (for example, security levels, precedence, receiver windows and the Urgent and Push flags). Readers should compare the specification below with RFC 4614 for details.
EON connections define their own set of ports, numbered from 1 to 65535, so that two hosts may have multiple EON connections over a single UDP connection. Unlike TCP/UDP, which maintains two distinct sets of ports, there is only one set of ports for EON; it is not permitted for SEON and DEON connections to use the same port number. These port numbers are only valid within the context of EON; they are not related in any way to TCP or UDP ports.
All EON packets are sent via UDP. In the details below, the correct fields in the UDP header are assumed to be set.
EON was created to permit communication between two hosts behind different Network Address Translation devices, as long as they support full-cone, restricted-cone or port-restricted-cone NAT. For a description of NAT types see: http://en.wikipedia.org/wiki/Network_address_translation#Different_types_of_NAT
Connections to NATted hosts require that the external UDP port on the NAT device be known, either by STUN or through some other means. Further, connections to devices behind restricted-cone or port-restricted-cone devices required the use of a 'NAT seed'. This is a dummy DEON packet sent by one or both hosts to the other on EON port 0 (which is reserved and cannot otherwise be used). This dummy packet forces the NAT devices to create the necessary mappings to allow bidirectional data flow. Due to the unreliable nature of UDP, we recommend sending three NAT seeds to ensure one gets through.
All EON packets have a data header; although SEON and DEON packets have different data headers, the first 44 bits follow the same format. A ‘protocol’ field is used, which is set to 1 for DEON and 2 for SEON packets, allowing them to be told apart.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Data... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Source Port (16 bits)
- This represents the EON port of the sending process. It has no relevance to TCP or UDP ports.
- Destination Port (16 bits)
- This represents the EON port of the destination process. It has no relevance to TCP or UDP ports.
- Protocol (8 bits)
- This field enables the EON implementation to differentiate SEON from DEON packets. For DEON packets, this field must be set to 1 (00000001b). For SEON packets, this field must be set to 2 (00000010b). Higher values are reserved for future protocols.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This header is followed by the data in the packet, shown as ‘data’ in the above diagram.
- Source Port (16 bits)
- This represents the EON port of the sending process. It has no relevance to TCP or UDP ports.
- Destination Port (16 bits)
- This represents the EON port of the destination process. It has no relevance to TCP or UDP ports.
- Protocol (8 bits)
- This field enables the EON implementation to differentiate SEON from DEON packets. For DEON packets, this field must be set to 1 (00000001b).
This header is followed by the data in the packet, shown as ‘data’ in the above diagram.
- Source Port (16 bits)
- This represents the EON port of the sending process. It has no relevance to TCP or UDP ports.
- Destination Port (16 bits)
- This represents the EON port of the destination process. It has no relevance to TCP or UDP ports.
- Protocol (8 bits)
- This field enables the EON implementation to differentiate SEON from DEON packets. For SEON packets, this field must be set to 2 (00000010b).
- Ack, Rst, Syn, Fin flags (1 bit each)
- Selective Acknowledgement Blocks (Sack) (2 bits)
- The number of Sack blocks that immediately follow the header (between 0 and 3). For every sack block, two 32bit unsigned integers follow the header, (denoted regionX begin and regionXend in the above diagram)
- Reserved (Rsvd) (2 bits)
- Reserved for future use. Must be zero.
- Sequence Number (32 bits)
- The sequence number of the first data octet in this packet. If SYN is set, the value of this field is the initial sequence number (ISN) and the first data octet is ISN+1.
- Acknowledgement Number (32 bits)
- If ACK is set, this field contains the value of the next sequence number the sender of this packet is expecting to receive. Once a connection is established this is always sent.
RFC 793 specifies that a TCP should remember the sequence numbers it has used in previous connections, so that old packets from previous connections do not interfere with new ones. This complicates implementation considerably; in this initial version of the protocol, all SEON connections will use a randomly-generated 32 bit value as the initial sequence number. To provide for crude protection against interference from old packets, when an SEON connection has terminated, a process may not initialise another SEON connection to the same EON port for ten seconds.
For connection establishment, data exchange and congestion control, SEON uses the TCP New Reno + SACK protocol, as defined in RFCs 4614, 2581 and 2018. Note that SEON implements SACK within the protocol, rather than as an option. Also, SEON uses a fine-grained timer for all operations.
The core feature of SEON over TCP (other than NAT penetration) is that it allows connections to be prioritized. This provides the capability for some connections to use bandwidth in preference to others, while retaining TCP's capability to use as much of the available total bandwidth as possible. This prioritization is done for data sending only; extending it to receiving data is an area for future research.
SEON uses a modification of the TCP-LP protocol. The sender assigns all connections a variable gamma (ɣ), 0 < ɣ <= 1. Which connections are assigned which ɣ values are dependent on the implementing application; robonobo assigns ɣ based on the relative bids in the bandwidth auction.
The sender keeps track of maximum and minimum RTT values for all connections. When the SRTT for a connection goes above minRtt + ɣ(maxRtt - minRtt), that connection has its send window cut as if for packet loss, and then watched to see if remains congested - see TCP-LP for complete details.