Computer Networking Connec1on- Oriented Transport: : Overview RFCs: 793, 1122, 1323, 2018, 2581 point- to- point: one sender, one receiver reliable, in- order byte steam: no message boundaries pipelined: conges1on and flow control set window size send & receive buffers full duplex data: bi- direc1onal data flow in same connec1on MSS: maximum segment size connec1on- oriented: handshaking (exchange of control msgs) init s sender, receiver state before data exchange flow controlled: sender will not overwhelm receiver 1
segment structure URG: urgent data (generally not used) ACK: ACK # valid PSH: push data now (generally not used) RST, SYN, FIN: connection estab (setup, teardown commands) Internet checksum (as in UDP) 32 bits source port # dest port # head len sequence number acknowledgement number not used checksum U A P R S F Receive window Urg data pointer Options (variable length) application data (variable length) counting by bytes of data (not segments!) # bytes rcvr willing to accept Seq. # s: byte stream number of first byte in segment s data ACKs: seq # of next byte expected from other side cumula1ve ACK Q: how receiver handles out- of- order segments A: spec doesn t say, - up to implementer seq. # s and ACKs User types C host ACKs receipt of echoed C Host A Host B Seq=42, ACK=79, data = C Seq=79, ACK=43, data = C Seq=43, ACK=80 simple telnet scenario host ACKs receipt of C, echoes back C time 2
Round Trip Time and Timeout Q: how to set 1meout value? longer than RTT but RTT varies too short: premature 1meout unnecessary retransmissions too long: slow reac1on to segment loss Q: how to es1mate RTT? SampleRTT: measured 1me from segment transmission un1l ACK receipt ignore retransmissions SampleRTT will vary, want es1mated RTT smoother average several recent measurements, not just current SampleRTT reliable data transfer creates rdt service on top of IP s unreliable service pipelined segments cumula1ve ACKs uses single retransmission 1mer retransmissions are triggered by: 1meout events duplicate ACKs ini1ally consider simplified sender: ignore duplicate ACKs ignore flow control, conges1on control 3
data rcvd from app: create segment with seq # seq # is byte- stream number of first data byte in segment start 1mer if not already running (think of 1mer as for oldest unacked segment) expira1on interval: TimeOutInterval sender events: 1meout: retransmit segment that caused 1meout restart 1mer ACK rcvd: if acknowledges previously unacked segments update what is known to be ACKed start 1mer if there are outstanding segments : retransmission scenarios Host A Host B Host A Host B timeout SendBase = 100 time X loss ACK=100 ACK=100 lost ACK scenario Sendbase = 100 SendBase = 120 SendBase = 120 Seq=92 timeout Seq=92 timeout time Seq=100, 20 bytes data ACK=100 ACK=120 ACK=120 premature timeout 4
retransmission scenarios (more) Host A Host B timeout Seq=100, 20 bytes data X loss ACK=100 SendBase = 120 ACK=120 time Cumulative ACK scenario ACK genera1on [RFC 1122, RFC 2581] Event at Receiver Arrival of in-order segment with expected seq #. All data up to expected seq # already ACKed Arrival of in-order segment with expected seq #. One other segment has ACK pending Arrival of out-of-order segment higher-than-expect seq. #. Gap detected Arrival of segment that partially or completely fills gap Receiver action Delayed ACK. Wait up to 500ms for next segment. If no next segment, send ACK Immediately send single cumulative ACK, ACKing both in-order segments Immediately send duplicate ACK, indicating seq. # of next expected byte Immediate send ACK, provided that segment starts at lower end of gap 5
Fast Retransmit 1me- out period oaen rela1vely long: long delay before resending lost packet detect lost segments via duplicate ACKs. sender oaen sends many segments back- to- back if segment is lost, there will likely be many duplicate ACKs for that segment If sender receives 3 ACKs for same data, it assumes that segment aaer ACKed data was lost: fast retransmit: resend segment before 1mer expires receive side of connec1on has a receive buffer: Flow Control flow control sender won t overflow receiver s buffer by transmicng too much, too fast IP datagrams (currently) unused buffer space data (in buffer) application process speed- matching service: matching send rate to receiving applica1on s drain rate app process may be slow at reading from buffer 6
Flow control: how it works IP datagrams (currently) unused buffer space rwnd RcvBuffer data (in buffer) application process (suppose receiver discards out- of- order segments) unused buffer space: = rwnd = RcvBuffer-[LastByteRcvd - LastByteRead] receiver: adver1ses unused buffer space by including rwnd value in segment header sender: limits # of unacked bytes to rwnd guarantees receiver s buffer doesn t overflow Connec1on Management Recall: sender, receiver establish connec1on before exchanging data segments ini1alize variables: seq. #s buffers, flow control info (e.g. RcvWindow) client: connec1on ini1ator Socket clientsocket = new Socket("hostname","port number"); server: contacted by client Socket connectionsocket = welcomesocket.accept(); Three way handshake: Step 1: client host sends SYN segment to server specifies ini1al seq # no data Step 2: server host receives SYN, replies with SYNACK segment server allocates buffers specifies server ini1al seq. # Step 3: client receives SYNACK, replies with ACK segment, which may contain data 7
Connec1on Management (cont.) Closing a connec1on: client server client closes socket: clientsocket.close(); close FIN Step 1: client end system sends FIN control segment to server ACK FIN close Step 2: server receives FIN, replies with ACK. Closes connec1on, sends FIN. timed wait closed ACK Connec1on Management (cont.) Step 3: client receives FIN, replies with ACK. Enters 1med wait - will respond with ACK to received FINs Step 4: server, receives ACK. Connec1on closed. closing client FIN ACK FIN server closing Note: with small modifica1on, can handle simultaneous FINs. timed wait ACK closed closed 8
Connec1on Management (cont) server lifecycle client lifecycle 9