networking

Networking

Transport Layer

Networking – Transport Layer

• The Transport Layer is part of the Internet Protocol stack

• The Transport Layer sits between the Application Layer and the Network Layer

• The Transport Layer provides communication services to the application processes in a network


• Main properties of Transport Layer– Provides logical (not physical) connection

between processes– Implemented in end system (processes), not in

e.g. routers– The data unit at the Transport Layer level is a

segment, not a full message– Two common Transport layer protocls are TCP

and UDP


• Transport Layer vs. Network Layer– Transport Layer transports data

between processes running of different hosts

– Network Layer transports data between hosts

– A Transport Layer protocol can offer services that the underlying Network Layer protocol does not offer


• Multiplexing/demultiplexing

Network Layer

Transport Layer


• Multiplexing/demultiplexing• How does it work in the letter analogy?

Jim CarpenterHigh Road 1122209 Smallville

Sue MillerSchool Street 2078865 Silvertown

A stamp

…

Source person

Destinationperson

Source location

Destinationlocation


• Multiplexing/demultiplexing• Remember– A host is specified by its IP address– A process is specified by its port number

Transport Layer segment


• Client side process– ”I run on port 55”– ”I wish to talk to a server running on port 23”

• Remember IP address of client host is also included in the segment (at IP level)

55 23


• Server side process– ”I run on port 23”– ”I wish to reply to the client running on port 55”

23 55


• What if two different clients – running on different hosts – use the same port number (for different processes)?

• No problem, since the two hosts will have different IP addresses!

• It is the combination of IP address and port number that must be unique (just as name and address for a plain letter…)


• Specific Transport Layer protocols – UDP• UDP – User Datagram Protocol• In the context of the Internet Protocol Stack, it

is built on top the IP Network Protocol• Adds just two ”services” to the IP protocol– Multiplexing/demultiplexing– Lightweight data validation


• Multiplexing/demultiplexing is done using the source and destination port numbers, as explained previously

• Length field specifies the length (in bytes) of the actual data

• Checksum field is used for data validation


• Data validation uses a so-called checksum calculation

• Data is binary – consists of 0s and 1s (bits)

• Binary numbers can be added together, just as decimal numbers


• Adding two 16-bit binary numbers also produces a 16-bit binary number

• All the 16-bit ”words” in the data fields are added together, producing a single 16-bit binary number

• The 16-bit binary number in the checksum field is now chosen in a clever way…


0100101011011101

1111111111111111

+(16-bit checksum)


• This is 1-complement checksum• If we add…– All the 16-words of the data field, plus– The 16-bit checksum

• …we always get 1111111111111111


• Server side– Given the data,

calculate the corresponding checksum

– Put the checksum in the checksum field

– Send to client

• Client side– Receive from server– Add up all data and

the chekcsum– If the result is not

1111111111111111, we have discovered an error!


• How does UDP handle a data error…?– Some UDP implementations simply throw away

damaged segments– Other deliver them to the application, with an

indicating that the data is damaged• Higher-level error handling must be done by

the receiving application!


• Specific Transport Layer protocols – TCP• TCP – Transmission Control Protocol• In the context of the Internet Protocol Stack, it

is built on top the IP Network Protocol• TCP adds significant non-trivial services to the

IP protocol!


• Main TCP features– Reliable data transfer – data is guaranteed to

arrive without errors, and in the correct order– Flow control – match the transmission speed of

sender and receiver– Congestion control – makes sure that no single

connection is allowed to flood the network with data traffic (a benefit for the Internet as a whole, not so much for the individual connection…)


• How can you implement ”reliable data transfer”?

• A complex task!• Not only at the Transport

Layer level, but also at the ”deeper” levels

• We will explore the problem in general


• Abstract look at data transfer:

Sender Receiver

Data

Reliable channel

ApplicationLayer

TransportLayer

Reliable!


• Data transfer seen from the Transport Layer:

Sender Receiver

Data

Unreliable channel

TransportLayer

NetworkLayer

Reliable!


• Levels of unreliability– Level 0 - perfect reliability (no loss of data

packets, no errors in data packets)– Level 1 - partial reliability (no loss of data packets,

possible errors in data packets)– Level 2 – no reliability (possible loss of data

packets, possible errors in data packets)


• Level 0 – perfect reliability– Essentially trivial to implement– Data from the Application Layer is

divided into segments, headers are added, and data is sent

– Similarly, data is extracted on the server side, and handed to the Application Layer


• Level 1 – Partial reliability– Packets are guaranteed to

arrive at their destination…– …but the content of a packets

may be damaged– We need a mechanism for

retransmission of a damaged packet


• Main steps involved– Checking whether or not (the data in) a packet is

damaged– Informing the sender of the packet whether or not

the received packet was intact– Known as an ARQ protocol (Automatic Repeat

reQuest)


• Error detection– We already saw an example (1-complement

checksum)– More sophisticated techniques exist (error

detection and correction)– Exact technique not important here– All techniques require sending extra data


• Receiver feedback– Receiver must provide explicit feedback to the

sender, about the successful/failed outcome of receiving a packet

– Receiver sends a packet back to sender– ACK (acknowledge) packet – all went well– NAK (not acknowledge) packet - failure


• Step 1: Send data packet n from Sender to Receiver

Sender Receiver

Data (n)


• Step 2a: Receiver finds data to be OK

Sender Receiver

Data (n)


• Step 3a: Receiver sends ACK packet to Sender

Sender Receiver

ACK


• Step 4a: Receiver gets ACK packet

Sender Receiver

ACK


• Step 1 (again): Send next piece of data from Sender to Receiver

Sender Receiver

Data (n+1)


• Step 2b: Receiver finds data to be damaged

Sender Receiver

Data (n)


• Step 3b: Receiver sends NAK packet to Sender

Sender Receiver

NAK


• Step 4b: Receiver gets NAK packet

Sender Receiver

NAK


• Step 1 (again): Send same piece of data from Sender to Receiver

Sender Receiver

Data (n)


• Packets are sent in order • Next packet is not sent

before the current packet has been correctly received (a stop-and-wait protocol)

• Sender thus always knows which data a ACK/NAK packet refers to


• Can anything go wrong…?• Data packet keeps getting

damaged…at some point we must give up (timeout)

• The ACK/NAK packets themselves could also become damaged!


• Possible solutions– Introduce ”acknowledge to acknowledge” packets

– hard to decide when to stop…– Better error correction – can only partially solve

the problem– Assume the worst – only consider a correctly

received ACK packet as meaning ”acknowledge”. Everything else is interpreted as NAK


• Problematic scenario– Receiver receives data, and confirms it to be OK– Receiver sends ACK to Sender– Sender receives a damaged packet, and interprets

this as a NAK (”assume the worst”)– Sender thus decides to to resend data– Receiver gets data. Data is OK, BUT is it• Resent data, or• New data?


• To resolve the problem, we intro-duce a data packet sequence number

• All data packets are marked with an incremental sequence number

• Receiver keeps track of the sequence number of the last correctly received package



Sender Receiver

Data (n)


• Step 2: Receiver finds data to be OK

Sender Receiver

Data (n)


• Step 3: Receiver sends ACK packet to Sender, and remembers sequence number

Sender Receiver

ACK

n


• Step 4: Receiver gets damaged ACK packet

Sender Receiver

!C¤

n


• Step 5: Resend data packet n from Sender to Receiver

Sender Receiver

Data (n)

n


• Step 6: Receiver looks at sequence number, and discovers that this is resent data

Sender Receiver

Data (n)

n


• Step 7: Receiver sends ACK packet to Sender (again), and can discard data…

Sender Receiver

ACK

n


• Step 8: Receiver gets correct ACK packet (hopefully…)

Sender Receiver

ACK

n


• Further optimisations• The sequence number

only needs to be a single bit (why…?)

• We only need ACKs, not NAKs (how…?)


• Level 2 – No reliability– The content of a packet may

be damaged– Packets may be entirely lost– Fully realistic: A router will

throw away packets if traffic gets too intense



Sender Receiver

Data (n)


• Step 2: Receiver finds data to be OK

Sender Receiver

Data (n)


• Step 3: Receiver sends ACK packet to Sender, and remembers sequence number

Sender Receiver

ACK

n


• Step 4: The ACK packet is lost!

Sender Receivern


• Obvious problem – how can the sender detect that something went wrong…?

• If the Sender does not receive an ACK within a certain time, the transmission has failed, and data must be resent

• Reasons for failure: Data packet lost, or ACK was lost

• How long is ”a certain time”…?


• Choosing a proper timeout time is not easy!• A compromise between allowing reasonable

time for a transmission to complete, and slowing down the entire transmission

• No matter the value, using a timeout introduces a risk of duplicate data packets

• Is already handled in level 1 protocol


• The Sender must thus– Reset and start the timer

whenever a data packet is sent

– Stop the timer when an ACK is received

– Respond to a timer timeout by resending the previous data packet


• It also becomes necessary to extend the ACK with the sequence number of the data packet that is being acknowledged (why…?)


• With the outlined extensions, the described protocol can implement reliable data transfer on top of an unrealiable network

• Protocol is the stop-and-wait type• Performance is poor, due to the need for a full

round-trip per packet• No pipelining!


• In order to achieve acceptable performance, pipelining must be included in the protocol

• Sender is allowed to send data packets without waiting for acknowledgements

• Consequences– Longer data packet sequence numbers– Sender-side buffering of data packets


• The Go-Back-N protocol (GBN)• Pipelining is allowed, BUT at most N unacknow-

ledged packets must be in the pipeline


• GBN Sender-side actions– Data received from upper layer– If fewer than N packets are in the pipeline, then

create a packet and send it– Else (i.e. N packets are in the pipeline) inform

caller that data cannot be sent– Caller must handle this rejection appropriately


• GBN Sender-side actions– ACK received from Receiver– The ACK will contain a sequence number– If ACK contains sequence number n, then all data

packets up to and including this sequence number are consider to be correctly received

– Also called a cumulative acknowledgement


• GBN Sender-side actions– Timeout event– No ACK has been received within the set time limit– Resend all packets for which an ACK has not been

received (up to N packets)– Hence the name ”Go back N”…


• GBN Receiver-side actions– Orderly data reception– Receiver receives data packet with sequence

number n– The previously received data packet had sequence

number (n -1)– All is in order; send ACK for data packet n– Deliver packet to upper layer


• GBN Receiver-side actions– Non-orderly data reception– Covers all other cases than ”orderly”– Resend ACK for most recently, orderly received

data packet k– Hence an ACK with sequence number k will

indicate: all data packets up to and including k have been properly received

– Data packet itself is discarded


Example: N = 4


• Go-Back N (GBN) implements pipelining, thereby greatly improving performance

• Still potential weaknesses for large values of N (say, N > 1000)

• One single error can provoke retransmission of thousands of data packets


• An alternative approach is a Selective Repeat (SR) protocol

• Main principle: only resend those specific data packets that Sender suspects were not correctly received by the Receiver


• Main principles of Selective Repeat– Receiver must individually acknowledge any

correctly received data packet– Out-of-order packets are buffered at the Receiver,

not discarded– Each packet must have its own (logical) timer at

the Sender– In general: SP is somewhat more complex, but

increases the effective bandwidth


• Recall the main TCP features– Reliable data transfer – data is guaranteed to

arrive without errors, and in the correct order (we know how to do that now…)


• Recall the main TCP features– Flow control – try to dynamically match the

transmission speed of the sender side with the processing speed of the receiver side (we will get back to that part…)


• Recall the main TCP features– Congestion control – makes sure that no

single connection is allowed to flood the network with an excessive amount of data (we will get back to that part…)

The Internet (IP)


Host Host

Data

TCP TCP


• TCP Connection• Before two hosts start to exchange data, they

will establish a (logical) connection• Initiator is called client, other side server• Needed information– Host address (IP address)– Port number


• TCP Connection• Note that the ”connection” only exists in the

end hosts – IP has no concept of connection!• TCP uses three-way handshake procedure to

establish a connection• Both sides will maintain a number of TCP

state variables and a data buffer during the connection

The Internet (IP)


Host Host

Data buffer

TCP (state)

Data buffer

TCP (state)


• Sending data in TCP• Connection is full-duplex; both parties can

send data at the same time• Data sent from a Sender will end up in the

Receivers data buffer• In the host processes, TCP will – from time to

time – take data (a segment) from the buffer and hand it to the application


Just like in UDP header


For reliable data transfer


Total length of the header


Various options for dynamic adjustments, e.g window size


Flag fields, e.g. acknowledge


Checksum for error detection


The amount of data the receiver will accept


• TCP provides realiable data transfer, using sequence numbers and acknowledgements

• Sequence number counts bytes, not segments (the number of the next byte the Receiver expect to receive)

• TCP uses pipelining of data, and selective retransmissions


• TCP offers flow control – matching the speed of Sender and Receiver

• Flow control is similar to – but not identical to – congestion control

• Prevents buffer overflow at the Receiver side


• Sender ”pumps” data in the Receiver buffer• Receiver consumes data when the application

process takes data from the buffer• In any segment sent, the size of the spare

room (RcvWindow) is placed in the ”rcvr window size” field


• Sender-side reasoning:– I have sent s bytes that are unacknowledged…– I know the Receiver has r bytes left…– …so, I must make sure that r > s

• If (r > s) keep sending data

else pause


• Note – this scheme has a problem (what?)

• Fortunately, the problem can be fixed (how?)


• TCP uses timeouts to decide if data needs to be retransmitted

• How to select a proper timeout value…?• Too low: many duplicate segments will be

sent, causing more bandwidth usage• Too high: available bandwidth is not utilised


• Lower limit for timeout is the round-trip time (RTT) – the time it takes to send data and get an acknowledge back

• A Sender can measure the RTT for each data segment is sends

• Problem: the RTT changes over time…


RTT Sample 1 2 3 4 5

RTT Value 27 32 40 22 28


• Strategy 1: Just calculate average over all available values


RTT Value 27 33 40 62 38

RTT Average 27 30 33 41 40


• Problems with Strategy 1• All values are given the same ”weight”, both

very old and brand new values• Historic values should become less and less

important, since the current state of the connection is more important


• Strategy 2: Only use the last n RTT values (e.g. n = 3)


RTT Value 27 33 40 62 38

RTT Average 27 30 33 45 47


• Problems with Strategy 2• Are the historic RTT values completely

unimportant?• Current conditions might be ”extreme”• What is a proper value for n?


• A compromise: exponential weighted moving average (EWMA)

• Formula (RTTA : RTT Average) :

RTTAnew = (1-w) RTTA∙ old + w RTT, w < 1∙


• EWMA in human language…– Historical RTT values are never ”forgotten”…– …but get less and less weight in the RTT average

• Example, w = 0.1– Weight of newest RTT value: 10 %– Weight of value before that: 9 %– Weight of value before that: 8.1 %– Weight of value before that: 7.3 %– …


• Strategy 3: Use EWMA, with w = 0.2


RTT Value 27 33 40 62 38

RTT Average 27 28 30 36 36


• Given we can properly estimate the average RTT, what is then a proper timeout value?

• Timeout = RTT average + ”a margin”• TCP can also track the average deviation d

from the average RTT (also uses EWMA)• Timeout = RTT average + 4d


• Congestion control – adjusting the speed of data transmission

• Not as such a benefit for the individual connection, but for ”the Internet as a whole”


• Why not just ”blast way”…?• Network only has a limited – and uneven –

capacity• Data packets will ”pile up” at routers• Routers can only buffer a finite number of

data packets – when buffers are full, data packets will be thrown away and lost


• The possible costs of congestion– When data arrives at a link at a rate close to the

link capacity, queueing delays increase rapidly– Sender must perform retransmissions when

routers start to drop packets– When a packet is dropped along a path of links,

the bandwidth used at previous links is wasted


• How can an end system detect congestion?• Network-assisted congestion control – the

underlying layers provide explicit feedback about network congestion state

• End-end congestion control – the end system themselves must detect congestion based on local observations (packet losses and delays)

• TCP is based on end-end congestion control


• Recall basic flow control– Receiver includes the current data window size in

data acknowledgements– Sender may not have more unacknowledged data

outstanding than the size of the data window• BUT should the sender always utilise this to

the limit…?


• Basic congestion control– Start out with a small data window (congestion

window) of size w– w is much smaller than ”allowed” by flow control– Sender may only have up to w bytes of

unacknowledged data outstanding– As long as Sender does not experience loss of

data, w can be increased


• Exactly how does w increase?• Sender maintains a so-called threshold value t,

where t is larger than the initial value of w– While w < t, the size of w doubles after each

successful transmission– While w >= t, the size of w is increased by one after

each successful transmission (segment size unit)– If a timeout is experienced: t = w/2, w = 1


• Final question – what is a proper initial value for the threshold?

• Common choice is the current value of the data window size, as defined by flow control

• Allows sending of data segments up to full buffer size, if possible


• Variants of TCP congestion control– Tahoe – as described above– Reno – includes mechanisms for fast

retransmission and fast recovery– Vegas – more sophisticated management of

window sizes and threshold


• Does TCP congestion control achieve the desired goal – global fairness of bandwidth use?

• Yes, seems to work in practice. Theory is somewhat complicated…

• Big joker is UDP-based applications!

networking

Documents

transport layer level

networking transport

application layer

ip network protocoladds

different processes

ip level

different ip addresses

destination port numbers