1 / 57

Connection Management: Choosing a Unique Identifier

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

gtammie
Télécharger la présentation

Connection Management: Choosing a Unique Identifier

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

  11. 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

  12. 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

  13. Connection Management • connection establishment • 2-way handshake with timer • 3-way handshake (TCP) • connection teardown

  14. 3-way handshake

  15. 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

  16. 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)

  17. 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)

  18. 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

  19. 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)?

  20. 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?

  21. 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

  22. 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

  23. 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

  24. 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

  25. 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!

  26. 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

  27. 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

  28. 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

  29. UDP packet Layer 32 bits source port destination port UDP length UDP checksum data (up to 65K)

  30. 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;

  31. /* 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);

  32. /*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. */

  33. 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;

  34. /*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);

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

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

  37. 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

  38. 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

  39. 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

  40. 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)

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

  42. 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

  43. 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

  44. 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

  45. 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

  46. 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

More Related