Connection Management: Choosing a Unique Identifier

1. Connection Management: Choosinga 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., 232) 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) req_conn(x) conn x estab acc_conn(x) conn x estab send data(x+1) data(x+1) data(x+1) rcvd ACK(x+1) ack(x+1)

5. INACTIVE WAIT ACK ESTAB fromlayer3(acc_conn(x)) active open choose unique x tolayer3(req_conn(x)) timeout respondent tolayer3(req_conn(x)) initiator fromlayer3(req_conn(x)) tolayer3(acc_conn(x)) fromlayer3(acc_conn(y))

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

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

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 passive open accept() active open connect() syn(x) SYN recvd choose unique y synack(y,x+1) x+1 tells us there’s a live connection go to ESTAB y+1 tells us there’s a live client, goto ESTAB ack(x+1,y+1)

19. Handshaking Scenarios in TCP passive open accept() message old connection (no live client) syn(x) SYN recvd choose unique y synack(y,x+1) z+1 tells us this is NOTin response to y message! 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 • 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!

28. TCP Retransmit Timer: Jacobson’sAlgorithm 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| • timeout value = RTT + 4*D • M - measureded RTT

29. 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) Multiplexing and Addressing

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 32 bits source port destination port UDP length UDP checksum data (up to 65K)

33. UDP Implementation: Source Codelinux 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. established close wait fin_wait_1 fin_wait_2 time_wait last_ACK CLOSED close() FIN close() FIN TCP Connection Close FIN ACK ACK FIN ACK ACK timeout after 2 segment lifetimes

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