DOC PREVIEW
Stanford CS 144 - Lecture Notes

This preview shows page 1-2-3-23-24-25-26-47-48-49 out of 49 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 49 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 49 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 49 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 49 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 49 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 49 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 49 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 49 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 49 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 49 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 49 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Lecture 12: TCP Friendliness, DCCP, NATs,and STUNCongestion Control• TCP dynamically adapts its rate in response tocongestion• AIMD causes flows to converge to fair goodput• But how do losses (e.g., bit errors) affect goodput?• What about UDP?Chiu Jain Phase PlotsFlow A rate (bps)Flow B rate (bps)FairA=BEfficientA+B=Coverloadunderloadt1t2t3t4t5t6Responding to Loss• Set threshold tocwnd2• On timeout- Set cwnd to 1- Causes TCP to enter slow start• On triple duplicate ACK (Reno)- Set cwnd tocwnd2- Retransmit missing segment- Causes TCP to stay in congestion avoidanceAnalyzing TCP Simply• Assume all segments are MSS long• Assume a packet loss rate p• Assume a constant RTT• Assume p is small (no timeouts)Analysis• Window size W cuts toW2after a loss• Grows to W afterW2RTTs• Goodput =34· W · MT U ·1RT TWindow Size• p =1(W2+(W2+1)+...+W )• p ≈138W2• W ≈q83·p• Goodput =34·q83·p· MT U ·1RT T• Goodput =1.22·MT URT T ·√p• Constant factor changes based on delayed acks,etc.TCP Friendliness• Don’t want other protocols to disrupt TCP• UDP happily shuts down TCP flows• “TCP friendliness:” obeying TCP congestioncontrol as per prior goodput equation- Does not imply acting like TCP- E.g., does not require abrupt window changesledbat WG• “The LEDBAT WG is chartered to standardize acongestion control mechanism that should saturatethe bottleneck, maintain low delay, and yield tostandard TCP.”• TCP-friendliness is insufficient for modern P2Papplications- Flow fairness, not application fairness- TCP fills queues• Elastic workloads vs. inelastic workloadsDCCP• Datagram Congestion Control Protocol (DCCP)provides congestion control for unreliabledatagrams (RFC 4340)• Connection-oriented protocol- Request-response-ack establishment- Close-reset or CloseReq-Close-reset teardown• Counts packets, not bytesDCCP SegmentSequence Numbers• Every DCCP packet uses a new sequence number- Data- Acknowledgements- Control traffic• Acknowledgements are for last packet received- Not cumulative acknowledgements- Does not succinctly describe connection history- Options can give packet vectorsSynchronization• DCCP uses sequence number windows to protectfrom attacks• Large bursts of losses cause packets to fall pastwindows• Need to resynchronizeSynchronization ExchangeSynchronization on Reset ProblemSynchronization on Reset SolutionCongestion Control• Defines Congestion Control IDs (CCIDs)• Negotiated with change/confirm L/R options• Each half-connection can have differentcongestion control• CCID 2: TCP congestion control (AIMD) (RFC4941)• CCID 3: TCP-friendly congestion control (RFC4942)CCID 2• Uses TCP congestion control- Maintains a cwnd, slow-start, etc.• Adds congestion control to acks- Sender specifies an AckRatio, R- Ratio of data to ack packets (TCP with delayed ACKs is 2)- On detecting ack losses, double R- AftercwndR2−Rlossless congestion windows, decrement RCCID 3• Uses TCP-friendly congestion control• Uses a sending rate, rather than a congestionwindow• Receiver sends feedback once per RTT, reportingloss rate• If sender hears no feedback, halves sending rate• Security issue with loss rate reporting: report lossintervals, rather than just a loss rate, verifiablewith ECN noncesDCCP Today• Numerous implementations• IETF Standards Track• Well suited to VoIP, Internet Gaming, etc.• Sees very little use2-minute stretchNAT• Network Address TranslatorNAT(128.34.22.8)Client A(10.0.0.101)NAT(76.18.117.20)Client B(10.1.1.9)Session A-S10.0.0.101:123418.181.0.31:22Session B-S10.1.1.9:541118.181.0.31:22Server(18.181.0.31)Session B-S76.18.117.20:1000118.181.0.31:22Session A-S128.34.22.8:610118.181.0.31:22Motivations and Complications• There are only 232IP addresses• Firewalls for security• Breaks end-to-end (node does not know itsexternal IP)• Node might not even know if it’s behind a NAT• NAT needs to be able to dynamically assignmappingsHow a NAT Works• Maps between global and local (IP,port) pairs• Requires knowledge of transport packet format• UDP datagram, TCP SYN- Can shut down TCP mapping on FIN+ACK- UDP requires timeouts (> 2 minutes, unless IANA saysotherwise)• RFC 4787/BCP 127 defines recommendedbehaviorsNAT Example, Step 1NAT(128.34.22.8)Client A(10.1.1.18)Server(18.181.0.31)Client B(10.1.1.9)NAT Example, Step 2NAT(128.34.22.8)Client A(10.1.1.18)Server(18.181.0.31)Client B(10.1.1.9)10.1.1.1818.181.0.314512 80Client A tries to opena connection to Server port 80 from port 4512NAT Example, Step 3NAT(128.34.22.8)Client A(10.1.1.18)Server(18.181.0.31)Client B(10.1.1.9)NAT rewrites the sourceaddress and port so itseems it is the source128.34.22.818.181.0.316641 8010.1.1.1818.181.0.314512 80NAT Example, Step 4NAT(128.34.22.8)Client A(10.1.1.18)Server(18.181.0.31)Client B(10.1.1.9)NAT also creates a mappingso it can transform futurepackets correctly10.1.1.1818.181.0.314512128.34.22.8664180NAT Example, Step 5NAT(128.34.22.8)Client A(10.1.1.18)Server(18.181.0.31)Client B(10.1.1.9)Server responds to SYNwith SYN+ACK and NATrewrites it128.34.22.818.181.0.3166418010.1.1.1818.181.0.3145128010.1.1.1818.181.0.314512128.34.22.8664180NAT Example, Step 6NAT(128.34.22.8)Client A(10.1.1.18)Server(18.181.0.31)Client B(10.1.1.9)Client B can also opena connection, and the NATcreates a mapping for it too128.34.22.818.181.0.3140508010.1.1.1918.181.0.3199678010.1.1.1918.181.0.319967128.34.22.8405080NAT Example, Step 7Client A(10.1.1.18)Server(18.181.0.31)In the case of TCP, NATcan discard the mappingon close or RSTNAT(128.34.22.8)Client B(10.1.1.9)128.34.22.818.181.0.3166418010.1.1.1818.181.0.3145128010.1.1.1818.181.0.314512128.34.22.8664180RSTRSTTypes of NAT (RFC 3849)• Full Cone: no ingress filter (single local-externalmapping)• Restricted Cone: ingress filter on address• Port Restricted: ingress filter on address/port• Symmetric: different mappings for differentexternal destinations• Teminology is imperfect (static port mappings,etc.)NAT Problems• Incoming TCP connections• E.g., Skypeclientssupernodesbootstrapsuper nodecallrelayTCP Through NATs• Server socket doesn’t initiate traffic: NAT can’t setup mapping• Rendezvous servers (as in Skype)• Connection reversal through rendezvous if onlyone is behind a NAT (rendezvous server asksun-NAT node to open a port so NAT node canconnect)TCP ReversalMore NAT Problems• Port mapping: 0-1023 should map to 0-1023• Port parity:


View Full Document

Stanford CS 144 - Lecture Notes

Documents in this Course
IP Review

IP Review

22 pages

Load more
Download Lecture Notes
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture Notes and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture Notes 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?