CH 3 Transport layer (Part 3)

Q13 Give difference

A)   TCP and UDP

B)    Flow control and congestion control

C)    GBN and SR

A) TCP and UDP

	TCP	UDP
Acronym for	Transmission Control Protocol	User Data-gram Protocol or Universal Data-gram Protocol
Connection	TCP is a connection-oriented protocol.	UDP is a connection-less protocol.
Function	As a message makes its way across the internet from one computer to another. This is connection based.	UDP is also a protocol used in message transport or transfer. This is not connection based which means that one program can send a load of packets to another and that would be the end of the relationship.
Usage	TCP is suited for applications that require high reliability, and transmission time is relatively less critical.	UDP is suitable for applications that need fast, efficient transmission, such as games. UDP's stateless nature is also useful for servers that answer small queries from huge numbers of clients.
Use by other protocols	HTTP, HTTPs, FTP, SMTP, Telnet	DNS, DHCP, TFTP, SNMP, RIP, VOIP.
Ordering of data packets	TCP rearranges data packets in the order specified.	UDP has no inherent order as all packets are independent of each other. If ordering is required, it has to be managed by the application layer.
Speed of transfer	The speed for TCP is slower than UDP.	UDP is faster because error recovery is not attempted. It is a "best effort" protocol.
Reliability	There is absolute guarantee that the data transferred remains intact and arrives in the same order in which it was sent.	There is no guarantee that the messages or packets sent would reach at all.
Header Size	TCP header size is 20 bytes	UDP Header size is 8 bytes.
Common Header Fields	Source port, Destination port, Check Sum	Source port, Destination port, Check Sum
Streaming of data	Data is read as a byte stream, no distinguishing indications are transmitted to signal message (segment) boundaries.	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.
Weight	TCP is heavy-weight. TCP requires three packets to set up a socket connection, before any user data can be sent. TCP handles reliability and congestion control.	UDP is lightweight. There is no ordering of messages, no tracking connections, etc. It is a small transport layer designed on top of IP.
Data Flow Control	TCP does Flow Control. TCP requires three packets to set up a socket connection, before any user data can be sent. TCP handles reliability and congestion control.	UDP does not have an option for flow control
Error Checking	TCP does error checking and error recovery. Erroneous packets are re-transmitted from the source to the destination.	UDP does error checking but simply discards erroneous packets. Error recovery is not attempted.
Fields	1. Sequence Number, 2. AcK number, 3. Data offset, 4. Reserved, 5. Control bit, 6. Window, 7. Urgent Pointer 8. Options, 9. Padding, 10. Check Sum, 11. Source port, 12. Destination port	1. Length, 2. Source port, 3. Destination port, 4. Check Sum
Acknowledgement	Acknowledgement segments	No Acknowledgment
Handshake	SYN, SYN-ACK, ACK	No handshake (connection-less protocol)

 

 B)  Flow control v/s Congestion control

      Flow control is controlled by the receiving side. It ensures that the sender only sends what the receiver can handle. Think of a situation where someone with a fast fiber connection might be sending to someone on dial-up or something similar. The sender would have the ability to send packets very quickly, but that would be useless to the receiver on dial-up, so they would need a way to throttle what the sending side can send. Flow control deals with the mechanisms available to ensure that this communication goes smoothly.

      Congestion control is a method of ensuring that everyone across a network has a "fair" amount of access to network resources, at any given time. In a mixed-network environment, everyone needs to be able to assume the same general level of performance. A common scenario to help understand this is an office LAN. You have a number of LAN segments in an office all doing their thing within the LAN, but then they may all need to go out over a WAN link that is slower than the constituent LAN segments. Picture having 100mb connections within the LAN that ultimately go out through a 5mb WAN link. Some kind of congestion control would need to be in place there to ensure there are no issues across the greater network.

C) GBN and SR

  

Basis for Comparison	Go-Back-N	Selective Repeat
Basic	Re-transmits all the frames that sent after the frame which suspects to be damaged or lost.	Re-transmits only those frames that are suspected to lost or damaged.
Bandwidth Utilization	If error rate is high, it wastes a lot of bandwidth.	Comparatively less bandwidth is wasted in re-transmitting.
Complexity	Less complicated.	More complex as it require to apply extra logic and sorting and storage, at sender and receiver.
Window size	N-1	<= (N+1)/2
Sorting	Sorting is neither required at sender side nor at receiver side.	Receiver must be able to sort as it has to maintain the sequence of the frames.
Storing	Receiver do not store the frames received after the damaged frame until the damaged frame is re-transmitted.	Receiver stores the frames received after the damaged frame in the buffer until the damaged frame is replaced.
Searching	No searching of frame is required neither on sender side nor on receiver	The sender must be able to search and select only the requested frame.
ACK Numbers	NAK number refer to the next expected frame number.	NAK number refer to the frame lost.
Use	It more often used.	It is less in practice because of its complexity.

Q14 Explain the TCP segment and justify the importance of its field values.

 

Field Name	Size (bytes)	Description
Source Port	2	Source Port: The 16-bit port number of the process that originated the TCP segment on the source device. This will normally be an ephemeral (client) port number for a request sent by a client to a server, or a well-known/registered (server) port number for a reply from a server to a client.
Destination Port	2	Destination Port: The 16-bit port number of the process that is the ultimate intended recipient of the message on the destination device. This will usually be a well-known/registered (server) port number for a client request, or an ephemeral (client) port number for a server reply.
Sequence Number	4	Sequence Number: For normal transmissions, the sequence number of the first byte of data in this segment. In a connection request (SYN) message, this carries the initial sequence number (ISN) of the source TCP. The first byte of data will be given the next sequence number after the contents of this field, as described in the topic on sequence number synchronization.
Acknowledgment Number	4	Acknowledgment Number: When the ACK bit is set, this segment is serving as an acknowledgment (in addition to other possible duties) and this field contains the sequence number the source is next expecting the destination to send. See the topic describing TCP data transfer for details.
Data Offset	1/2 (4 bits)	Data Offset: Specifies the number of 32-bit words of data in the TCP header. In other words, this value times four equals the number of bytes in the header, which must always be a multiple of four. It is called a “data offset” since it indicates by how many 32-bit words the start of the data is offset from the beginning of the TCP segment.
Reserved	3/4 (6 bits)	Reserved: 6 bits reserved for future use; sent as zero.
Control Bits	3/4 (6 bits)
Window	2	Window: Indicates the number of octets of data the sender of this segment is willing to accept from the receiver at one time. This normally corresponds to the current size of the buffer allocated to accept data for this connection. This field is, in other words, the current receive window size for the device sending this segment, which is also the send window for the recipient of the segment. See the data transfer mechanics topic for details.
Checksum	2	Checksum: A 16-bit checksum for data integrity protection, computed over the entire TCP datagram plus a special “pseudo header” of fields. It is used to protect the entire TCP segment against not just errors in transmission, but also errors in delivery. Optional alternate checksum methods are also supported.
Urgent Pointer	2	Urgent Pointer: Used in conjunction with the URG control bit for priority data transfer. This field contains the sequence number of the last byte of urgent data. See the priority data transfer topic for details.
Options	Variable
Padding	Variable	Padding: If the Options field is not a multiple of 32 bits in length, enough zeroes are added to pad the header so it is a multiple of 32 bits.
Data	Variable	Data: The bytes of data being sent in the segment.

Q15 How pipeline approach improves the overall sender utilization time? Explain GBN pipeline approach in transport layer.

In a Go-Back-N (GBN) protocol, the sender is allowed to transmit multiple packets (when available) without waiting for an acknowledgment, but is constrained to have no more than some maximum allowable number, N, of unacknowledged packets in the pipeline. Figure shows the sender's view of the range of sequence numbers in a GBN protocol.

If we define base to be the sequence number of the oldest unacknowledged packet and next segment number to be the smallest unused sequence number (i.e., the sequence number of the next packet to be sent), then four intervals in the range of sequence numbers can be identified. Sequence numbers in the interval [0, base-1] correspond to packets that have already been transmitted and acknowledged. The interval [base, nextseqnum-1] corresponds to packets that have been sent but not yet acknowledged. Sequence numbers in the interval [nextseqnum, base+N-1] can be used for packets that can be sent immediately, should data arrive from the upper layer. Finally, sequence numbers greater than or equal to base+N cannot be used until an unacknowledged packet currently in the pipeline has been acknowledged.

As suggested by Figure, the range of permissible sequence numbers for transmitted but not-yet-acknowledged packets can be viewed as a ``window'' of size N over the range of sequence numbers. As the protocol operates, this window slides forward over the sequence number space. For this reason, N is often referred to as the window size and the GBN protocol itself as a sliding window protocol.  You might be wondering why even limit the number of outstand standing, unacknowledged packet to a value of N in the first place.  Why not allow an unlimited number of such packets?

In practice, a packet's sequence number is carried in a fixed length field in the packet header. If k is the number of bits in the packet sequence number field, the range of sequence numbers is thus [0, 2k-1]. With a finite range of sequence numbers, all arithmetic involving sequence numbers must then be done using modulo 2^k arithmetic. (That is, the sequence number space can be thought of as a ring of size 2^k, where sequence number 2^k-1 is immediately followed by sequence number 0.) Recall that rtd3.0 had a 1-bit sequence number and a range of sequence numbers of [0, 1].Several of the problems at the end of this chapter explore consequences of a finite range of sequence numbers.  We will see in Section 3.5 that TCP has a 32-bit sequence number field, where TCP sequence numbers count bytes in the byte stream rather than packets. 

Q16 How many packets overhead while doing the data communication using TCP Draw the TCP connection establishment and termination process with diagram.

(We need a good answer for this Question as we were not able to explain it in a way that everyone can understand so if you think you can answer it well just go to contact us page and mail us the answer it will be displayed on blog with the credits.)

Q17 Describe why an application developer might choose to run an application over UDP rather than TCP.

In situations where you really want to get a simple answer to another server quickly, UDP works best. In general, you want the answer to be in one response packet, and you are prepared to implement your own protocol for reliability or to resend.

Another case is when you are delivering data that can be lost because newer data coming in will replace that previous data/state. Weather data, video streaming, a stock quotation service (not used for actual trading), or gaming data comes to mind.

Another case is when you are managing a tremendous amount of state and you want to avoid using TCP because the OS cannot handle that many sessions. This is a rare case today. In fact, there are now user-land TCP stacks that can be used so that the application writer may have finer grained control over the resources needed for that TCP state. “Prior to 2003, UDP was really the only game in town.”(Don’t write the quoted text in exam it’s just for Knowledge)

One other case is for multicast traffic. UDP can be multicast to multiple hosts whereas TCP cannot do this at all.

Q18 Explain the rdt3.0 with FSM diagram.

In addition to corrupting bits, the underlying channel can lose packets as well, a not uncommon event in today's computer networks (including the Internet). Two additional concerns must now be addressed by the protocol: how to detect packet loss and what to do when this occurs. The use of check summing, sequence numbers, ACK packets, and re transmissions - the techniques already developed in rdt 2.2 - will allow us to answer the latter concern. Handling the first concern will require adding a new protocol mechanism.

There are many possible approaches towards dealing with packet loss (several more of which are explored in the exercises at the end of the chapter). Here, we'll put the burden of detecting and recovering from lost packets on the sender. Suppose that the sender transmits a data packet and either that packet, or the receiver's ACK of that packet, gets lost. In either case, no reply is forthcoming at the sender from the receiver. If the sender is willing to wait long enough so that it is certain that a packet has been lost, it can simply re-transmit the data packet. You should convince yourself that this protocol does indeed work.

But how long must the sender wait to be certain that something has been lost? It must clearly wait at least as long as a round trip delay between the sender and receiver (which may include buffering at intermediate routers or gateways) plus whatever amount of time is needed to process a packet at the receiver. In many networks, this worst case maximum delay is very difficult to even estimate, much less know with certainty. Moreover, the protocol should ideally recover from packet loss as soon as possible; waiting for a worst case delay could mean a long wait until error recovery is initiated. The approach thus adopted in practice is for the sender to ``judiciously'' chose a time value such that packet loss is likely, although not guaranteed, to have happened. If an ACK is not received within this time, the packet is re-transmitted. Note that if a packet experiences a particularly large delay, the sender may re-transmit the packet even though neither the data packet nor its ACK have been lost. This introduces the possibility of duplicate data packets in the sender-to-receiver channel. Happily, protocol rdt2.2 already has enough functionality (i.e., sequence numbers) to handle the case of duplicate packets.

From the sender's viewpoint, re-transmission is a panacea. The sender does not know whether a data packet was lost, an ACK was lost, or if the packet or ACK was simply overly delayed. In all cases, the action is the same: re-transmit. In order to implement a time-based re-transmission mechanism, a countdown timer will be needed that can interrupt the sender after a given amount of timer has expired. The sender will thus need to be able to (i) start the timer each time a packet (either a first time packet, or a re-transmission) is sent, (ii) respond to a timer interrupt (taking appropriate actions), and (iii) stop the timer.

The existence of sender-generated duplicate packets and packet (data, ACK) loss also complicates the sender's processing of any ACK packet it receives. If an ACK is received, how is the sender to know if it was sent by the receiver in response to its (sender's) own most recently transmitted packet, or is a delayed ACK sent in response to an earlier transmission of a different data packet? The solution to this dilemma is to augment the ACK packet with an acknowledgement field. When the receiver generates an ACK, it will copy the sequence number of the data packet being ACK'ed into this acknowledgement field. By examining the contents of the acknowledgment field, the sender can determine the sequence number of the packet being positively acknowledged. 

Q19 Explain rdt1.0 with FSM diagram.

We first consider the simplest case in which the underlying channel is completely reliable. The protocol itself, which we will call rdt1.0, is trivial. The finite state machine (FSM) definitions for the rdt1.0 sender and receiver are shown in Figure 3.4-2.   The sender and receiver FSMs in Figure 3.4-2 each have just one state.  The arrows in the FSM description indicate the transition of the protocol from one state to another. (Since each FSM in Figure 3.4-2 has just one state, a transition is necessarily from the one state back to itself; we'll see more complicated state diagrams shortly.).  The event causing the transition is shown above the horizontal line labeling the transition, and the action(s) taken when the event occurs are shown below the horizontal line.

The sending side of rdt simply accepts data from the upper-layer via the rdt_send (data) event, puts the data into a packet (via the action make_pkt (packet, data)) and sends the packet into the channel. In practice, the rdt_send (data) event would result from a procedure call (e.g., to rdt_send ()) by the upper layer application.

On the receiving side, rdt receives a packet from the underlying channel via the rdt_rcv (packet) event, removes the data from the packet (via the action extract (packet, data)) and passes the data up to the upper-layer. In practice, the rdt_rcv (packet) event would result from a procedure call (e.g., to rdt_rcv ()) from the lower layer protocol.

In this simple protocol, there is no difference between a unit of data and a packet. Also, all packet flow is from the sender to receiver - with a perfectly reliable channel there is no need for the receiver side to provide any feedback to the sender since nothing can go wrong! (which is an illusion because nothing is perfect if nothing can go wrong in rdt1.0 why create rdt2.0 and others that’s not for discuss here but if you want to just go to the Contact us page and get connected to us).

Here chapter 3 ends finally!!!

We are always open for suggestions so if you have any just get in contact with us. Thank you for reading and good luck for exams if the reading was for the preparations.

Contact us

Previous Page