Tuesday, July 30, 2013

Objective 1.04 Explain the features and functionality of protocols and technologies specific to the transport layer

A. Compare/Contrast purpose and functionality of MTU and MSS

In computer networking, the maximum transmission unit (MTU) of a communications protocol of a layer is the size (in bytes) of the largest protocol data unit that the layer can pass onwards. MTU parameters usually appear in association with a communications interface (NIC, serial port, etc.). Standards (Ethernet, for example) can fix the size of an MTU; or systems (such as point-to-point serial links) may decide MTU at connect time.
A larger MTU brings greater efficiency because each packet carries more user data while protocol overheads, such as headers or underlying per-packet delays, remain fixed; the resulting higher efficiency means a slight improvement in bulk protocol throughput. A larger MTU also means processing of fewer packets for the same amount of data. In some systems, per-packet-processing can be a critical performance limitation.
However, this gain is not without some downside. Large packets can occupy a slow link for some time, causing greater delays to following packets and increasing lag and minimum latency. For example, a 1500-byte packet, the largest allowed by Ethernet at the network layer (and hence over most of the Internet), ties up a 14.4k modem for about one second.
Large packets are also problematic in the presence of communications errors. Corruption of a single bit in a packet requires that the entire packet be retransmitted. At a given bit error rate, larger packets are more likely to be corrupted. Retransmissions of larger packets takes longer. Despite the negative effects on retransmission duration, large packets can still have a net positive effect on end-to-end TCP performance.
The maximum segment size (MSS) is a parameter of the TCP protocol that specifies the largest amount of data, specified in octets, that a computer or communications device can receive in a single TCP segment, and therefore in a single IP datagram. It does not count the TCP header or the IP header.[1] The IP datagram containing a TCP segment may be self-contained within a single packet, or it may be reconstructed from several fragmented pieces; either way, the MSS limit applies to the total amount of data contained in the final, reconstructed TCP segment.
Therefore: Headers + MSS ≤ MTU
The Maximum segment size to avoid fragmentation = Largest datagram size that any host is required to be able to reassemble - IP header size - TCP header size
So most IPv4 hosts are required to be able to handle an MSS of 536 octets (= 576 - 20 - 20)
and most IPv6 hosts are required to be able to handle an MSS of 1220 octets (= 1280 - 40 - 20).[2]
A lower MSS will ensure that fragmentation will never be done along the path but, in counterpart, the data/header ratio will be lower.
For most computer users, the MSS option is established by the operating system on the SYN packet during the TCP handshake. Each direction of data flow can use a different MSS.


B. Explain the purpose and functionality of TCP

The Transmission Control Protocol (TCP) is one of the core protocols of the Internet protocol suite (IP), and is so common that the entire suite is often calledTCP/IP. TCP provides reliable, ordered, error-checked delivery of a stream of octets between programs running on computers connected to a local area network,intranet or the public Internet. It resides at the transport layer.

TCP segment structure

Transmission Control Protocol accepts data from a data stream, divides it into chunks, and adds a TCP header creating a TCP segment. The TCP segment is then encapsulated into an Internet Protocol (IP) datagram, and exchanged with peers. [3]
The term TCP packet, though sometimes informally used, is not in line with current terminology, where segment refers to the TCP Protocol Data Unit (PDU), datagram[4] to the IP PDU and frame to the data link layer PDU:
Processes transmit data by calling on the TCP and passing buffers of data as arguments. The TCP packages the data from these buffers into segments and calls on the internet module [e.g. IP] to transmit each segment to the destination TCP.[5]
A TCP segment consists of a segment header and a data section. The TCP header contains 10 mandatory fields, and an optional extension field (Options, orange background in table).
The data section follows the header. Its contents are the payload data carried for the application. The length of the data section is not specified in the TCP segment header. It can be calculated by subtracting the combined length of the TCP header and the encapsulating IP header from the total IP datagram length (specified in the IP header).
TCP Header
OffsetsOctet0123
OctetBit 0 1 2 3 4 5 6 7 8 910111213141516171819202122232425262728293031
00Source portDestination port
432Sequence number
864Acknowledgment number (if ACK set)
1296Data offsetReserved
0 0 0		N
S		C
W
R		E
C
E		U
R
G		A
C
K		P
S
H		R
S
T		S
Y
N		F
I
N		Window Size
16128ChecksumUrgent pointer (if URG set)
20
...		160
...		Options (if data offset > 5. Padded at the end with "0" bytes if necessary.)
...
Source port (16 bits)
identifies the sending port
Destination port (16 bits)
identifies the receiving port
Sequence number (32 bits)
has a dual role:
  • If the SYN flag is set (1), then this is the initial sequence number. The sequence number of the actual first data byte and the acknowledged number in the corresponding ACK are then this sequence number plus 1.
  • If the SYN flag is clear (0), then this is the accumulated sequence number of the first data byte of this segment for the current session.
Acknowledgment number (32 bits)
if the ACK flag is set then the value of this field is the next sequence number that the receiver is expecting. This acknowledges receipt of all prior bytes (if any). The first ACK sent by each end acknowledges the other end's initial sequence number itself, but no data.
Data offset (4 bits)
specifies the size of the TCP header in 32-bit words. The minimum size header is 5 words and the maximum is 15 words thus giving the minimum size of 20 bytes and maximum of 60 bytes, allowing for up to 40 bytes of options in the header. This field gets its name from the fact that it is also the offset from the start of the TCP segment to the actual data.
Reserved (3 bits)
for future use and should be set to zero
Flags (9 bits) (aka Control bits)
contains 9 1-bit flags
  • NS (1 bit) – ECN-nonce concealment protection (added to header by RFC 3540).
  • CWR (1 bit) – Congestion Window Reduced (CWR) flag is set by the sending host to indicate that it received a TCP segment with the ECE flag set and had responded in congestion control mechanism (added to header by RFC 3168).
  • ECE (1 bit) – ECN-Echo indicates
  • If the SYN flag is set (1), that the TCP peer is ECN capable.
  • If the SYN flag is clear (0), that a packet with Congestion Experienced flag in IP header set is received during normal transmission (added to header by RFC 3168).
  • URG (1 bit) – indicates that the Urgent pointer field is significant
  • ACK (1 bit) – indicates that the Acknowledgment field is significant. All packets after the initial SYN packet sent by the client should have this flag set.
  • PSH (1 bit) – Push function. Asks to push the buffered data to the receiving application.
  • RST (1 bit) – Reset the connection
  • SYN (1 bit) – Synchronize sequence numbers. Only the first packet sent from each end should have this flag set. Some other flags change meaning based on this flag, and some are only valid for when it is set, and others when it is clear.
  • FIN (1 bit) – No more data from sender
Window size (16 bits)
the size of the receive window, which specifies the number of window size units (by default, bytes) (beyond the sequence number in the acknowledgment field) that the sender of this segment is currently willing to receive (see Flow control and Window Scaling)
Checksum (16 bits)
The 16-bit checksum field is used for error-checking of the header and data
Urgent pointer (16 bits)
if the URG flag is set, then this 16-bit field is an offset from the sequence number indicating the last urgent data byte
Options (Variable 0–320 bits, divisible by 32)
The length of this field is determined by the data offset field. Options have up to three fields: Option-Kind (1 byte), Option-Length (1 byte), Option-Data (variable). The Option-Kind field indicates the type of option, and is the only field that is not optional. Depending on what kind of option we are dealing with, the next two fields may be set: the Option-Length field indicates the total length of the option, and the Option-Data field contains the value of the option, if applicable. For example, an Option-Kind byte of 0x01 indicates that this is a No-Op option used only for padding, and does not have an Option-Length or Option-Data byte following it. An Option-Kind byte of 0 is the End Of Options option, and is also only one byte. An Option-Kind byte of 0x02 indicates that this is the Maximum Segment Size option, and will be followed by a byte specifying the length of the MSS field (should be 0x04). Note that this length is the total length of the given options field, including Option-Kind and Option-Length bytes. So while the MSS value is typically expressed in two bytes, the length of the field will be 4 bytes (+2 bytes of kind and length). In short, an MSS option field with a value of 0x05B4 will show up as (0x02 0x04 0x05B4) in the TCP options section.
Some options may only be sent when SYN is set; they are indicated below as [SYN]. Option-Kind and standard lengths given as (Option-Kind,Option-Length).
  • 0 (8 bits) – End of options list
  • 1 (8 bits) – No operation (NOP, Padding) This may be used to align option fields on 32-bit boundaries for better performance.
  • 2,4,SS (32 bits) – Maximum segment size (see maximum segment size) [SYN]
  • 3,3,S (24 bits) – Window scale (see window scaling for details) [SYN][6]
  • 4,2 (16 bits) – Selective Acknowledgement permitted. [SYN] (See selective acknowledgments for details)[7]
  • 5,N,BBBB,EEEE,... (variable bits, N is either 10, 18, 26, or 34)- Selective ACKnowledgement (SACK)[8] These first two bytes are followed by a list of 1–4 blocks being selectively acknowledged, specified as 32-bit begin/end pointers.
  • 8,10,TTTT,EEEE (80 bits)- Timestamp and echo of previous timestamp (see TCP timestamps for details)[9]
  • 14,3,S (24 bits) – TCP Alternate Checksum Request. [SYN][10]
  • 15,N,... (variable bits) – TCP Alternate Checksum Data.
(The remaining options are obsolete, experimental, not yet standardized, or unassigned)
Padding
The TCP header padding is used to ensure that the TCP header ends and data begins on a 32 bit boundary. The padding is composed of zeros.[11]

[1-11] (https://en.wikipedia.org/wiki/Transmission_Control_Protocol)

C. Explain the purpose and functionality of UDP

The User Datagram Protocol (UDP) is one of the core members of the Internet protocol suite (the set of network protocols used for the Internet). With UDP, computer applications can send messages, in this case referred to as datagrams, to other hosts on an Internet Protocol (IP) network without prior communications to set up special transmission channels or data paths. The protocol was designed by David P. Reed in 1980 and formally defined in RFC 768.
UDP uses a simple transmission model with a minimum of protocol mechanism.[1] It has no handshaking dialogues, and thus exposes any unreliability of the underlying network protocol to the user's program. As this is normally IP over unreliable media, there is no guarantee of delivery, ordering or duplicate protection. UDP provides checksums for data integrity, and port numbers for addressing different functions at the source and destination of the datagram.
UDP is suitable for purposes where error checking and correction is either not necessary or performed in the application, avoiding the overhead of such processing at the network interface level. Time-sensitive applications often use UDP because dropping packets is preferable to waiting for delayed packets, which may not be an option in a real-time system.[2] If error correction facilities are needed at the network interface level, an application may use theTransmission Control Protocol (TCP) or Stream Control Transmission Protocol (SCTP) which are designed for this purpose.
A number of UDP's attributes make it especially suited for certain applications.

Packet structure[edit]

UDP is a minimal message-oriented Transport Layer protocol that is documented in IETF RFC 768.
UDP provides no guarantees to the upper layer protocol for message delivery and the UDP protocol layer retains no state of UDP messages once sent. For this reason, UDP is sometimes referred to asUnreliable Datagram Protocol.[4]
UDP provides application multiplexing (via port numbers) and integrity verification (via checksum) of the header and payload.[5] If transmission reliability is desired, it must be implemented in the user's application.
UDP Header
OffsetsOctet0123
OctetBit 0 1 2 3 4 5 6 7 8 910111213141516171819202122232425262728293031
00Source portDestination port
432LengthChecksum
The UDP header consists of 4 fields, each of which is 2 bytes (16 bits).[2] The use of the fields "Checksum" and "Source port" is optional in IPv4 (pink background in table). In IPv6 only the source port is optional (see below).
Source port number
This field identifies the sender's port when meaningful and should be assumed to be the port to reply to if needed. If not used, then it should be zero. If the source host is the client, the port number is likely to be an ephemeral port number. If the source host is the server, the port number is likely to be a well-known port number.[3]
Destination port number
This field identifies the receiver's port and is required. Similar to source port number, if the client is the destination host then the port number will likely be an ephemeral port number and if the destination host is the server then the port number will likely be a well-known port number.[3]
Length
A field that specifies the length in bytes of the UDP header and UDP data. The minimum length is 8 bytes since that's the length of the header. The field size sets a theoretical limit of 65,535 bytes (8 byte header + 65,527 bytes of data) for a UDP datagram. The practical limit for the data length which is imposed by the underlying IPv4 protocol is 65,507 bytes (65,535 − 8 byte UDP header − 20 byte IP header).[3]
In IPv6 Jumbograms it is possible to have UDP packets of size greater than 65,535 bytes.[6] RFC 2675 specifies that the length field is set to zero if the length of the UDP header plus UDP data is greater than 65,535.
Checksum
The checksum field is used for error-checking of the header and data. If no checksum is generated by the transmitter, the field uses the value all-zeros.[7] This field is not optional for IPv6.[8]

Comparison of UDP and TCP

Transmission Control Protocol is a connection-oriented protocol, which means that it requires handshaking to set up end-to-end communications. Once a connection is set up user data may be sent bi-directionally over the connection.
  • Reliable – TCP manages message acknowledgment, retransmission and timeout. Multiple attempts to deliver the message are made. If it gets lost along the way, the server will re-request the lost part. In TCP, there's either no missing data, or, in case of multiple timeouts, the connection is dropped.
  • Ordered – if two messages are sent over a connection in sequence, the first message will reach the receiving application first. When data segments arrive in the wrong order, TCP buffers delay the out-of-order data until all data can be properly re-ordered and delivered to the application.
  • Heavyweight – TCP requires three packets to set up a socket connection, before any user data can be sent. TCP handles reliability and congestion control.
  • Streaming – Data is read as a byte stream, no distinguishing indications are transmitted to signal message (segment) boundaries.
UDP is a simpler message-based connectionless protocol. Connectionless protocols do not set up a dedicated end-to-end connection. Communication is achieved by transmitting information in one direction from source to destination without verifying the readiness or state of the receiver. However, one primary benefit of UDP over TCP is the application to voice over internet protocol (VoIP) where latency and jitter are the primary concerns. It is assumed in VoIP UDP that the end users provide any necessary real time confirmation that the message has been received.
  • Unreliable – When a message is sent, it cannot be known if it will reach its destination; it could get lost along the way. There is no concept of acknowledgment, retransmission, or timeout.
  • Not ordered – If two messages are sent to the same recipient, the order in which they arrive cannot be predicted.
  • Lightweight – There is no ordering of messages, no tracking connections, etc. It is a small transport layer designed on top of IP.
  • Datagrams – Packets are sent individually and are checked for integrity only if they arrive. Packets have definite boundaries which are honored upon receipt, meaning a read operation at the receiver socket will yield an entire message as it was originally sent.
  • No congestion control – UDP itself does not avoid congestion, and it's possible for high bandwidth applications to trigger congestion collapse, unless they implement congestion control measures at the application level.

D. Explain the purpose and functionality of ports in general

In computer networking, a port is an application-specific or process-specific software construct serving as a communications endpoint in a computer's host operating system. A port is associated with an IP address of the host, as well as the type of protocol used for communication. The purpose of ports is to uniquely identify different applications or processes running on a single computer and thereby enable them to share a single physical connection to a packet-switched network like the Internet.
The protocols that primarily use ports are the Transport Layer protocols, such as the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP) of the Internet Protocol Suite. A port is identified for each address and protocol by a 16-bit number, commonly known as the port number. The port number, added to a computer's IP address, completes the destination address for a communications session. That is, data packets are routed across the network to a specific destination IP address, and then, upon reaching the destination computer, are further routed to the specific process bound to the destination port number.
Note that it is the combination of IP address and port number together that must be globally unique. Thus, different IP addresses or protocols may use the same port number for communication; e.g., on a given host or interface UDP and TCP may use the same port number, or on a host with two interfaces, both addresses may be associated with a port having the same number.
Of the thousands of enumerated ports, about 250 well-known ports are reserved by convention to identify specific service types on a host. In the client-server model of application architecture, ports are used to provide a multiplexing service on each server-side port number that network clients connect to for service initiation, after which communication can be reestablished on other connection-specific port numbers.

Common port numbers[edit]

Main article: List of TCP and UDP port numbers
The Internet Assigned Numbers Authority (IANA) is responsible for the global coordination of the DNS Root, IP addressing, and other Internet protocol resources. This includes the registration of commonly used port numbers for well-known Internet services.
The port numbers are divided into three ranges: the well-known ports, the registered ports, and the dynamic or private ports. The well-known ports are those from 0 through 1023. Examples include:
The registered ports are those from 1024 through 49151. IANA maintains the official list.[2] The dynamic or private ports are those from 49152 through 65535. One common use is for ephemeral ports.
E. Explain how retransmissions occur

Retransmission (data networks)

Retransmission, essentially identical with Automatic repeat request (ARQ), is the resending of packets which have been either damaged or lost. It is a term that refers to one of the basic mechanisms used by protocols operating over a packet switched computer network to provide reliable communication (such as that provided by a reliable byte stream, for example TCP).
Such networks are usually 'unreliable', meaning they offer no guarantees that they will not delay, damage, or lose packets, or deliver them out of order. Protocols which provide reliable communication over such networks use a combination of acknowledgments (i.e. an explicit receipt from the destination of the data), retransmission of missing and/or damaged packets (usually initiated by a time-out), andchecksums to provide that reliability.

Acknowledgment

There are several forms of acknowledgement which can be used alone or together in networking protocols:
  • Positive Acknowledgement: the receiver explicitly notifies the sender which packets, messages, or segments were received correctly. Positive Acknowledgement therefore also implicitly informs the sender which packets were not received and provides detail on packets which need to be retransmitted. Positive Acknowledgment with Re-Transmission (PAR), is a method used by TCP (RFC 793) to verify receipt of transmitted data. PAR operates by re-transmitting data at an established period of time until the receiving host acknowledges reception of the data.
  • Negative Acknowledgment (NACK): the receiver explicitly notifies the sender which packets, messages, or segments were received incorrectly and thus may need to be retransmitted (RFC 4077).
  • Selective Acknowledgment (SACK): the receiver explicitly lists which packets, messages, or segments in a stream are acknowledged (either negatively or positively). Positive selective acknowledgment is an option in TCP (RFC 2018) that is useful in Satellite Internet access (RFC 2488).
  • Cumulative Acknowledgment: the receiver acknowledges that it correctly received a packet, message, or segment in a stream which implicitly informs the sender that the previous packets were received correctly. TCP uses cumulative acknowledgment with its TCP sliding window.

Retransmission

Retransmission is a very simple concept. Whenever one party sends something to the other party, it retains a copy of the data it sent until the recipient has acknowledged that it received it. In a variety of circumstances the sender automatically retransmits the data using the retained copy. Reasons for resending include:

  • if no such acknowledgment is forthcoming within a reasonable time, the time-out
  • the sender discovers, often through some out of band means, that the transmission was unsuccessful
  • if the receiver knows that expected data has not arrived, and so notifies the sender
  • if the receiver knows that the data has arrived, but in a damaged condition, and indicates that to the sender

F. Explain the purpose and process of a reset

TCP resets

The stream of packets in a TCP connection each contains a TCP header. Each of these headers contains a bit known as the "reset" (RST) flag. In most packets this bit is set to 0 and has no effect, however if this bit is set to 1 it indicates to the receiving computer that the computer should immediately stop using the TCP connection – It should not send any more packets using the connection's identifying numbers (called ports), and discard any further packets it receives with headers indicating they belong to that connection. A TCP reset basically kills a TCP connection instantly.
When used as designed this can be a useful tool. One common application is the scenario where a computer (computer A) crashes while a TCP connection is in progress. The computer on the other end (computer B) will continue to send TCP packets since it does not know computer A has crashed. When computer A reboots, it will then receive packets from the old pre-crash connection. Computer A has no context for these packets and no way of knowing what to do with them, so it might send a TCP reset to computer B. This reset lets computer B know that the connection is no longer working. The user on computer B can now try another connection or take other action.
G. Describe various TCP options

TCP Header
OffsetsOctet0123
OctetBit 0 1 2 3 4 5 6 7 8 910111213141516171819202122232425262728293031
00Source portDestination port
432Sequence number
864Acknowledgment number (if ACK set)
1296Data offsetReserved
0 0 0		N
S		C
W
R		E
C
E		U
R
G		A
C
K		P
S
H		R
S
T		S
Y
N		F
I
N		Window Size
16128ChecksumUrgent pointer (if URG set)
20
...		160
...		Options (if data offset > 5. Padded at the end with "0" bytes if necessary.)
Options (Variable 0–320 bits, divisible by 32)
The length of this field is determined by the data offset field. Options have up to three fields: Option-Kind (1 byte), Option-Length (1 byte), Option-Data (variable). The Option-Kind field indicates the type of option, and is the only field that is not optional. Depending on what kind of option we are dealing with, the next two fields may be set: the Option-Length field indicates the total length of the option, and the Option-Data field contains the value of the option, if applicable. For example, an Option-Kind byte of 0x01 indicates that this is a No-Op option used only for padding, and does not have an Option-Length or Option-Data byte following it. An Option-Kind byte of 0 is the End Of Options option, and is also only one byte. An Option-Kind byte of 0x02 indicates that this is the Maximum Segment Size option, and will be followed by a byte specifying the length of the MSS field (should be 0x04). Note that this length is the total length of the given options field, including Option-Kind and Option-Length bytes. So while the MSS value is typically expressed in two bytes, the length of the field will be 4 bytes (+2 bytes of kind and length). In short, an MSS option field with a value of 0x05B4 will show up as (0x02 0x04 0x05B4) in the TCP options section.
Some options may only be sent when SYN is set; they are indicated below as [SYN]. Option-Kind and standard lengths given as (Option-Kind,Option-Length).
  • 0 (8 bits) – End of options list
  • 1 (8 bits) – No operation (NOP, Padding) This may be used to align option fields on 32-bit boundaries for better performance.
  • 2,4,SS (32 bits) – Maximum segment size (see maximum segment size) [SYN]
  • 3,3,S (24 bits) – Window scale (see window scaling for details) [SYN][6]
  • 4,2 (16 bits) – Selective Acknowledgement permitted. [SYN] (See selective acknowledgments for details)[7]
  • 5,N,BBBB,EEEE,... (variable bits, N is either 10, 18, 26, or 34)- Selective ACKnowledgement (SACK)[8] These first two bytes are followed by a list of 1–4 blocks being selectively acknowledged, specified as 32-bit begin/end pointers.
  • 8,10,TTTT,EEEE (80 bits)- Timestamp and echo of previous timestamp (see TCP timestamps for details)[9]
  • 14,3,S (24 bits) – TCP Alternate Checksum Request. [SYN][10]
  • 15,N,... (variable bits) – TCP Alternate Checksum Data.
(The remaining options are obsolete, experimental, not yet standardized, or unassigned)

H. Describe a TCP checksum error

If the data gets where it needs to go but is corrupted and we do not detect the corruption, this is in some ways worse than it never showing up at all. To provide basic protection against errors in transmission, TCP includes a 16-bit Checksum field in its header. The idea behind a checksum is very straight-forward: take a string of data bytes and add them all together. Then send this sum with the data stream and have the receiver check the sum. In TCP, a special algorithm is used to calculate this checksum by the device sending the segment; the same algorithm is then employed by the recipient to check the data it received and ensure that there were no errors.

I. Describe how TCP addresses error correction

To calculate the TCP segment header’s Checksum field, the TCP pseudo header is first constructed and placed, logically, before the TCP segment. The checksum is then calculated over both the pseudo header and the TCP segment. The pseudo header is then discarded.

When the TCP segment arrives at its destination, the receiving TCP software performs the same calculation. It forms the pseudo header, prepends it to the actual TCP segment, and then performs the checksum (setting the Checksum field to zero for the calculation as before). If there is a mismatch between its calculation and the value the source device put in the Checksum field, this indicates that an error of some sort occurred and the segment is normally discarded.

http://www.tcpipguide.com/free/t_TCPChecksumCalculationandtheTCPPseudoHeader-2.htm

J. Describe how the flow control process occurs

In data communications, flow control is the process of managing the rate of data transmission between two nodes to prevent a fast sender from outrunning a slow receiver. It provides a mechanism for the receiver to control the transmission speed, so that the receiving node is not overwhelmed with data from transmitting node. Flow control should be distinguished from congestion control, which is used for controlling the flow of data when congestion has actually occurred.[1] Flow control mechanisms can be classified by whether or not the receiving node sends feedback to the sending node.
Flow control is important because it is possible for a sending computer to transmit information at a faster rate than the destination computer can receive and process it. This can happen if the receiving computers have a heavy traffic load in comparison to the sending computer, or if the receiving computer has less processing power than the sending computer.

Stop-and-wait[edit|edit source]

Main article: Stop-and-wait ARQ
Stop-and-wait flow control is the simplest form of flow control. In this method, the receiver indicates its readiness to receive data for each frame, the message is broken into multiple frames. The sender waits for an ACK (acknowledgement) after every frame for specified time (called time out). It is sent to ensure that the receiver has received the frame correctly. It will then send the next frame only after the ACK has been received.

Operations[edit]

  1. Sender: Transmits a single frame at a time.
  2. Receiver: Transmits acknowledgement (ACK) as it receives a frame.
  3. Sender receive ACK within time out.
  4. Go to step 1.
If a frame or ACK is lost during transmission then it has to be transmitted again by sender. This retransmission process is known as ARQ (automatic repeat request).
The problem with Stop-and wait is that only one frame can be transmitted at a time and that often leads to inefficient transmission channel till we get the acknowledgement the sender can not transmit any new packet. During this time both the sender and the channel are unutilised.

Pros and cons of stop and wait[edit]

Pros
There is only one advantage to this flow control and that is its simplicity.
Cons
Inefficiency is created because the sender needs to wait for the ACK after every frame it transmits. This causes a lot of inefficiency when the propagation delay is much longer than the transmission delay.[2]
Stop and wait can also create inefficiencies when sending longer transmissions.[3] When longer transmissions are sent there is more likely chance for error in this protocol. If the messages are short the errors are more likely to be detected early. More inefficiency is created when single messages are broken into separate frames because it makes the transmission longer.[4]

Sliding Window[edit]

Main article: Sliding Window Protocol
A method of flow control in which a receiver gives a transmitter permission to transmit data until a window is full. When the window is full, the transmitter must stop transmitting until the receiver advertises a larger window.[5]
Sliding-window flow control is best utilized when the buffer size is limited and pre-established. During a typical communication between a sender and a receiver the receiver allocates buffer space for nframes (n is the buffer size in frames). The sender can send and the receiver can accept n frames without having to wait for an acknowledgement.The receiver acknowledges a frame by sending an acknowledgement that includes the sequence number of the next frame expected. This acknowledgement announces that the receiver is ready to receive n frames, beginning with the number specified. Both the sender and receiver maintain what is called a window. The size of the window is less than or equal to the buffer size.
Sliding window flow control has a far better performance than stop-and-wait flow control. This is because in a wireless environment data rates are very low and noise level is very high, so waiting for an acknowledgement for every packet that is transferred is not very feasible. Therefore, transferring data as a bulk would yield a better performance in terms of higher throughput.
Sliding window flow control is a point to point protocol assuming that no other entity tries to communicate until the current data transfer is complete.

Go Back N[edit]

Main article: Go-Back-N ARQ
An automatic repeat request (ARQ) algorithm, used for error correction, in which a negative acknowledgement (NAK) causes retransmission of the word in error as well as the previous N–1 words. The value of N is usually chosen such that the time take to transmit the N words is less than the round trip delay from transmitter to receiver and back again. Therefore a buffer is not needed at the receiver.
The normalized propagation delay (a) = propagation time (Tp)⁄transmission time (Tt), where Tp = Length (L) over propagation velocity (V) and Tt = bitrate (r) over Framerate (F). So that a =Lr⁄VF.
To get the utilization you must define a window size (N). If N is greater than or equal to 2a + 1 then the utilization is 1 (full utilization) for the transmission channel. If it is less than 2a + 1 then the equationN⁄1+2a must be used to compute utilization.[6]

Selective Repeat[edit]

Main article: Selective Repeat ARQ
Selective Repeat is a connection oriented protocol in which both transmitter and receiver have a window of sequence numbers. The protocol has a maximum number of messages that can be sent without acknowledgement. If this window becomes full, the protocol is blocked until an acknowledgement is received for the earliest outstanding message. At this point the transmitter is clear to send more messages.[7]

Comparison[edit]

This section is geared towards the idea of comparing Stop-and-wait, Sliding Window with the subsets of Go Back N and Selective Repeat.
Each equation is a general overview. View each page for more in-depth definition.

Stop-and-wait[edit]

Error free: 1/2a+1
With errors: 1-P/1+2a

Selective Repeat[edit]

We define throughput T as the average number of blocks communicated per transmitted block. It is more convenient to calculate the average number of transmissions necessary to communicate a block, a quantity we denote by 0, and then to determine T from the equation
T=1/b

Transmit flow control[edit]

Transmit flow control may occur:
The transmission rate may be controlled because of network or DTE requirements. Transmit flow control can occur independently in the two directions of data transfer, thus permitting the transfer rates in one direction to be different from the transfer rates in the other direction. Transmit flow control can be
Flow control can be performed

Hardware flow control[edit]

In common RS 232 there are pairs of control lines which are usually referred to as hardware flow control:
Hardware flow control is typically handled by the DTE or "master end", as it is first raising or asserting its line to command the other side:
  • In the case of RTS control flow, DTE sets its RTS, which signals the opposite end (the slave end such as a DCE) to begin monitoring its data input line. When ready for data, the slave end will raise its complementary line, CTS in this example, which signals the master to start sending data, and for the master to begin monitoring the slave's data output line. If either end needs to stop the data, it lowers its respective "data readyness" line.
  • For PC-to-modem and similar links, in the case of DTR flow control, DTR/DSR are raised for the entire modem session (say a dialup internet call), and RTS/CTS are raised for each block of data.

Software flow control[edit]

Main article: Software flow control
Oppositely, XON/XOFF is usually referred to as software flow control.

Open-loop flow control[edit]

The open-loop flow control mechanism is characterized by having no feedback between the receiver and the transmitter. This simple means of control is widely used. The allocation of resources must be a “prior reservation” or “hop-to-hop” type.
Open-loop flow control has inherent problems with maximizing the utilization of network resources. Resource allocation is made at connection setup using a CAC (Connection Admission Control) and this allocation is made using information that is already “old news” during the lifetime of the connection. Often there is an over-allocation of resources and reserved but unused capacities are wasted. Open-loop flow control is used by ATM in its CBR, VBR and UBR services (see traffic contract and congestion control).[1]
Open-loop flow control incorporates two controls; the controller and a regulator. The regulator is able to alter the input variable in response to the signal from the controller. An open-loop system has no feedback or feed forward mechanism, so the input and output signals are not directly related and there is increased traffic variability. There is also a lower arrival rate in such system and a higher loss rate. In an open control system, the controllers can operate the regulators at regular intervals, but there is no assurance that the output variable can be maintained at the desired level. While it may be cheaper to use this model, the open-loop model can be unstable.

Closed-loop flow control[edit]

The closed-loop flow control mechanism is characterized by the ability of the network to report pending network congestion back to the transmitter. This information is then used by the transmitter in various ways to adapt its activity to existing network conditions. Closed-loop flow control is used by ABR (see traffic contract and congestion control).[1] Transmit flow control described above is a form of closed-loop flow control.
This system incorporates all the basic control elements, such as, the sensor, transmitter, controller and the regulator. The sensor is used to capture a process variable. The process variable is sent to a transmitter which translates the variable to the controller. The controller examines the information with respect to a desired value and initiates a correction action if required. The controller then communicates to the regulator what action is needed to ensure that the output variable value is matching the desired value. Therefore there is a high degree of assurance that the output variable can be maintained at the desired level. The closed-loop control system can be a feedback or a feed forward system:
A feedback closed-loop system has a feed-back mechanism that directly relates the input and output signals. The feed-back mechanism monitors the output variable and determines if additional correction is required. The output variable value that is fed backward is used to initiate that corrective action on a regulator. Most control loops in the industry are of the feedback type.
In a feed-forward closed loop system, the measured process variable is an input variable. The measured signal is then used in the same fashion as in a feedback system.
The closed-loop model produces lower loss rate and queuing delays, as well as it results in congestion-responsive traffic. The closed-loop model is always stable, as the number of active lows is bounded.

PC–radio flow control[edit]

Flow control also includes the control of data transfer between the PC and the radio. While the PC is transferring data to the modem and if the modem detects a reception, the PC–radio communication must be paused, giving higher priority to the incoming signal.


Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)