CS419: Computer NetworksLecture 10, Part 1: April 6, 2005Transport: UDP/TCP demux and flow control / sequencingCS419Recall our protocol layers . . .CS419. . . and our protocol graphCS419| IP gets the packet to the hostz Really the interface| Now how do we get the packet from the interface to the right process?| Well, you’ve kinda seen this already, but lets cover againCS419TCP and UDP ports| The ports serve to “demux” the packetz Get it from the interface to the right processSRC port DST portchecksum lengthDATAUDP HeaderCS419TCP and UDP ports| Some ports are “well-known”z HTTP is by default TCP port 80z DNS is UDP or TCP port 53z Etc.| Servers listen at these ports| Other ports are dynamically assignedz Clients usually dynamically assign portsCS419UDP/TCP application process selection| Unicast application process is selected by the complete 5-tuple, consisting of:z Source and Dest IP addressz Source and Dest portz IP protocolz Ex: an FTP server may have concurrent transfers to the same client. Only the source port will differ.| Multicast application process is selected by a 3-tuple: Dest IP address and UDP port, and IP protocolz Because it is multicast, UDP may select multiple processesCS419Typical server incoming connection processingClient HostServer HostListening ProcessClient Process1SA=C, DA=S, P=TCP, SP=5000, DP=23TCPTCPCS419Typical server incoming connection processingClient HostServer HostListening ProcessClient Process1SA=C, DA=S, P=TCP, SP=5000, DP=23Server Process1TCPforkTCPCS419Typical server incoming connection processingClient HostServer HostListening ProcessClient Process1SA=C, DA=S, P=TCP, SP=5000, DP=23Server Process1TCPforkClient Process2SA=C, DA=S, P=TCP, SP=5001, DP=23TCPCS419Typical server incoming connection processingClient HostServer HostListening ProcessClient Process1SA=C, DA=S, P=TCP, SP=5000, DP=23Server Process1TCPforkClient Process2SA=C, DA=S, P=TCP, SP=5001, DP=23Server Process1forkTCPCS419UDP and TCP service| UDP is connectionless packet transport servicez Like IP, packets can be lost, mis-ordered, duplicated| A receive() of X bytes corresponds to a previous send() of X bytesz And a corresponding packet of X bytes• (Ignoring packet loss or other errors like not providing enough receive buffer)| If sending app sends, but receiving app doesn’t receive, packet will be lostz Even if no packets are lost in the network!CS419UDP packet lossCS419UDP and TCP service| TCP is a reliable byte-stream transport servicez As long as the TCP connection is established, bytes arrive in the order they were sent| But, a send() of X bytes doesn’t imply a receive() of X bytesz Sender can send 500 bytes, and receiver can read 1 byte 500 times (and it could have been transmitted as 2 250-byte packets)z And vice versa| TCP provides flow controlCS419TCP flow controlCS419Stop-and-wait| Before looking at TCP in its full glory, lets look at simpler sequencing / flow control algorithms| Stop-and-wait is about as simple as it can get| Sender sends packet, waits for ack, sends another packet, . . .| Receiver receives packet, acks it . . .CS419Stop-and-waitCS419Stop-and-wait| Receiver only needs one packet’s worth of receive bufferz Only send ACK after received packet is processed| Sender only needs one packet’s worth of send bufferz Save packet until get ACK, then save the next packetCS419Even stop-and-wait not quite this simple!CS419Stop-and-wait requires a 1-bit sequence number spaceWorks correctly only if packets cannot be reordered in transitCS419Problem with stop-and-wait| Fine on a short-skinny pipez Low bandwidth, low distance| Wasteful on a long-fat pipez High delay x bandwidth product| 1.5 Mbps link, 45ms round-trip delayz Approx. 8KB BW x delay| Eight 1KB packets can be sent in one RTT, but stop-and-wait only sends one packet in one RTTCS419Sliding window| Sender can send multiple bytes before getting an ACK for the first bytez Number of bytes is the send windowz Sender must buffer these bytes in case it has to retransmit| Receiver can buffer multiple bytes before delivering any to the applicationz Number of bytes is the receive windowz Receiver must buffer these bytes in case application doesn’t read them on timez Or in case some bytes not receivedCS419Sliding windowCS419Send and receive window sizes| Send window should be big enough to fill the pipe| Receive window can (in theory) be smaller than send windowz As long as receiver can keep up with senderz But packet loss can result in more retransmits than necessary• So you really don’t want to do this…| No point in making receive window bigger than send windowz Unless congestion in network a concernCS419Sliding window examplesCS419Sliding window examples| Normal operation| Receive app delays reading| Packet lost| Cumulative ACK| NACK| Selective ACKCS419Seq number space must be at least two times window