oxide

19 bookmarks
Custom sorting
Network Design Considerations for Trading SystemsNetwork Design Considerations for Trading Systems - hotnets24-262.pdf
Network Design Considerations for Trading SystemsNetwork Design Considerations for Trading Systems - hotnets24-262.pdf

The quest to build scalable data center networks has driven much of the innovation in the networking community in recent decades. But the one-size-fits-all service model offered by these networks does not meet the needs of every application. In response, cloud providers have started to design custom clusters to support the specialized workloads used in finance, AI, high-performance computing, and other areas. This paper pulls back the curtain on one such area: the low-latency networks used for algorithmic trading systems. We present requirements and architectures, and discuss implementation approaches that make different trade-offs in terms of performance, hardware requirements, and ease of management. We identify concrete steps for making it easier to design low-latency networks in the future.

·conferences.sigcomm.org·
Network Design Considerations for Trading SystemsNetwork Design Considerations for Trading Systems - hotnets24-262.pdf
IGMP Basics
IGMP Basics
Internet Group Management Protocol (IGMP) used by a Host to notify the local Router that it wishes to receive (or stop receiving) multicast traffic for a given group address. Below diagram shows a …
·mrncciew.com·
IGMP Basics
RFC 3376: Internet Group Management Protocol, Version 3
RFC 3376: Internet Group Management Protocol, Version 3
This document specifies Version 3 of the Internet Group Management Protocol, IGMPv3. IGMP is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP adds support for 'source filtering', that is, the ability for a system to report interest in receiving packets *only* from specific source addresses, or from *all but* specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to networks where there are no interested receivers. This document obsoletes RFC 2236.
·datatracker.ietf.org·
RFC 3376: Internet Group Management Protocol, Version 3
How to Build an Exchange
How to Build an Exchange
UPDATE: We are full up. Tons of people signed up for the talk, and we’renow at the limit of what we feel like we can support in the space. Thanks forall the ...
·blog.janestreet.com·
How to Build an Exchange
RFC 4605: Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")
RFC 4605: Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")
In certain topologies, it is not necessary to run a multicast routing protocol. It is sufficient for a device to learn and proxy group membership information and simply forward multicast packets based upon that information. This document describes a mechanism for forwarding based solely upon Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) membership information. [STANDARDS-TRACK]
·datatracker.ietf.org·
RFC 4605: Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")
oxidecomputer/dendrite: The components needed to drive and manage the Oxide rack switch
oxidecomputer/dendrite: The components needed to drive and manage the Oxide rack switch
Dpd. This is the primary program that manages the underlying switch hardware. It is located in the dendrite code repository. It’s responsible for managing the switch ASIC and providing and API for other programs that want to add state to the ASIC such as routing table entries, ARP/NDP entries, etc.
·github.com·
oxidecomputer/dendrite: The components needed to drive and manage the Oxide rack switch
21 - User Networking API / RFD / Oxide
21 - User Networking API / RFD / Oxide
DNS for InstancesWhen an instance is created, it is automatically registered in Internal DNS. In this case, the primary IPv4 and IPv6 addresses are registered as A and AAAA records. Internal DNS exists on a per-VPC basis. Using the network’s DNS servers, an instance is always able to resolve any address on the VPC. If an instance is not on that VPC, it will not be able to resolve names outside of that VPC.When an Ephemeral IP address is assigned to an instance, then that instance will appear in external DNS. Names in external DNS are accessible outside of the Oxide environment by other applications. A DNS A record is created whenever an IPv4 Ephemeral IP address is assigned and a DNS AAAA record is assigned whenever an IPv6 Ephemeral IP address is assigned.Names in DNS follow the same structure, regardless of whether or not they are being used internally or externally. This structure is:..inst....<instance> refers to the DNS name of the instance<az> refers to the DNS name of the availability zone<vpc> refers to the DNS name of the VPC<project> refers to the DNS name of the project<org> refers to the DNS name of the organization<suffix> refers to the DNS suffix that is used. For internal DNS this is always .internal. For external DNS, this varies based on the installation.Let’s look at an example. Here are two names that refer to the same instance. One is in internal DNS and one is in external DNS:glorfindel.us-east-1.inst.gondolin.noldor.tolkien.internal glorfindel.us-east-1.inst.gondolin.noldor.tolkien.oxide.fingolfin.orgHere glorfindel is the DNS name of the instance. us-east-1 is the DNS name of the availability zone. gondolin is the DNS name of the VPC, noldor is the DNS name of the project, and tolkien is the DNS name of the organization. The first DNS host name is the name in internal DNS, which is why it has the .internal suffix. The second name is the one in external DNS and oxide.fingolfin.org is the suffix. The DNS suffix is specific to an installation.In all of the above objects, we explicitly said it was the DNS name. The DNS name is a separate name for each object that defaults to the object’s name. DNS has some additional constraints in terms of naming that aren’t always there for the main name attributes. In addition, it’s important that renaming something that users see and interact with on a regular basis doesn’t impact the names that machines are using unless intended.When two VPCs have been peered together, subnets that are shared will show up in DNS with the corresponding names that match that project.
·rfd.shared.oxide.computer·
21 - User Networking API / RFD / Oxide