1. Connection Management: Choosing a Unique Identifier Problem: choose identifier (e.g., number) so that no other packet associated with this host currently in network has same identifier  host id unique globally, so concatenated address and identifier unique  assume we know maximum lifetime of packet in network (T) Approach: maintain state  keep list of all values used in last 2T (why 2T ?)  don’t reuse value in list  if list lost: wait 2T  concerns:

2. Choosing a Unique Identifier Approach: what me worry?  choose at random from large set (e.g., 2 32 ) of numbers  unlikely to choose new number previously chosen in last 2T  can be combined with used value list for more protection  good enough for many people (except academics)

3. Connection Establishment: Two-way Handshake  initiator sends req_conn(x) message to other side (respondent)  x is unique identifier  respondents accepts connection via acc_conn(x) reply

4. choose x send req_conn(x) conn x estab send data(x+1) conn x estab data(x+1) rcvd ACK(x+1) req_conn(x) acc_conn(x) data(x+1) ack(x+1)

5. INACTIVEWAIT ACKESTAB fromlayer3(acc_conn(x)) fromlayer3(req_conn(x)) tolayer3(acc_conn(x)) timeout tolayer3(req_conn(x)) fromlayer3(acc_conn(y)) initiator active open choose unique x tolayer3(req_conn(x)) respondent

6. Two-way Handshake: Old Messages acc_conn(y) recognized as old! choose x send req_conn(x) conn x estab send data(x+1) conn x estab data(x+1) rcvd ACK(x+1) req_conn(x) acc_conn(y) data(x+1) acc_conn(x) ignore

7. Two-way Handshake: Handling Duplicates choose x send req_conn(x) conn x estab send data(x+1) conn x estab data(x+1) rcvd ACK(x+1) req_conn(x) acc_conn(x) data(x+1) timeout send req_conn(x) req_conn(x) conn x already estab acc_conn(x)

8. Two-way Handshake: Failure Scenario Receiver cannot tell if req_conn(x) is a duplicate or not

9. Two-way Handshake with Timers Receiver won’t delete connection record for x until sure no more req_conn(x) in network  hold record until T after connection close

10. Two-way Handshake: Transactions Request to open connection, pass data, close connection accomplished with one packet  only one round trip delay needed for transactions  receiver: on receipt, perform operation on data, return reply, close connection

12. Three-way Handshake Two-way handshake:  sender chose unique identifer, x  allowed sender to detect old replies from receiver (receiver had to reply with x)  allowed receiver (with timers on x value) to detect old sender message

13. Three-way Handshake(cont) Three-way handshake:  let receiver also choose its own unique identifier, y, and require sender to reply back using y  allows receiver to detect old sender messages without using timers  requires three way exchange of messages to set up connection

14. Connection Management  connection establishment  2-way handshake with timer  3-way handshake (TCP)  connection teardown

15. 3-way handshake

17. Three-way Handshake Illustrated Three way handshake:  used in TCP, TP4, DECnet  header bits in TCP packet for SYN, ACK  trades extra round-trip requirements for no timers

18. Handshaking Scenarios in TCP active open connect() passive open accept() SYN recvd choose unique y y+1 tells us there’s a live client, goto ESTAB syn(x) synack(y,x+1) ack(x+1,y+1) x+1 tells us there’s a live connection go to ESTAB

19. Handshaking Scenarios in TCP messageoldconnection (no live client (no live client) passive open accept() SYN recvd choose unique y z+1 tells us this is NOT in response to y message! syn(x) synack(y,x+1) ack(x+1,z+1)

20. Closing a Connection Two approaches for closing a connection  abort: send close msg to peer, close connection, delete state info  what if close message lost?  graceful: send close msg, but before deleting state info wait for peer to acknowledge close

21. TCP graceful close:  initiator send FIN(x) msg to other side (respondent), waits until ACK(x+1) recvd  respondent: how to know if ACK(x+1 received)  if not received, don’t want to quit, because will need to resend ACK(x+1) later  ask initiator to ACK the ACK(x+1)?  wait 2T after sending ACK(x+1)?

22. Closing a Connection: Reaching Agreement Q: can I decide to close, knowing the other entity has also agreed to close and knows that I will close A similar scenario: can two armies coordinate their attacks if communication is unreliable?

23. Transport Protocol Timers We’ve seen several transport-level timers  timeout-retransmit timer  implicit connection close timer: in two way handshake  timeout on connection establishment: give up if no reply to SYN in 75 secs  delayed ACK timer – try to piggyback receiver-to-sender data on ACK, wait for 200 ms before generating standalone ACK Additional timers:  flow control timer (TCP persist timer) if receiver has set my window to 0 and no recent update, query receiver  keep-alive timer: if no activity in period, generate "I’m OK are you OK packet" – 2 hours in TCP

24. Timers: Implementation Physically: just one countdown timer  initialized, started, stopped via software  will generate interrupt after counting down to zero  protocol code (timer interrupt handler) initiated in response to interrupt

25. Timers: Implementation Logically: many timers may be running  all future timer timeout values recorded in data structures  hardware timer counts down to earliest interrupt time  on interrupt:  perform required activity  consult data structures, load physical timer with time until next closest interrupt time, start timer  return from interrupt time in future for this interrupt interrupt type next time in future for this interrupt interrupt type next time in future for this interrupt interrupt type next timer list

26. Estimating Round Trip Delays Retransmit timer values based on round trip delay estimate End-end-delays variable in wide area network (congestion) Estimating round trip time(RTT): exponential averaging  record time from packet send to ACK receipt  compute new RTT estimate using new measured round trip delay (M) and old estimate: RTT <- a*RTT + (1-a)*M RTT <- a*RTT + (1-a)*M  a in range [0,1], RTT changes slowly when a close to 1, quickly when a close to 0 complication: how to deal with retransmissions

27. Timers: Retransmit Timer Value  retransmission timer should be function of RTT (as estimated above)  timeout value = b * RTT  original TCP spec. recommends b=2  on packet timeout  increase timer value: loss of delay assumed due to congestion (rather than corruption)  doubling of timeout value is common (up to some threshold, Linux: doubles five times (2,4,8,16,32)) More art than science! More art than science!

28. TCP Retransmit Timer: Jacobson’s Algorithm Original TCP timer algorithm replaced in late 1980’s New approach:  adjust timer as a function of RTT and a measure of jitter (variability) (D): D = aD + (1-a)|RTT-M| D = aD + (1-a)|RTT-M|  timeout value = RTT + 4*D  M - measureded RTT

29. Multiplexing and Addressing Transport layer protocol often manages multiple higher layer connections  packet at layer N must contain info about which layer N+1 protocol to pass "data"  TCP protocol will handle multiple connections (open sockets) simultaneously  must be able to dispatch (demultiplex) incoming packets to correct upper layer connection (e.g., socket)  TCP uses local and remote IP address/port info to demultiplex Network layer may need to demultiplex upward to one of several possible transport protocols (e.g., UDP or TCP)

31. Internet transport layer case study: TCP and UDP UDP: datagram service  message-oriented, one time send preserves message boundaries  no reliability  no retransmission  error detection using Internet checksum over UDP packet and 3 IP header  fields (address and IP length)  no flow or congestion control  no ordering

32. UDP packet Layer source portdestination port UDP lengthUDP checksum data (up to 65K) 32 bits

33. UDP Implementation: Source Code linux implementation of UDP send side /* udp_send called from above, as result of sendto system call */ static int udp_send(struct sock *sk, struct sockaddr_in *sin, unsigned char *from, int len, int rt) { struct sk_buff *skb; struct device *dev; struct udphdr *uh; unsigned char *buff; unsigned long saddr; int size, tmp; int ttl;

34. /* Allocate an sk_buff copy of the packet. */ size = sk->prot->max_header + len; skb = sock_alloc_send_skb(sk, size, 0, &tmp); if (skb == NULL) return tmp; skb->sk = NULL; /* to avoid changing sk->saddr */ skb->free = 1; skb->localroute = sk- >localroute|(rt&MSG_DONTROUTE);

35. /*Now build the IP and MAC header. */ buff = skb->data; saddr = sk->saddr; dev = NULL; ttl = sk->ip_ttl; tmp = sk->prot->build_header(skb, saddr, sin->sin_addr.s_addr, &dev, IPPROTO_UDP, sk->opt, skb->mem_len,sk->ip_tos,ttl); skb->sk=sk; /* So memory is freed correctly */ /*Unable to put a header on the packet. */

36. if (tmp < 0 ) { sk->prot->wfree(sk, skb->mem_addr, skb- >mem_len); return(tmp); } buff += tmp; saddr = skb->saddr; /*dev->pa_addr;*/ skb->len = tmp + sizeof(struct udphdr) + len; /* len + UDP + IP + MAC */ skb->dev = dev;

37. /*Fill in the UDP header. */ uh = (struct udphdr *) buff; uh->len = htons(len + sizeof(struct udphdr)); uh->source = sk->dummy_th.source; uh->dest = sin->sin_port; buff = (unsigned char *) (uh + 1); /*Copy the user data. */ memcpy_fromfs(buff, from, len); /*Set up the UDP checksum. */ udp_send_check(uh, saddr, sin->sin_addr.s_addr, skb->len - tmp, sk);

38. /* Send the datagram to the interface. */ udp_statistics.UdpOutDatagrams++; sk->prot->queue_xmit(sk, dev, skb, 1); return(len); }

39. TCP: call setup and close Three-way handshake for connection setup Connection close: each TCP side must issue close to other

40. TCP Connection Close established close wait fin_wait_1 fin_wait_2 time_wait last_ACK CLOSED FIN ACK FIN ACK timeout after 2 segment lifetimes close() FIN close() FIN

41. TCP: Data Transfer Stream-oriented (byte stream with no message boundaries) Internet checksum as in UDP When to send in TCP?  RFC says "whenever"  flow and congestion control window restrict sending  what about interactive operations: character echoing in telnet  40 byte header + one byte payload?  Nagle's algorithm: with single character input, buffer characters until you get ACK for last batch of characters sent  fast uncongested network: overhead not a concern; slow network: buffer characters to save overhead

42. Receiver-wise TCP Data Concerns  cumulative ACKs a la GBN  RFC doesn't say when to ACK  out of order packet: TCP spec does not specify action  typically buffer and ACK last in-order packet  ACK may not be generated immediately  hope to piggyback on reverse direction data  hope 2nd packet arrives, ACK both at once

43. TCP: fast retransmit with cumulative ACK Fast retransmit: after receiving three ACK(N) while waiting for ACK(N+1)  retransmit N without waiting for timeout (N was likely lost)

44. Example:  fast retransmit of 3  cumulative ACK of 6  this implementation buffers pkts at rcvr

46. TCP packet format We've seen use of most of packet fields already: Fields we haven't seen:  length: length of header (variable, due to options)  URG: if set, urgent pointer points to "urgent" data  PSH: TCP should push this data to receiver ASAP. Seldom used or usable  options: can be used to carry timestamp, or maximum segment size info

47. TCP windows and timers RTT estimation based on measured ACK delays Retransmit timers  old algorithm: 2*RTT  new algorithm: RTT + 4*variation factor Window-based flow control  receiver advertises buffer space to sender Window-based congestion control:  slow start: ramp up cwd (window size) quickly to ssthresh  increase more slowly  halve cwd on loss detection

48. Real-Time Transport Protocols: Requirements  transport protocol must provide timing information  support for multicast  heterogeneity, scalability  feedback on quality of service  RTP: Real-Time Transport Protocol  RTCP: RTP Control Protocol

49. RTP: Real-Time Transport Protocol RFC 1889  product of IETF Audio Video Transport Working Group (AVT WG)  goals  lightweight, interoperability  mechanism - not policy  scalability - unicast, multipoint 2 - 1000s participants  separation of control/data

50. RTP: Real-Time Transport Protocol  best effort service  timing info. for playout  reordering information  loss detection for quality estimation, recovery  synchronization  network jitter  clock drift  intermedia (lip sync)  QoS feedback  source identification

51. RTCP: RTP Control Protocol  estimate no. participants  state of participants (talker indication)  QoS feedback - can be used to adjust sender rate  end-end loss rate  end-end delay jitter  scalability- randomized control traffic; rate decreases as number increases

52. End-End Aspects of ATM ATM adaptation layer (AAL) performs end- system functionality in ATM networks  different AAL's provide different services to upper layers  common functionality:  fragmentation and reassembly: breaking application-level data units into 48 byte chunks for ATM network layer  detection of errors, but not correction or recovery

53. AAL1:  for real-time, constant bit rate applications such as uncompressed audio, video  preserves timing on end-end-basis AAL2: non- functional AAL3/4 and AAL5:  data transport for error-sensitive, non-real-time data  message mode (preserves message boundaries) and stream mode

54. AAL5 Case study  looks a lot like UDP  will detect errors but not retransmit  packet format  data: up to 65K bytes per AAL5 message  UU: user-defined (upper layer) field unused by AAL. Possible uses are sequence numbers and/or multiplexing  length: length of data  CRC: cyclic redundancy check: stronger error detection than Internet checksum. Errors detected (signaled to upper layer) but not corrected

55. data upper layer(s) ATM layer data UU length CRC convergence sub-layer (data framing) segmentation and reassembly 1-65KB 1 1 2 4 …

56. Transport Layer: Summary Encountered many fundamental networking problems:  communication over an unreliable channel  flow control  congestion control  connection management  multiplexing/demultiplexing

57. The future: a critically important layer  requirements of new applications require new transport level mechanisms  why bundle a specific set of functionality into a monolithic protocol as in TCP  craft protocols from smaller building blocks  internetworking: when crossing many networks, lowest service level is minimal; rich transport-level functionality required