internet transport layer outline

8/16/2019 Internet Transport Layer Outline

http://slidepdf.com/reader/full/internet-transport-layer-outline 1/5

SUGAR-DFJ

transport service:provide logical communication between app process running on different h

ostrun in end systems

send side: break app msg into segment, pass to network layerreceive side: reassemble segment into msg, pass to app layer

Internet: TCP and UDP

TCP: reliable, in-order deliverycongestion controlflow controlconnection setup

UDP: unreliable, unordered deliveryno-frills extension of best-effort IPno delay guaranteeno bandwidth guarantee

demultiplexig at rcv host:delivering received segment to correct socket

multiplexing at send host

gathering data from multiple socket, envelope data with header

UDP: User Datagram Protocolno fills, bare bonesbest effort serviceconnectionless:

no handshakingUDP segment handled independently

no connection establishmentsimplesmall segment headerno congestion control

streaming multimedia apploss tolerantrate sensitiveDNS, SNMP

reliable transfer over UDP: add at application layer

checksum: detect error in transmit segment

Reliable data transfer:rdt1.0: reliable transfer over a reliable channel

no bit error

no loss of packet

rdt2.0: channel with bit errorACK, NACKerror detectionreceiver feedback -> sender

rdt2.1: handle garble ACK/NAKstop and waitretransmit current packet if ACK/NAK garble



sender add sequence number to each packetreceiver discard duplicate packet

rdt2.2: NAK free protocol

rdt3.0: channel with error and losssender wait reasonable amount of time for ACKretransmit if no ACK receive in this timerequire countdown timer

Pipelined protocol:pipelining: sender allow multiple, "in-flight", yet-to-be-acknowledge pa

cketrange of sequence number must be increasebuffering at sender and receiver

go-back-N, selective repeat

Go-back-N:sender: up to N unACK packet in pipelinereceiver: only send cumulative ACK

doesn't ACK packet if there is a gapsender has timer for oldest unACK packet

if time expire, retransmit all unACK packet

Selective repeat:sender: up to N unACK packet in pipelinereceiver: ACK individual packetsender: maintain timer for each unACK packet

if time expire, retransmit only unACK packet

Go-back-N:k-bit sequence number in packet headerwindow of up to N consecutive unACK packet allowACK all packet up to, including sequence number - cumulative ACK

may receive duplicate ACKtimer for each in-flight packettime out: retransmit packet n and all higher sequence number packet in w

indow

ACK-only: always send ACK for correctly received packet with highest inorder sequence number

may generate duplicate ACKneed only remember expected sequence number

out of order packetdiscardre ACK packet with highest inorder sequence number

Selective repeat:receiver ack all correctly receive packetsender only resend packet for which ACK not receive

sender window:N consecutive sequence numberlimit sequence of sent, unACK packet

sender:data from above:

if next available sequence number in window, send packettimeout(n):

resend packet n, restart timerACK(n)



mark packet n as receiveif n smallest unACK packet, advance window base to next

unACK sequence number

receiver:send ACK(n)out of order: bufferingin order: deliver, advance window to next not-yet-receive packet

TCP:point-to-point:

1 sender, 1 receiverreliable, inorder

no message boundarypipeline:

TCP congestion and flow control set window sizesend and receive buffer

full duplex data:bidirectional data flow in same connectionMSS: maximum segment size

connection-oriented:handshaking

flow control:

sender will not overwhelm receiver

TCP segment:source port numberdest port numbersequence numberACK numberheader lengthURG: urgent dataReceive windowchecksumurg data pointeroptions

application data

EstimatedRTT = (1 - alpha) * EstimatedRTT + alpha * SampleRTT

TCP reliable data transfer:TCP create rdt service on top of IP unreliable servicepipelined segmentcumulative ACKsTCP use single retransmission timer

retransmission are triggered by:timeout eventduplicate ACK

initially consider simplified TCP sender:ignore duplicate ACKsignore flow control, congestion control

sender:create segment with seq #seq # is byte-stream number of first data byte in segmentstart timer if not already running



timeout:retransmit segment that cause timeoutrestart timer

ACK receive:if acknowledge previously unACK segment:

update what is known to be ACKstart timer if there are outstanding segments

fast retransmittimeout period often relatively long

long delay before resending lost packetdetect lost segment via duplicate ACK

sender often send many segmenet back-to-backif segment is lost, there will be many duplicate ACK for

that segmentfast retransmit: resend segment before timer expire

flow control:sender won't overflow receiver buffer by transmitting too much,

too fastreceiver advertise unused buffer space by including rwnd value i

n segment headersender: limit # of unACK byte to rwnd

connection management:establish connection before exchanging data segmentinitialize TCP variables

seq #s, buffer, flow control info3 way handshake:

client host send TCP-SYN segment to serverspecify initial seq #, no data

server host receive SYN, reply with SYNACK segment:server allocate bufferspecify server initial seq #

client receive SYNACK, reply with ACK segment, may contain data

closing connection:client end system send TCP FIN control segment to serverserver receive FIN, reply with an ACK, close connection,

send FINclient receive FIN, reply with an ACK

enter time wait, will respond with ACK to receive FIN

server receive ACK, close connection

Congestion control:too many source sending too much data too fast for network to handledifferent from flow controlmanifestation:

lost packet (buffer overflow at router)long delay (queueing in router buffer)

cost of congestion:more work for given goodputunneeded retransmissionwhen packet drop, any upstream transmission capacity use for tha

t packet was wasted

end-end congestion:



no explicit feedback from networkcongestion infer from end-system observe loss, delayapproach taken by TCP

network-assisted congestion control:router provide feedback to end system

single bit indicating congestionexplicit rate sender should send

ABR: avaliable bit rate:elastic serviceif sender's path underload:

sender should use available bandwidthif sender's path congested:

sender throttled to minimum guarantee rate

RM (resource management):sent by sender, intersperse with data cellbit in RM cell set by switch

NI bit: no increase in rateCI bit: congestion indication

RM cell return to sender by receiver, with bit intact

TCP congestion control:

should transmit as fast as possible, but without congesting networkdecentralized: each TCP sender set its own rate, base on implicit feedback:

ACK: segment receive, network not congest, increase sending ratelost segment: assume loss due to congestion, decrease sending ra

te

probing for bandwidth:increase transmission rate on receipt of ACK, until eventually l

oss occur, then decrease transmission rate

increase exponentially fast at connection start, or following timeoutcongestion avoidance: increase linearly

TCP slow start:when begin, cwnd = 1 MSSincrease rate exponentially until first loss event or when thres

hold reacheddouble cwnd every RTTdone by incrementing cwnd by 1 for every ACK received

AIMD: Additive Increase, Multiplicative Decrease

TCP fairness

internet transport layer outline

Documents