CS代写 RFC 768] - PowCoder代写

Introduction, Reliable Transport Protocols
Transport layer

Chapter goals:

Chapter Overview:
 understand principles behind transport layer services:
 transport layer services
 multiplexing/demultiplexing  reliable data transfer
 flow control
 congestion control
 connectionless transport: UDP
 instantiation and implementation in the Internet
 reliable transfer
 flow control
 connection management
Transport Layer
 multiplexing/demultiplexing
 principles of reliable data transfer
 connection-oriented transport: TCP
 principles of congestion control  TCP congestion control
Transport layer

Transport services and protocols
 provide logical communication between application processes running on different hosts
application
As far as the processes are concerned, they can communicate directly
 implemented in end systems, but not in network routers
network data link physical
network data link physical
network data link physical
 transport vs network layer services:
network data link physical
network data link physical
 transport layer: data transfer between processes
network data link physical
• relies on network layer services, and is therefore constrained by the service model of Network-layer protocol
application
• Adds enhanced services
Let’s look at a simple
 network layer: data transfer between end systems
analogy to see their
subtle differences
Transport layer
network data link physical

Transport Layer vs. Network Layer
East Coast
Postal-service mail carrier
Uncle Bill
An Analogy: Cousins sending letters
Uncle Sam & Uncle Bill – responsible for mail collection, distribution, and communicating with postal service
Postal service – carries the mails from
hosts (also called end systems) = ? West Coast hosts (also called end systems) = houses
processes = ? rocesses = cousins
applicaatiopnpmliecsasatigoesn=mleettesrsaingensv=elo?pe
transport layer protocol = Uncle Sam and Uncle Bill transport layer protocol = ?
network layer protocol = postal service (including mail network layer protocol = ?
house to house
Transport layer 4

Transport Layer vs. Network Layer
Their services are constrained by the possible services that the postal service provides
hosts (also called end systems) = houses
processes = cousins
application messages = letters in envelope
transport layer protocol = Uncle Sam and Uncle Bill network layer protocol = postal service (including mail
It may so happen that their uncles could get sick, and so other people may take over – analogously, the computer network may provide multiple transport protocols
Transport layer

Transport Layer vs. Network Layer
Transport Layer
Network Layer
logical communication between processes
logical communication between end systems
moves messages from application process to the network layer and vice-versa: Sending & Receiving sides
computer network can make multiple transport layer protocols available
• TCP • UDP
process-to-process communication
host-to-host communication Transport layer

layer5 layer4
layer5 layer4
layer3 layer2 layer1
layer3 layer2 layer1
Logical Communication
• converts Application-layer messages into Transport layer segments (4-PDUs):
• receives tranport-layer segments (4-PDUs)
-breaks down application messages into smaller chunks, then adds + transport layer header = transport segment(4-PDUs)
• removes transport header • reassembles the chunks
• Network Layer: Each transport-layer segment is encapsulated into a network-layer datagram.
back into the original msg • passes to receiving
Transport layer application process 7

(UDP) unreliable (“best- effort”), unordered unicast or multicast delivery
Transport-layer protocols
Internet transport services:
application
(TCP) reliable, in-order unicast delivery
 congestion
 flow control
 connection setup
network data link physical
network data link physical
 servicesnotavailable:  real-time
application
 bandwidth guarantees
 reliable multicast
network data link physical
Critical Function: Extend IP’s service from host-to-host delivery to
process-to-process delivery.
Transport layer
network data link physical
network data link physical
network data link physical
network data link physical

Multiplexing / demultiplexing
Multiplexing:
Job of gathering data chunks from multiple network application processes (different sockets), enveloping data with header (later used for demultiplexing) and passing the resulting segments to the network layer.
source port # dest port # other header fields
Multiplexing/Demultiplexing:  based on sender, receiver
application data
port numbers, IP addresses  source, destination port #s
in each segment
 recall: well-known port numbers for specific applications
TCP/UDP segment format
Ports: 0-1023 are well-known and restricted, complete list: www.iana.org
Transport layer
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?&page=1

Multiplexing/demultiplexing
Recall: segment – unit of data exchanged between
Demultiplexing: job of delivering the segments (received from the network layer) to the correct application layer processes (via sockets)
transport layer entities
 aka TPDU: transport protocol data unit
segment header
transport network
application transport network
application-layer data
P3 M M P4 application
M Hn segment
application transport network
Transport layer

Application Layer
Receiver process
Transport Layer
UDP SEGMENT
UDP SEGMENT
UDP SOCKETS
 A UDP socket is fully identified by a two-tuple consisting of a Destination IP address and a Destination port number.
Source IP: 18.200.155.123
Source Port: 2233
Destination IP: 130.123.246.333
Destination Port: 1155 …… data data
Transport layer
UDP socket
Destination IP: 130.123.246.333 Destination Port: 1155
Connectionless demultiplexing
Source IP: 18.200.155.456 Source Port: 2233
Destination IP: 130.123.246.333 Destination Port: 1155

Application Layer
Transport Layer
Source IP: 18.200.155.123 Source Port: 2233
Destination IP: 130.123.246.333 Destination Port: 1155
Source IP: 18.200.155.456 Source Port: 2233
Destination IP: 130.123.246.333 Destination Port: 1155
TCP SEGMENT
TCP SEGMENT
*This will take effect, once the TCP connections have been established between the clients and the server
TCP SOCKETS
 A TCP socket is fully identified by a four-tuple consisting of a Destination IP address, Destination port number, Source IP address and Source port
Receiver process
Receiver process
Source IP: 18.200.155.123
Source Port: 2233
Destination IP: 130.123.246.333
Destination Port: 1155 …… data data
Transport layer
Connection-oriented demultiplexing
Source IP: 18.200.155.456 Source Port: 2233
Destination IP: 130.123.246.333 Destination Port: 1155

Multiplexing/demultiplexing: example
source port: x dest. port: 23
Web client host C
source port:23 dest. port: x
Source IP: C Dest IP: B source port: y dest. port: 80
Source IP: C Dest IP: B source port: x dest. port: 80
port use: simple telnet app
Web client host A
Source IP: A Dest IP: B source port: x dest. port: 80
Web server B
How does a Web Server allow for multiple clients connecting to
it at the same time if it’s using TCP?
Transport layer
port use: Web server

UDP: User Datagram Protocol [RFC 768]
 “no frills,” “bare bones” Internet transport protocol
TCP – 20 bytes, UDP – 8 bytes
 “best effort” service, UDP segments may be:
Why is there a UDP?
 delivered out of order to
 no connection establishment (which can add delay)
 simple: no connection state at sender, receiver
 connectionless:
 no handshaking between
 small segment header
UDP sender, receiver
 no congestion control: UDP can blast away as fast as desired
 each UDP segment handled independently of others
Transport layer Additional functionalities are implemented by the application 14

 often used for streaming multimedia apps
 loss tolerant
Length, in bytes of UDP segment, including header
source port #
dest port #
 rate sensitive
 other UDP uses (why?):
Application data
 reliable transfer over UDP is possible: you need to add reliability at application layer
 application-specific error recovery!
UDP segment format
For segment error checking
The use of the checksum and source port fields is optional in IPv4 (pink background in table). In IPv6 only the source port field is optional.
Transport layer

 compute checksum of received
 treat segment contents (header and payload) as sequence of 16-bit integers
 checksum: addition (1’s complement sum) of segment contents
 check if computed checksum equals checksum field value:
 sender puts checksum value into UDP checksum field
 If YES – no error detected. But maybe there are errors nonetheless? More later ….
UDP checksum
Goal: detect “errors” (e.g., flipped bits) in transmitted segment
 If NOT equal – error detected!
Transport layer

Example #1
(Checksum calculation)
Transport layer

UDP checksum example:
 Three packets of 16 bits each
 The 1’s complement of ‘r’ is:
 0110011001100110  0101010101010101  0000111100001111
 0011010100110101
 adding the three, calling it ‘r’:
 At the destination, the sum of four packets should be:
 1100101011001010
 1111111111111111
 Send the four packets: the original three and one’s complement of ‘r’ to destination
 If the packet is damaged:
Why provide for error checking? No guarantee that it is provided in
all of the links between source and destination
 1111101111111111 (zeros!!)
Transport layer

Computation details
Note: Any overflow encountered during the binary sum will be wrapped around
1’s complement=
Transport layer

Example #2
(Checksum calculation)
Transport layer

Treat segment contents (header and payload) as sequence of 16-bit integers
source port # dest port # length checksum
Application data
16-bit words
Transport layer

Computation details with overflow
Content of segment(header and payload)
Calculate the binary sum of the first two rows of data:
16-bit words
Transport layer

Computation details with overflow
Content of segment(header and payload)
Calculate the binary sum of the first two rows of data:
Transport layer
Add the result (Sum1) to the third row of original data:
Note: Any overflow encountered during the binary sum will be wrapped around
16-bit words

Computation details with overflow
wrapping the carry and adding it to low order bit
Transport layer

At the receiver-side, upon receipt of the segment,
the checksum is extracted,
then added to the 16-bit word representation of the segment.
Note: Any overflow encountered during the binary sum will be wrapped around
If the packet has not been corrupted during the transfer, the sum will contain 16 1’s.
Transport layer

Transport layer

Principles of Reliable data transfer
 important in application, transport and link layers  top-10 list of important networking topics!
reliable channel
 characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)
Transport layer

Network layer
Principles of Reliable data transfer
 important in application, transport and link layers  top-10 list of important networking topics!
reliable channel
 characteristics of unreliable channel will determine complexity of
reliable data transfer protocol (rdt)
Transport layer
Unreliable channel

Reliable data transfer: getting started Application Layer
Network Layer
Unreliable channel
rdt_send(): called from above, (e.g., by app.). Pass data for
deliver_data(): called by rdt to deliver data to upper layer
delivery to receiver’s application layer
Transport Layer
receive side
udt_send(): called by rdt, to transfer packet over unreliable channel to receiver
rdt_rcv(): called when packet arrives on rcv-side of channel
Transport layer

Reliable data transfer: getting started We will:
 incrementally develop sender, receiver sides of reliable data transfer protocol (rdt)
consider only unidirectional data transfer • but control info will flow on both directions!
 use finite state machines (FSM) to specify sender, receiver
state: when in this “state” next state uniquely determined by next event
event actions
actions taken on state transition
Transport layer

reliable transfer over a reliable channel
Transport layer

Rdt1.0: reliable transfer over a reliable channel
 underlying channel perfectly reliable  no bit errors
 no loss of packets
 separate FSMs for sender, receiver:
 sender sends data into underlying channel  receiver read data from underlying channel
Transport layer

channel with bit errors
Transport layer

Rdt2.0: channel with bit errors Occurs during transmission, propagation and buffering
 underlying channel may flip bits in packet
 recall: UDP checksum is used to detect bit errors
 the question: how to recover from errors:
 acknowledgements (ACKs): receiver explicitly tells sender that pkt
received OK
 negative acknowledgements (NAKs): receiver explicitly tells sender that pkt had errors
 sender retransmits pkt on receipt of NAK
 human scenarios: message dictation using ACKs, NAKs?
new mechanisms in rdt2.0 (beyond rdt1.0): 1. error detection
2. receiver feedback: control msgs (ACK,NAK) rcvr->sender
3. retransmission Transport layer 34

rdt2.0: FSM specification
sender FSM receiver FSM Transport layer

rdt2.0: in action (error scenario)
sender FSM receiver FSM Transport layer

What to do?
 receiver discards (doesn’t deliver up) duplicate pkt
rdt2.0 has a fatal flaw!
What happens if ACK/NAK gets corrupted?
Handling duplicates:
 sender doesn’t know what happened at receiver!
 sender adds sequence number to each pkt
 It can’t just retransmit: there’s a possibility of duplication
 sender retransmits current pkt if ACK/NAK garbled
 sender ACKs/NAKs receiver’s ACK/NAK? However, what if the sender’s ACK/NAK gets lost?
stop and wait protocol
 retransmit, but this might cause retransmission of correctly received pkt!
Sender sends one packet, then waits for receiver’s response
Transport layer

Stop-and-wait protocol
channel with bit errors and loss
Transport layer

rdt3.0: channels with bit errors and loss Alternating bit Protocol
New assumption: underlying channel can also lose packets (data or ACKs)
 checksum, seq. #, ACKs, retransmissions will be of help, but not enough
Q: how to deal with packet loss?
 sender waits until certain data or ACK lost, then retransmits
 drawbacks?
Transport layer

rdt3.0 sender
Approach: sender waits for a “reasonable” amount of time for an ACK to arrive
 retransmit if no ACK is received within this period  if pkt (or ACK) was just delayed (and not lost):
retransmission would cause packet duplication, but use of seq. numbers already handles this
 receiver must specify seq # of pkt being ACKed  requires countdown timer (in the sender side only)  Replace NAK with Duplicate ACK s
Put the burden of detecting and recovering from lost packets to the sender
Transport layer

What we know so far…
 Reliable Data Transfer Mechanisms:
 Checksum
– Verification of integrity of packet (data or ACK)
Timer – Signals necessary re-transmission is required (used by sender)
Sequence number
 ACK  NAK
– Indicates receipt of packet in good or bad form (receiver);
– a duplicate ACK may replace a NAK
– Keeps track of which packet has been sent and received (data or ACK packets), for detecting duplicate packets
Transport Layer – TCP

Stop timer
Stop timer
do nothing
do nothing
Every time a packet is sent, the timer is restarted.
make_pkt(sndpkt,ACK1, checksum)
make_pkt(sndpkt, ACK0,checksum)
do nothing
do nothing
udt_send(sndpkt)
udt_send(sndpkt)
Transport layer

Stop timer
Stop timer
do nothing
do nothing
Every time a packet is sent, the timer is restarted.
make_pkt(sndpkt,ACK1, checksum)
make_pkt(sndpkt, ACK0,checksum)
Transport layer
do nothing
do nothing
udt_send(sndpkt)
udt_send(sndpkt)
Disregard incorrect ACK no.

End of Session
Transport layer

Performance of rdt v3.0
 rdt3.0 (STOP-AND-WAIT PROTOCOL) is a functionally correct protocol, but performance is not acceptable
 2 communicating hosts (one in the East Coast, and another in the West Coast), communicating over a 1 Gbps link.
 Assuming that the speed of light Round Trip Time (RTT) is approximately 30 msec., and that ACK packets are extremely small (that their transmission time is negligible)
 Packet size to transmit: (1KByte = 8Kbit)
 What is the throughput of the sender (or the channel)?
Transport layer

Performance of rdt v3.0
 2 communicating hosts (one in the East Coast, and another in the West Coast), communicating over a 1 Gbps link.
 Assuming that the speed of light RTT is approximately 30 msec., and that ACK packets are extremely small (that their transmission time is negligible)
 Packet size to transmit: (1KByte = 8Kbit)
 What is the throughput of the sender (or the channel)?
= 8kb/pkt = 8 microsec 1*(10^9) b/sec
fraction of time = 0.008 msec = 0.000267 sender busy sending 30.008 msec
Utilization = U =
 1KByte of packet every 30 msec -> 267 kb/sec throughput over 1 Gbps
 network protocol limits use of physical resources! Transport layer 48

Pipelined protocols
Pipelining: sender allows multiple, “in-flight”, yet-to- be-acknowledged packets
 range of sequence numbers must be defined  buffering at sender and/or receiver
Two generic forms of pipelined protocols:
Go-Back-N and Selective Repeat
Transport layer

socket door
application writes data
application reads data
socket door
 Reliable Data Transfer Mechanisms:
 Checksum
– Verification of integrity of packet (data or ACK)
Sequence number
 ACK  NAK
– Indicates receipt of packet in good or bad form (receiver);
– a duplicate ACK may replace a NAK
TCP send buffer
TCP receive buffer
Timer – Signals necessary re-transmission is required (used by sender)
– Keeps track of which packet has been sent and received (data or ACK packets), for detecting duplicate packets
Window, pipelining 50
– Allows for the sending of multiple yet-to-be-acknowledged packets
Transport Layer – TCP

Pipelining protocol
channel with bit errors and loss, etc.
https://media.pearsoncmg.com/ph/esm/ecs_kurose_compnetwork_8/cw/#interactiveanimations
Transport Layer – TCP

Variables:
• N – Window size
• base – base of the Window
• nextseqnum – sequence number of the packet t

程序代写 CS代考加微信: powcoder QQ: 1823890830 Email: powcoder@163.com

Related Posts