Transport Layer Protocols

Module 2 Transport Layer Protocols

• Introduction to transport layer
• Multiplexing and demultiplexing
• Principles of Reliable data transfer
  • Stop-and-wait
  • Go-back-N design and evaluation
• Connection-oriented transport TCP
• Connection less transport UDP
• Principles of congestion control
  • Efficiency and fairness

How the Transport Layer Works

• Node to node: Data link layer.
• Host to host: Network layer.
• Process to process: Transport layer.

Transport Layer

• Transport layer is a central piece of the layered network architecture.
• It has the critical role of providing communication services directly to the application processes running on different hosts.
• Transport-layer principles:
  • How these principles are implemented in existing protocols.
  • Emphasis will be given to TCP and UDP transport-layer protocols.
  • The relationship between the transport and network layers.
• The Transport Layer of the OSI model delivers messages between networked hosts.
• It accepts data from the session layer, breaks it into packets, and delivers these packets to the network layer.
• Protocols include TCP, SPX, NETBIOS, ATP, and NWLINK.
• Network Devices: Brouter, Gateway, and Cable tester work on the transport layer.
• The transport layer provides services not furnished by lower layer protocols to achieve the quality of service needed.

Transport Layer Goal

• The ultimate goal of the transport layer is to provide efficient, reliable, and cost-effective service to its users, normally processes in the application layer.
• To achieve this goal, the transport layer uses the services provided by the network layer.
• The hardware and/or software within the transport layer that does the work is called the transport entity.
• First critical function of the transport layer—extending the network layer’s delivery service between two end systems to a delivery service between two application-layer processes running on the end systems.

Transport Layer Principles

• Principles confront one of the most fundamental problems in computer networking—how two entities can communicate reliably over a medium that may lose and corrupt data.
• Array of techniques that transport protocols use to solve this problem.
• How these principles are embodied in TCP, the Internet’s connection-oriented transport protocol.
• Second fundamentally important problem in networking—controlling the transmission rate of transport-layer entities in order to avoid, or recover from, congestion within the network.

Introduction and Transport-Layer Services

• A transport-layer protocol provides for logical communication between application processes running on different hosts.
• Logical communication:
  • From an application’s perspective, it is as if the hosts running the processes were directly connected.
  • In reality, the hosts may be on opposite sides of the planet, connected via numerous routers and a wide range of link types.
• Application processes use the logical communication provided by the transport layer to send messages to each other, free from the worry of the details of the physical infrastructure used to carry these messages.
• Transport-layer protocols are implemented in the end systems but not in network routers.
• On the sending side, the transport layer converts application-layer messages into transport-layer packets, known as transport-layer segments.
  • This involves breaking the messages into smaller chunks and adding a transport-layer header to each chunk to create the segment.
  • The transport layer then passes the segment to the network layer, where it is encapsulated within a network-layer packet (a datagram) and sent to the destination.
• The network routers act only on the network-layer fields of the datagram; they do not examine the fields of the transport-layer segment.
• On the receiving side, the network layer extracts the transport-layer segment from the datagram and passes it to the transport layer.
  • The transport layer processes the received segment, making the data available to the receiving application.

Transport and Network Layers

• The transport layer lies above the network layer in the protocol stack.
• A transport-layer protocol provides logical communication between processes running on different hosts; a network-layer protocol provides logical communication between hosts.
• Transport Layer provides logical communication between processes and exists only in hosts. Port numbers are used for routing in the destination computer, ignoring the network.
• Network Layer provides logical communication between hosts and exists in hosts and routers, routing data through the network. IP addresses are used for routing in the network.

Transport vs. Network Layer

• Network layer: logical communication between hosts.
• Transport layer: logical communication between processes.
• Transport Layer 3-5
• Household analogy: 12 kids in Ann's house sending letters to 12 kids in Bill's house:
  • Hosts = houses
  • Processes = kids
  • App messages = letters in envelopes
  • Transport protocol = Ann and Bill who demux to in-house siblings
  • Network-layer protocol = postal service
• Application messages = letters in envelopes, processes = cousins, hosts (end systems) = houses.
• Transport-layer protocol = Ann and Bill, network-layer protocol = postal service (including mail carriers).
• Transport-layer protocols live in the end systems and move messages from application processes to the network edge (network layer) and vice versa. They don’t have a say about how the messages are moved within the network core.
• Intermediate routers do not act on or recognize transport layer information added to application messages.
• Multiple transport protocols may be available, each offering a different service model to applications.

Transport-Layer Services

• Services offered depend on the postal service's capabilities. For example, if the postal service has no delivery time guarantee, Ann and Bill cannot guarantee a maximum mail delivery delay.
• Services a transport protocol provides are constrained by the underlying network-layer protocol's service model.
• If the network-layer protocol cannot provide delay or bandwidth guarantees, neither can the transport-layer protocol.
• Certain services, like reliable data transfer or encryption, can be offered by a transport protocol even if the corresponding service isn’t offered at the network layer.

Internet Transport Layer

• A TCP/IP network provides two distinct transport-layer protocols to the application layer: UDP (User Datagram Protocol) and TCP (Transmission Control Protocol).
• UDP provides an unreliable, connectionless service.
• TCP provides a reliable, connection-oriented service.
• Application developers must specify one of these protocols when designing a network application, by selecting between UDP and TCP when creating sockets.
• Transport layer packet as a segment.
• Internet literature refers to the transport-layer packet for TCP as a segment, but often refers to the packet for UDP as a datagram.
• Both TCP and UDP packets are referred to as segments.
• Datagram refers to network-layer packet.

Packet vs. Frame

• PACKET
  • Encapsulated created at the Network layer of the OSI model
  • Ex: IP-Packet
  • Pack contains Source and destination address along with Top layer data
  • Segment is encapsulated within packs
  • Herce segment is the data part
• FRAME
  • Encapsulated and created that layer of the OS
  • Ex: Ethernet frame
  • Frame cortis Source and destination MAC address along with Top layer
  • packet it encapulated within a frame
  • Hence packet is the data part
• Thus, a socket typically contains logical address information
• Thus a frame typically contains physical address information

IP Service Model:

• The Internet’s network-layer protocol is IP (Internet Protocol), providing logical communication between hosts.
• IP provides a best-effort delivery service, making its best effort to deliver segments but offering no guarantees.
• It does not guarantee: Segment delivery, Orderly segment delivery, Data integrity in the segments.
• IP is thus an unreliable service.
• Every host has at least one network-layer address, an IP address.

OSI Model

• Protocols in each layer:
  • Modbus, SEP2, DNP3, HTTP, IEC 61850, CIM, ICCP, BACnet, OpenADR, GOOSE
  • Compression and encryption protocols
  • NFS, SQL, SMB, RPC, P2P, tunneling, SCP, SDP, SIP, H.323
• TCP/IP Model
  • APPLICATION: Data
  • TRANSPORT: Segments - TCP, UDP
  • INTERNET: Packets - IPv4/IPv6, ARP, IGMP, ICMP
  • NETWORK INTERFACE: Bits and Frames - Ethernet, RS 232, UTP cables (CAT 5, 6), DSL, Optic fiber

Transport Layer Responsibilities

• UDP and TCP extend IP’s delivery service between two end systems to one between two processes running on the end systems.
• Extending host-to-host delivery to process-to-process delivery is called transport-layer multiplexing and demultiplexing.
• UDP and TCP provide integrity checking by including error detection fields in their segments’ headers.
• The two minimal transport-layer services:
  • Process-to-process data delivery
  • Error checking (both UDP and TCP provide)
• UDP is an unreliable service and does NOT guarantee that data sent by one process will arrive intact to the destination process.
• TCP offers additional services to applications, including reliable data transfer.

TCP and Data Transfer

• TCP provides reliable data transfer using flow control, sequence numbers, acknowledgments, and timers.
• It ensures data is delivered correctly and in order from sending to receiving process.
• TCP converts IP’s unreliable service between end systems into a reliable data transport service between processes and provides congestion control.
• Congestion control:
  • A service for the Internet as a whole.
  • Prevents any one TCP connection from swamping the links and routers between communicating hosts with an excessive amount of traffic.
  • Strives to give each connection traversing a congested link an equal share of the link bandwidth by regulating the rate at which the sending sides of TCP connections can send traffic into the network.
  • UDP traffic is unregulated.
  • An application using UDP transport can send at any rate it pleases, for as long as it pleases.
• A protocol that provides reliable data transfer and congestion control is necessarily complex.

TCP Congestion Control

• End-end control (no network assistance)
• Transmission rate limited by congestion window size, $CongWin$, over segments:
• Formula:
  • $Throughput = (CongWin * MSS) / RTT$

Reliable data transfer

• Transport application Layer Layer
• Sending process dala receiver process dala
• reliable channel (a) provided services
  • deliver_data()
  • rdt_send() dala reliable data transfer protocol (sending side)
  • udtsend()↑ packet (data) paoket (unreliable channel) rdtrev()

Reliable Delivery: Service Model

• Reliable, In-order Delivery Typically done when reliability is implemented at the
• transport layer, e.g., TCP
• Example application: File transfer

Multiplexing and Demultiplexing

• Transport-layer multiplexing and demultiplexing: extending the host-to-host delivery service from the network layer to a process-to-process delivery service for applications on the hosts.
• MULTIPLEXING/DEMULTIPLEXING service is needed for all computer networks.
• Multiplexing at sender:
  • Handle data from multiple sockets, add transport header (later used for demultiplexing).
• Demultiplexing at receiver:
  • Use header info to deliver received segments to correct socket.

Multiplexing/Demultiplexing Explained

• Multiplexing (many to one): an entity accepts items from more than one source.
• Demultiplexing (one to many): an entity delivers items to more than one source.
• Engaged in four processes simultaneously such as for Web pages, running one FTP session, and Telnet session.

Process to Process/Host to Host

• The Data link layer is responsible for delivery of frames between nodes over a link node to node delivery using a MAC address to choose one node among several.
• The Network layer is responsible for delivery of datagrams between two hosts host to host delivery using an IP address to choose one host among millions.
• Real communication takes place between two processes (application programs). We need process-to-process delivery.
• We need a mechanism to deliver data from one of process running on the source host to the corresponding process running on the destination host.
• The Transport layer is responsible for process-to-process. We need a port number, to choose among multiple processes running on the destination host.

Multiplexing

• At the destination host, the transport layer receives segments from the network layer.
• The transport layer delivers data in these segments to the appropriate application process running in the host.
• The computer receiving data From the network layer directs received data to the processes
• A process can have one or more sockets - doors through which data passes from the network to the process and through which data passes from the process to the network.
• The transport layer in the receiving host delivers data to a socket, not directly to a process.
• Sockets have unique identifiers, and the identifier format depends on the socket type (UDP or TCP).

Sockets

• Each transport-layer segment has fields to direct it to the appropriate socket.
• At the receiving end, the transport layer examines these fields to identify the receiving socket and directs the segment to that socket.
• The job of delivering the data in a transport-layer segment to the correct socket is called demultiplexing.
• The job of gathering data chunks from different sockets at the source host, encapsulating each chunk with header information, to create segments, and passing the segments to the network layer is called multiplexing.
• This is important whenever a single protocol at one layer is used by multiple protocols at the next higher layer.
• Transport-layer multiplexing requires
  • Sockets have unique identifiers.
  • Each segment have special fields that indicate the socket to which the segment is to be delivered, specifically source port number field and the destination port number field.
  • Each port number is a 16-bit number, ranging from 0 to 65535.

Port Numbers

• The port numbers ranging from 0 to 1023 are called well-known port numbers and are reserved for well-known application protocols such as HTTP (port 80) and FTP (port 21).
• The list of well-known port numbers is given in RFC 1700 and is updated at IANA.
• When we develop a new application, we must assign the application a port number.
• The transport layer implements the demultiplexing service by assigning port numbers to each socket and directing segments to the corresponding socket based on the destination port number.
  • Multiplexing/demultiplexing in TCP is more subtle.

Demultiplexing

• Why do we need demultiplexing?
• Assume is running 3 network applications all using the same transport protocol, e.g., TCP
  FTP Server, Telnet Client, Web Browser
• When a packet arrives at a host, it moves up the protocol stack until it reaches the transport layer, e.g., TCP
• Now, the transport layer needs a way to determine which application the packet needs to be delivered. This is the demultiplexing problem.
• Recall that all protocol layers perform multiplexing/demultiplexing: e.g., IP needs to determine which transport protocol a given packet needs to be delivered, UDP or TCP?

Connectionless Multiplexing and Demultiplexing

• When a UDP socket is created, the transport layer automatically assigns a port number to the socket.
• The transport layer assigns a port number in the range 1024 to 65535 that is not being used by any other UDP port in the host.
• The server side of the application assigns a specific well-known port number (0 to 1023).
• The client side of the application lets the transport layer automatically assign the port number.

UDP Multiplexing

• Suppose a process in Host A with UDP port 19157 wants to send data to a process with UDP port 46428 in Host B.
• The transport layer in Host A creates a transport-layer segment that includes: Application data, Source port number (19157), Destination port number (46428).
• The transport layer then passes the resulting segment to the network layer, which encapsulates it in an IP datagram and makes a best-effort attempt to deliver the segment to the receiving host.
• When the segment arrives at Host B, its transport layer examines the destination port number (46428) and delivers the segment to the socket identified by port 46428.
• Because Host B could be running multiple processes, each with its own UDP socket and associated port number, UDP segments are directed (demultiplexed) to the appropriate socket by examining the destination port number.
• A UDP socket is fully identified by a two-tuple consisting of a destination IP address and a destination port number.
• If two UDP segments have different source IP addresses or source port numbers but the same destination IP address and destination port number, they will be directed to the same destination process via the same destination socket.

Source Port Number

• The source port number serves as part of a return address—when B wants to send a segment back to A, the destination port in the B-to-A segment will take its value from the source port value of the A-to-B segment.
• A’s IP address and the source port number form the complete return address. Server uses the recvfrom() method to extract the clientside (source) port number from the segment it receives from the client; it then sends a new segment to the client, with the extracted source port number serving as the destination port number in this new segment.

TCP Connection Management

• TCP demultiplexing depends on TCP sockets and TCP connection establishment.
• A TCP socket is identified by a four-tuple: (source IP address, source port number, destination IP address, destination port number).
• When a TCP segment arrives at a host, the host uses all four values to direct (demultiplex) the segment to the appropriate socket.
• Two arriving TCP segments with different source IP addresses or source port numbers will be directed to two different sockets, except for a TCP segment carrying the original connection-establishment request.
• The TCP server application has a “welcoming socket” that waits for connection establishment requests, e.g., port number 12000.
• The TCP client creates a socket and sends a connection establishment request segment, a TCP segment with destination port number 12000 and a connection-establishment bit set in the TCP header, along with a source port number chosen by the client.
• The server process then creates a new socket, extracts the following four values in the connection-request segment:
  • The source port number in the segment,
  • The IP address of the source host,
  • The destination port number in the segment,
  • Its own IP address.
• The newly created connection socket is identified by these four values, and all subsequently arriving segments matching these values will be demultiplexed to this socket.
• Then, the client and server can send data to each other.
• The server host can support many simultaneous TCP connection sockets, each identified by its own four-tuple.

Demultiplexing

• Two clients, using the same destination port number (80) to communicate with the same Web server application
• Host C initiates two HTTP sessions to server B, and Host A initiates one HTTP session to B.
• Hosts A and C and server B each have their own unique IP address
• Host C assigns two different source port numbers (26145 and 7532) to its two HTTP connections.
• Host A might also assign a source port of 26145 to its HTTP connection.
• The server will still be able to correctly demultiplex the two connections, since the two connections have different source IP addresses.

Principles of Reliable Data Transfer

• The reliability problem occurs at the transport layer, link layer and application layer too.
• Reliability is an important problem.

The Service Abstraction

• The service abstraction provided to the upper-layer entities is that of a reliable channel through which data can be transferred.
• With a reliable channel, no transferred data bits are corrupted or lost, and all are delivered in the order in which they were sent.
• This is the service model offered by TCP.
• It is the responsibility of a reliable data transfer protocol to implement this service abstraction.
• This task is made difficult by the fact that the layer below the reliable data transfer protocol may be unreliable.
• TCP is a reliable data transfer protocol implemented on top of an unreliable (IP) end-to-end network layer.
• Transport-level protocol or a global internetwork (a transport-level protocol) lower layers are simply an unreliable point-to-point channel.
• Packets will be delivered in the order in which they were sent, with some packets possibly being lost; i.e, the underlying channel will not reorder packets.
• The sending side of the data transfer protocol will be invoked from above by a call to rdt_send().

Protocol Mechanisms

• The sending side rdt is being called. The first step in developing any protocol is to choose a good name.
• On the receiving side, rdt_rcv() will be called when a packet arrives from the receiving side of the channel.
• When the rdt protocol wants to deliver data to the upper layer, it will do so by calling deliver_data().
• Unidirectional data transfer: data transfer from the sending to the receiving side.
• Reliable bidirectional (full-duplex) data transfer: both the send and receive sides of rdt send packets to the other side by a call to udt_send() (udt - unreliable data transfer).

Reliable Channel

• Reliable Data Transfer over a Perfectly Reliable Channel: rdt1.0
• The underlying channel is completely reliable.
• The protocol itself, rdt1.0, is trivial.
• There are separate FSMs for the sender and for the receiver.
• The sender and receiver FSMs have just one state.
• The sending side of rdt simply accepts data from the upper layer via the rdtsend(data) event, creates a packet containing the data (via the action makepkt(data)) and sends the packet into the channel.
• On the receiving side, rdt receives a packet from the underlying channel via rdtrcv(packet) event, removes the data from the packet (via the action extract (packet, data)) and passes the data up to the upper layer (via the action deliverdata(data)).
• All packet flow is from the sender to receiver; with a reliable channel there is no need for the receiver side to provide any feedback to the sender since nothing can go wrong.
• Thus, there is no need for the receiver to ask the sender to slow down.

Bit Error Channels

• Reliable Data Transfer over a Channel with Bit Errors: rdt2.0
• A more realistic model - in which bits in a packet may be corrupted.
• Assume that all transmitted packets are received in the order in which they were sent (although their bits may be corrupted).
• Reliable data transfer protocols based on such retransmission are known as ARQ (Automatic Repeat reQuest) protocols.
• Three additional protocol capabilities are required in ARQ protocols to handle the presence of bit errors: Error detection, Receiver feedback, Retransmission.

Error Detection

• First, a mechanism is needed to allow the receiver to detect when bit errors have occurred.
• UDP uses the Internet checksum field for exactly this purpose.
• Error-detection and -correction techniques: allow the receiver to detect and possibly correct packet bit errors. These techniques require that extra bits be sent from the sender to the receiver.
• These bits will be gathered into the packet checksum field of the rdt2.0 data packet.
• Receiver feedback:
• The sender and receiver areexecuting on different end systems, possibly separated by thousands of miles, the only way for the sender to learn of the receiver’s view of the world (whether or not a packet was received correctly) is for the receiver to provide explicit feedback to the sender.
• The positive (ACK) and negative (NAK) acknowledgment replies in the message-dictation scenario are examples of such feedback.
• Rdt2.0 protocol send ACK and NAK packets back from the receiver to the sender. These packets need only be one bit long.

Retransmission

• A packet that is received in error at the receiver will be retransmitted by the sender.
• The send side of rdt2.0 has two states. In the leftmost state, the send-side protocol is waiting for data to be passed down from the upper layer.
• When the rdtsend(data) event occurs, the sender will create a packet containing the data to be sent, along with a packet checksum and then send the packet via the udtsend(sndpkt) operation.
• In the rightmost state, the sender protocol is waiting for an ACK or a NAK packet from the receiver.
• If an ACK packet is received (the notation rdt_rcv(rcvpkt) && isACK (rcvpkt)), the sender knows the most recently transmitted packet has been received correctly and thus the protocol returns to the state of waiting for data from the upper layer.
• If a NAK is received, the protocol retransmits the last packet and waits for an ACK or NAK to be returned by the receiver in response to the retransmitted data packet.
• Protocols such as rdt2.0 are known as stop-and-wait protocols.
• The receiver-side FSM for rdt2.0 still has a single state on packet arrival, the receiver replies with either an ACK or a NAK.
• When a packet is received and is found to be in error the notation is rdt_rcv(rcvpkt) && corrupt(rcvpkt).

Protocol Errors

• The ACK or NAK packet could be corrupted
• Will need to add checksum bits to ACK/NAK packets in order to detect such errors.
• The more difficult question is how the protocol should recover from errors in ACK or NAK packets.
• Problem: If an ACK or NAK is corrupted, the sender has no way of knowing whether or not the receiver has correctly received the last piece of transmitted data.
• Instead of sending a NAK, send an ACK for the last correctly received packet.
• A sender that receives two ACKs for the same packet knows that the receiver does not see the second packet so the packets resent.

Lossy Channels

• Reliable Data Transfer over a Lossy Channel with Bit Errors: rdt3.0
• The underlying channel can lose packets which is handled by:
  • How to detect packet loss
  • How to do stuff when a packet loss occurs
• Check summing, sequence numbers, ACK packets, and retransmissions are the techniques already developed rdt2.2 will allow lost or corrupted packets.
• Handling the loss requires a new protocol mechanism.

Lossy Errors

• We’ll put the burden of detecting and recovering from lost packets on the sender.
• Either the transmitter of the date or ACK is lost.
• No reply in sight so re-transmit after some time (as some packets are delayed).
• To know how long it needs to wait requires round-trip-delay, amount to process packet is unknown.
• Packet loss has likely, although not guaranteed, to have happened.
• The sender may retransmit the packet even though neither the data packet nor its ACK have been lost, or a timer has been initiated.
• Duplicate data packet, or some may have been lost all together.
• We are using sequence number now to transmit the data packet to see if the data needs resending or not.
• The sender implements time-based retransmission by
  • Start timer then resend packet that has timed out.
• Timer interputed and the timer must stop and must be invoked by the lower layer
• Timer interrupt or a call from the lower layer or be able to receive packet in some way, form, or fashion.
• These will be used in sequences number checksums and a timeout in every operational.

Pipelining

• rdt3.0 protocol has the core elements but the issue is that no one would use this due to performance to day speed.
• When sending from west cost to some one from east coast the speed will be some what 30 second so how fast in the network will it be with a 1gbits.
• So we need pipelining which helps improve the performance by sending without waiting for the acknowledgment.
• Utilization of the sender is only 2.7 % that is why pipelining must happen so the network hardware can fully improve.
• Imagine paying someone to improve or create a system that improve the transfer when is can only transfers 267kbps
• Allow the system in transits so each segment from sender and receiver can be visual the technique.

Go Back-N

• Is allowed to transmit multiple packets when there is no need to wait with some time, the # has limitation N
• If we define a base to sequence number the oldest unack and then have next segnum with of the next to be sent
• Thus the is 4 total
  • number have transmitting and acknowledge
  • Have been sent not acknowledge
  • Used when transmitting happens
  • No available until ack is send (base number should always been acknowledge).
• As sequence number which can see the window size the has the range the protocol that is moving forward.
• A packet is carried in fixed-length filed headers and K has number of bits can thus (0,24-1)

Window Size

• Maximum Window Size Two types of error control are used in protocols; Go-Back-N and Selective Repeat. Additionally for flow control purposes, sender and receiver maintain a window of acceptable sequence numbers.
• The receiver must be able to distinguish a retransmission of an already received packet from the original transmission of a new packet, the #n-1 in the case of Go-Back-N. The receiver only except is the next to be send and discards and packets and order
• In the example, with a 2-bit sequence number the maximum window size is 3#n/2 in Selective Repeat. Since the receiver accepts out-of-order packets, two consecutive windows should not overlap. Otherwise it is not able to distinguish
• duplicates from new transmissions, the maximum window size is 2
• EG: http://webmuseum.mi.fh-offenburg.de/index.php?view=exh&src=73

Go Back-N -ARQ

• Go-Back-N ARQ is a specific instance of the automatic repeat request (ARQ) protocol, in which the sending process continues to send a number of frames specified by a window size even without receiving an acknowledgement (ACK) packet from the receiver.
• It is a special case of the general sliding window protocol with the transmit window size of N and receive window size of 1. It can transmit N frames to the peer before requiring an ACK.

Go-Back Efficiency

• Go-Back-N ARQ is a more efficient use of a connection than Stop-and-wait ARQ, since unlike waiting for an acknowledgement for each packet, the connection is still being utilized as packets are being sent. In other words, during the time that would otherwise be spent waiting, more packets are being sent.
• The receiver sends ACKs for correctly received and in-order frames. When the sender receives a cumulative ACK, it updates its window base.
• However, if a frame is lost or damaged, or if the ACK acknowledging them is lost or damaged, that frame and all following frames in the window will be re-sent. Go-Back-N ARQ can waste bandwidth in high loss environments.

Go Back actions

• The GBN sender must respond to three types of events
  • When code from and up level that windows full check that is n acknowledge the packets and thus the code is in and not sent.
  • GBN means ACK each the must be receive the packets this has all been acknowledgment, must see receiver (ACK)
  • The protocols “GBN” each for timer means retransfer the re send until the ACk is send to show the and stop with the timer

Selective Repeat

• GBN protocol gives access in that fills packs so in that channel that can limit the transfer
• As names suggest a limited performance with packets and a large channel
• The number re transmitted must be see since the packets are being lost due to channel, therefore a Selective repeat would be key.
• Individual retransmission will require the receiver also re acknowledge correctly receive packets must be received.
• Window used again like always to reduce and use the outstanding packets being send.

Actions

• Data that is above and when date is and SR to check the packet then sent the data and re turn to it (GBN)
• Timers use to to get lost all the logical transfer each to see if it being resent during transferring in transmission the sender bases has the transfer to move forward

Transfer

• SR receiver has the retransmitted to see if all be transfer
• SR will ack the correct receipt even of an out order transmission the out of the order needs to rebuffer since it needs the lower sequence is needs must be correct when its transfer to that code
• Even see some packets that are going missing and 325.

TCP

• The internet connect with all the data that as be reliable and in the transfer means sequence and the numbers needs what sequence transfer the data and numbers to correct the speed with the destination with data
• This type of protocol is an essential transfer protocol to ensure ever has a stable internet transfers

TCP Connections and States

• Establisment : the data is transferred in each that needs transfer each to transfer and handshake
• The connections need to run on both system which that intermediate needs to know as each needs to have that number for each transfer
• The client application that is creating the process from the application to another
• The first transfer that needs to transfer
• the code for that request
• Client.connection((connection is to server))
• The client has to connect that server so ever system must come and sync to know how code in a proper fashion