1 Principles behind Transport Layer Services

1.1 Multiplexing/Demultiplexing

Multiplexing at sender side, Demultiplexing at receiver side.

How Demultiplexing

Index with: IP + Port num

This part indicates that transport layer processes data with multiplexing, which function the multiple processes communicate in the network simultaneously without critical collisions. 

Now we can actually go in to UDP, but I'd like to put the principles in one section. Other Principles below are more relative withTCP.

1.2 Reliable Data Transfer

Reliability is one of the most important problem of Network. And it is obvious that there is no absolute reliability, though we are trying to find a more reliable way for data transmitting. 

So, most of the implementation of reliable data transferring is built on unreliable data transferring. It is an altitude to make it more reliable.

1. rdt1.0: reliable transfer over a reliable channel

It seems to be an ideal version of rdt.

2. rdt2.0: channel with bit errors

use checksum to detect errors: stop-and-wait

ACK: receiver tells sender that the pkt OK

NAK: receiver tells sender that the pkt BAD, and sender retransmit

So the rdt adds error detection and
receiver feedback

a fatal flaw: if ACK and NAK corrupt or duplicate.

3. rdt2.1: sequence number

Here are just two num 0 and 1. 

Sender must get the ACK/NAK before moving to next state.

Receiver must check if the pkt is duplicate, here num 0 and 1.

But the receiver can not know if the last ACK/NAK received OK at sender.

4. rdt2.2: a NAK-free protocol

Mostly same with rdt2.1 except without NAK

1) receiver send ACK for last pkt received OK

2) duplicate ACK at sender results in same action as NAK

5. rdt3.0: channel with errors and loss

new assumption: channel can lose pkts.

Sender wait amount of time for ACK. timeout->retransmit->multiple pkt, receiver must detect.

6. Pipeling

There are two types of pipeling protocols:

1) Go-back-N

Sender

There is N size window:

Timer for each pkt, timeout to retransmit. And the sender expects to get the pkt[nextseqnum]. 

Receiver:

Only send ACK for correctly-received pkt with highest sequence number - pkt[expectedseqnum].

If receiving out-of-order pkt, 

discard,

re-ACK with highest in-order sequence number.

2) Selective Repeat:

It promote some disadvantages of GBN of discarding the disorderred pkts. It buffers the pkts and move the windows until the lowerbound is ACKed(sender) or received(received)

1.3 Flow Control (talked in TCP)

1.4 Congestion Control

This is different from flow control. Congestion is said that too many sources sending much data too fast fornetwork to handle(but flow control is said to send and receiver).

There are several ways to congestion control, end systems lead(TCP) or network lead. I just want detail the congestion control in TCP below.

2 Transport Layer Protocols

2.1 UDP

1. Properties

1) connectionless: simple, small header, no congestion control

2) lost, deliver out of order

2. Checksum

An example

3. Segment Format

2.2 TCP

1. overview

end-to-end

reliable, in-order

pipeline

data: MSS

connection

flow control

2. RTT and Time out

1) RTT

2) Time out

timeout = RTT + safety margin

a. margin

b. timeout

3. rdt

sender

ACK received: update the Sendbase to ACK=y

time out: send with smallest sequence number

receiver

a. Formal: delay ACK

b. Higher than expected sequence: duplicated ACK of expected sequence

c. fill gaps: ACK of sequence at lower end of gap.

4. Retransmit

With the discussion above, if loss happens, there will likely be many duplicate ACKs. So sender will detect loss and begin tofast retransmit

Fast retransmit: resend segment before timer expire

5. Flow control

sender will not overflow the buffer of receiver.

Get the point above, sender limits unACKed data smaller thanspare room of receiver.

6. Connection Management

a. initiation work

seq num

flow control, buffer, rcvwindow

b. three way handshake

build:

1) client->server: SYN, initial seq num

2) server->client: SYNACK segment, server allocate buffers, specify initial seq num

3) client->server: reply ACK segment, may with data

close:

1) client->server: FIN

2) server->client: ACK first, after closing connection, send FIN

3) client->server: ACK

4) server: get ACK close.

7. Congestion control

To sum up the details of congestion control in TCP is that: send windows vary with the condition of congestion in the network. If the network is congested, the send will decrease the window size. If not the window will be enlarged. So the intension of sending
is according to the network condition.

How sender perceive congestion:

1) loss event: time out or 3 duplicate ACKs

Slow start

1) when connection begins, CongWin = 1 MSS

2) CongWin increase exponentially until loss event.

Loss

1) 3 dup ACKs:

Reno: CongWin half, win grow linear  -- 3 dup ACKs indicate the network capable of delivering some segments.

Tahoe: same with time out

2) timeout: CongWin set to 1 MSS, win grow exponentially to a threshold then linearly. -- timeout is a more alarming condition

End.