1 / 20

Recovering Internet Symmetry in Distributed Computing

Recovering Internet Symmetry in Distributed Computing. Sechang Son, Miron Livny [sschang, miron]@cs.wisc.edu. Contents. Introduction Dynamic Port Forwarding Architecture Implementation Analysis Generic Connection Brokering Architecture Implementation Analysis Conclusion.

thalia
Télécharger la présentation

Recovering Internet Symmetry in Distributed Computing

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. Recovering Internet Symmetry in Distributed Computing Sechang Son, Miron Livny [sschang, miron]@cs.wisc.edu

  2. Contents • Introduction • Dynamic Port Forwarding • Architecture • Implementation • Analysis • Generic Connection Brokering • Architecture • Implementation • Analysis • Conclusion

  3. Fate of Private Network • Introduced as a short term solution to IPv4 address shortage problem until the full deployment of IPv6 • May be not disappeared • Easy network planning and maintenance • Cost nothing • Grid is a big supporter of private network

  4. B : A X B : X : A X : A NAT, Masquerading, and Port Forwarding Private network NAT A B B : X

  5. Condor/Grid Requirements • No change to public side: interoperable with (existing) regular sockets • Minimum changes to network components and no change to kernel or having system-wide impact • Easy deployment is one of key factor of Grid system • Highly scalable • Clusters with hundreds or thousands machines must be supported • High performance • Representative requirements of any Grid System

  6. Previous Works • Global Approaches • TRIAD, IPNL, AVES • Local/Fill-the-gap Approaches • Napster, Gnutella: Application specific connection brokering • SOCKS • Realm Specific IP (RSIP) • No system meets Grid requirements

  7. Central Manager X X X A Add DPF Server NAT Ack(X) A X ? X *:X:A C Dynamic Port Forwarding (DPF) Private network B

  8. Implementation of DPF • Client • molded into the communication library of Condor • Creates and deletes forwarding rule on the fly • Server • Uses NAT library to add/list/delete port forwarding rule • Maintains 3 different representations of forwarding rules for fault tolerance and updates/synchronizes those in a careful way • Periodically polls clients for garbage collection

  9. Analysis of DPF • Highly Interoperable • Highly scalable • The number of proxy addresses leased to clients is only limiting factor • DPF with multiple ip addresses is supported • Very deployable • No changes to OS, network component, or NAT required • DPF server runs as privileged user • Security • Opens holes under administrator’s permission and as long as necessary

  10. Analysis of DPF • Performance: Private-to-public

  11. Central Manager P P N A T P A Add Contact B P P ? P ? P Passive Active P GCB Server Generic Connection Brokering (GCB) Private network B

  12. ACK N A T Dummy A Contact B P ? P Passive GCB Server Generic Connection Brokering (GCB) Private network UDP UDP B

  13. A P GCB Server Generic Connection Brokering (GCB) Private network Regular socket B

  14. Active Proxy addr Real addr … Conn_Q Rcv_Buf … B C Data Implementation of GCB client socket bind accept connect … dup … fork execve fd = 0 fd = i fd = k socket bind accept connect … dup … fork execve

  15. Implementation of GCB server • Composed of Broker and RelayServer • Broker in charge of arranging the direction of connection • RelayServer creates proxy sockets and handles relay between two sockets • Broker forks new RelayServer on the fly • Stale status due to server crash or machine reboot is handled by reregistration

  16. Reliable UDP • Used for communication between clients and server • Reliable and in-order delivery • Simple congestion control • Connected and unconnected UDP • Time-wait state

  17. Analysis of GCB • Very interoperable • Public node needs to be a GCB client to get brokered • Regular sockets can talk to GCB nodes through relay service • Highly deployable • No changes to OS, network component, or NAT • No requirement for NAT and GCB server runs as a normal user • Very scalable • Logically as scalable as DPF, but performance can be a limiting factor • Security • Opens no hole • May increase the chance of misuse of organization’s policy

  18. Analysis of GCB • Performance: Private-to-public

  19. Firewall • Both firewalls and private networks damage Internet connectivity • Connections blocked • Firewall: intentional • Private network: side-effect • Condor’s mechanism to restrict the range of ports that sockets can bind to can be used with either DPF or GCB to support firewalls that block some outbound connections too

  20. Conclusion • DPF for dedicated and large cluster • GCB for medium and non-dedicated cluster

More Related