Sky x technology Essay Example

control, and host system interfacing can be executed in parallel in the EXT protocol. This lightweight protocol has a simple yet flexible algorithm. Packet headers in EXT have fixed sizes and contain enough information to screen and guide packets through the network. The core of the protocol consists of four fixed-sized fields in the header: KEY, ROUTE, SEE, and the command word.

To simplify packet processing, EXT keeps additional mode bits and flags to a minimum. EXT utilizes two frame formats: one for control packets and one for information packets (refer to Figure 1). Both formats share a common header segment and a common trailer segment with constant lengths. Each EXT packet includes a variable length segment between the header and trailer, with the packet type determined by its segment type.

Figure 1: General Frame Formats
INFORMATION PACKET
Common Header Information Segment Common Trailer
CONTROL PACKET
Control Segment (24 Bytes) (Variable Length) (16 Bytes)

The important fields in the data stream are aligned on 8 byte boundaries to allow quick access by machines with 2 byte, 4 byte, or 8 byte alignment. The formats of these fields are explained in more detail later on. The common header contains information about the packet type and identifies which parts of the data stream are included in the information segment. The packet header's control flags field indicates any optional modes, such as disabling error checking or enabling multicast transmission. The common trailer includes two checksum fields, indicates how much data has been delivered to the receiving client application, and also contains a flags field.

These flags in the trailer are typically used to control state changes, such as closing the data transmission connection or

requesting data acknowledgement. The trailer also specifies message boundaries by setting the end of message flag (EOM). The user data being transferred is stored in the information segment and can also be used for passing addresses and other miscellaneous data when necessary. Each data packet contains a contiguous subset of the data stream being transferred. In EXT, there is no maximum limit imposed by the protocol for the number of bytes in each data packet – instead, it is determined by the underlying talking layer.

The maximum transmission unit (MTU) is a limit for each implementation, and it is determined by subtracting the header and trailer sizes from the maximum data field size. EXT supports two modes of data transfer: tagged data of constant length (8 bytes) can be included in the data packet along with the user's data. These additional data bytes appear in the information segment, either at the beginning or end of the user data, indicated by flags in the header and trailer.

Beginning tagged data are indicated by the TAG flag in the common trailer. The control segment contains the receiver's error, flow, and rate control parameters' values. It also contains fields used to resynchronize the transmitter and achieve multi-packet handshaking when necessary. In EXT, multi-packet exchange sequences provide both a transport-level virtual circuit capability and a transport-level datagram service. In EXT, a connection may involve an exchange of three packets, as illustrated in Figure 2. The packets perform functions such as requesting context establishment, transmission of user data, and acknowledgment of context termination. The figure also shows the acknowledgement of context termination request and informing the destination of sender's context termination.The provided

text describes the Three Packet Connection-Mode Handshake, where the EXT system establishes a reliable connection between two user processes. Initially, the source sends packet (A), which is received by the destination. After examining the header, the destination determines that the source wants to establish a send connection. If the destination agrees, a context is established, and the packet's data are queued for transfer to the destination user process. The destination sends control packet (B) to acknowledge the data receipt and indicate readiness to close the connection.

Upon receiving packet (B), the sender responds by sending control packet (C) and closing its side of the connection. This completes the three-way handshake. Any associated buffers are freed, and the sender stops responding to control packets related to that context. When the destination receives packet (C), the connection is closed.

In EXT, it is the sender's responsibility to detect lost acknowledgements. The sender uses the status request bit (SERE) in the EXT moon trailer to request acknowledgement. It also uses a timer (WITTIER) to determine if the receiver has failed to respond to its request for status and data acknowledgement.If the timer expires before receiving an acknowledgement, the sender assumes the acknowledgment was lost and sends another request for a control packet acknowledging the received data. However, during closing, the sender acknowledges the termination of the context to ensure that the receiver knows the context is closed. If this final packet becomes corrupted or lost, the receiver will eventually timeout and close the connection. Unlike TCP, where each data packet would be retransmitted after a timeout, in EXT only a CENT packet containing the SERE would be sent. The corresponding

returned CENT packet would indicate which data packets, if any, need to be retransmitted. EXT avoids retransmitting data that has already been received correctly by using selective retransmission. Closing an EXT connection is coordinated using three flags: RECLUSE, WHOSE, and END. To inform the remote host that it has completed all reading or writing on the shared connection, the local host sets the RECLUSE or WHOSE flags in an outgoing packet. It is important to note that in a full duplex connection between two nodes A and B, data would be transmitted in both directions (A?bi and B*A). Using RECLUSE and WHOSE, each direction can be shut down independently. The END flag is set in an outgoing packet to indicate that the local host has released or closed its end of the connection.In the final packet transmitted, the END bit is set to indicate that the context has been terminated, meaning that no further packets can be exchanged. If a packet is received with the END bit set, the context is assumed to be closed at the remote end and the local host releases the context.

The "close" protocol, which includes END, RECLUSE, and WHOSE, can support graceful termination, abbreviated termination, transactions, and abort situations without any modification. There are also two-packet exchange sequences called fast handshakes in EXT that allow for transaction-like exchanges. However, these modes are less reliable than the three packet connection in full duplex connections. The two packet fast close can be used as a transport level datagram service or for simple request/response operations.

In EXT, when a data acknowledgment is requested (such as in the FIRST packet of fast close cases), the

receiver delays acknowledgment until all the received data prior to SERE has been processed. This also includes the data in the packet with SERE. EXT also includes a second status request flag called DEER in the common header flags field. DEER differs from SERE because SERE requests an immediate response from the receiver, whereas DEER requests it after all currently queued data has been received.The text discusses the benefits of delayed acknowledgements in the context of flow control in SERE (Selective Acknowledgment and Resource Equalization). By delaying acknowledgements until the receiver has freed up buffer space and can accept more data, flow control blocking is minimized. This prevents the receiver from generating its final acknowledgement before all data from the last information packet has been delivered, ensuring that unacknowledged data is not left hanging. SERE responses are therefore delayed until all data has been processed. Flow control allows the receiver to communicate the state of its receiving buffers to the sender. The receiver's flow control parameters, including the size of the data buffer and the number of bytes received but waiting to be transferred, are included in control packets sent from the receiver to the sender. These parameters are detailed in Table 1.EXT Flow Control Parameters LOCAL constrains the sender from exceeding the receiver's buffer capacity by avoiding sending bytes with a sequence number greater than LOCAL.
DEEDS represents the sequence number of the next byte to be delivered to the destination application or client, which can be considered as the highest sequence number that the client has received successfully. Hence, all bytes with a sequence number smaller than DEEDS have been successfully transferred.
DEEDS is always

less than or equal to LOCAL, indicating that the buffer size allocated to the context by the receiving EXT process can be calculated by subtracting DEEDS from LOCAL and taking modulo 232. This allocation scheme follows a byte-oriented approach similar to TCP rather than a packet-oriented approach like TAP.
A significant advantage of this policy is that byte-oriented allocation is unaffected by internet congestion.
The sender holds transmitted data in a buffer until it receives confirmation of successful delivery. In case retransmission is needed, the buffered data can be resent.
When the sender observes an extension of DEEDS, it can release the buffers associated with the delivered data.
RISE denotes the sequence number of the first byte not yet received contiguously from the network.The first byte in the first gap or the first byte in the next expected data packet can be considered as RISE. Like LOCAL and DEEDS, RISE also has an alternative interpretation. All bytes with sequence numbers lower than RISE have been buffered by the receiving EXT process at the destination but may not have been delivered to the destination client process yet. Therefore, RISE is one greater than the largest consecutively received data byte sequence number. The sequence numbers of all bytes associated with gaps are between RISE and LOCAL. These parameters allow EXT to implement flow control, allowing the receiver to restrict the sender from sending excessive data prematurely. It is important to note that all sequence number parameters in EXT occupy 4 bytes (?SEE, RISE, DEEDS, LOCAL) associated with gaps in the received data stream. TCP has 32-bit sequence numbers and a 16-bit window, while EXT provides a 32-bit sequence number. RISE, DEEDS,

and LOCAL are used to differentiate delayed retransmissions from new data with the same sequence number. Once the sender is informed of the receiver's allocation limit through the LOCAL parameter, it continues transmitting until the allocation limit is reached without requiring individual acknowledgments for each transmitted packet. Therefore, EXT efficiently utilizes the higher reliability of modern networks such as fiber optic LANs.Once the allocation is complete, the EXT sender process sets the SERE parameter in the last transmitted data packet. The receiver then responds as previously described, sending a control packet that acknowledges all received data, identifies any gaps detected, and advances the allocation if necessary. Another allocation policy called reservation mode exists in EXT. In this mode, the transmission is determined by the size of the buffers specifically reserved for the receiving client's context (indicated by setting LOCAL to the size of this reserved buffer). In reservation mode, the sender must pause between message transmissions until the receiving client has provided a new buffer for receiving the next message. This ensures that adjacent messages are separated into different client buffers since each message may not completely fill its buffer. The reservation buffer size in reservation mode can differ significantly from the normal allocation size and may be greater. This mode is similar to the allocation control mechanisms found in the VAMP [7] and NETBALL[8] protocols. In certain situations, flow control alone may not be enough to guarantee efficient and error-free transmission between sender and receiver, even on a highly reliable network. Imagine a network that includes both hardware and software implementations of the EXT protocol.

The use of the VILE chip set allows for

parallel execution of much of the protocol. However, in cases where a sending EXT process implemented in hardware sends multiple packets without sufficient spacing, it may overwhelm a receiving EXT process implemented in software. To prevent this, EXT uses rate control to limit the size and timing of data bursts from the sender. In a given time period, the number of bytes transmitted by the sender should not exceed the receiver's (or intermediate routers') capacity to decipher and queue the data, otherwise they will start dropping packets. Van Jacobsen has proposed various extensions to the TCP protocol, including the utilization of a 64-bit sequence number and a 29-bit window size. It should be noted that the SERE bit setting policy in EXT can be determined by the user application. Gaps in the received data stream can occur due to packet arrival patterns, which is a separate issue from flow control or buffer size problems discussed earlier. The receiver may have enough buffer space available, but consecutive packets can arrive faster than the control mechanisms can handle, as shown in Table 2. By adjusting the rate control parameters (RATE and BURST), the receiver can optimize the data transmission rate to a suitable level.

The transmitter is restricted from transmitting more than BURST bytes within ARTIER timeouts. The maximum number of packet bursts per second is determined by the RATE/BURST ratio. The duration of each packet burst is determined by the BURST/RATE ratio. The rate timer, ARTIER, is set to this specified value. If RATE control is disabled, the sender's transmissions are not constrained.

When a slow EXT receiver, implemented in software, is listening to a hardware-implemented sender,

packet bursts need to be spaced out to ensure that the slow receiver has enough time between consecutive bursts to complete protocol processing before the next burst arrives. To achieve this, the BURST parameter should be set equal to the EMIT (maximum transmission unit) of the underlying network. Therefore, each packet burst cannot contain more than one packet's worth of data.

If the receiver can handle N packets per second, the RATE parameter should be set equal to EMIT * N. This restricts the sender from sending back-to-back packets without appropriate spacing. Figure 3 illustrates byte transmission versus time for a hypothetical EXT implementation over a one-second period. The appropriate values for these parameters can be determined experimentally and then included in all outgoing control packets from the receiver. It should be noted that in this example, RATE is much greater than BURST.Figure 3 demonstrates that by adjusting the BURST and RATE parameters, an inter-burst separation can occur. Each burst is represented by a ramped triangle, and the separations between bursts are indicated by horizontal dotted line segments where no progress is made. During each pause in transmission, the slower receiver has the opportunity to catch up. However, the sender process can only determine the appropriate values for RATE, BURST, and LOCAL after the first burst of data is complete and the first control packet arrives. Until then, default values must be used for the flow and rate control parameters. The choice of default values can impact the number of dropped packets during the initial data burst, especially if there are significant variations in protocol processing speeds across the network. To mitigate this, a conservative approach

would be to set the default LOCAL to a small number of bytes (such as one average sized data packet) and to adjust the default rate parameters to ensure sufficient packet spacing for the slowest receiver on the network.

After the initial burst, the sender will wait for the control packet generated by the SERE in the last data packet of the burst. This control packet will provide more accurate flow and rate control parameters for the receiver. Although this may result in slightly more overhead in the initial burst, it will prevent the loss of many packets.