Homenet Working Group A. Augustin Internet-Draft Cisco Systems Intended status: Informational July 6, 2015 Expires: January 7, 2016 DNCP Use Case in a Distributed Cache System draft-augustin-homenet-dncp-use-case-00 Abstract In a distributed cache system, at some point the nodes need to share and synchronise some information. This document explains how this cache system works and shows how DNCP is useful in this situation. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 7, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Augustin Expires January 7, 2016 [Page 1] Internet-Draft DNCP Use Case July 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 2 3. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Interest of using DNCP . . . . . . . . . . . . . . . . . . . 4 5. DNCP Profile . . . . . . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction The cache system described in this document works under the assumption that each chunk of data that may be cached is uniquely associated to an IPv6 address. When a client desires to retrieve this chunk of data, it establishes a TCP connection towards the IPv6 address of the chunk. The system only relies only on the use of IPv6 and TCP, it is therefore independant of the application used on top of it (usually HTTP). This connection is routed through a proxy, which acts as an entry point in the cache system. The proxy inserts a Segment Routing Header in each packet which destination is the IPv6 address of a chunk, in order to have these packets sequentially routed through a certain number of cache servers. Cache servers intercept the packets to reply directly to clients if they have the requested chunk available locally (Segment Routing interception). 2. Terminology and Abbreviations The terminology and abbreviations used in this document are described in this section. o DNCP: The Distributed Node Consensus Protocol, as defined in [I-D.ietf-homenet-dncp] o SRH: IPv6 Segment Routing Header, defined in [I-D.previdi-6man-segment-routing-header] o SR List: The list of addresses included in a SRH specifying the different destinations a packet will go through before reaching its final destination. o Chunk: A blob of binary data, which is associated to a unique IPv6 address, and which a client may request. o Client: A host that requests a chunk by establishing a connection towards the associated IPv6 address. Augustin Expires January 7, 2016 [Page 2] Internet-Draft DNCP Use Case July 2015 o Proxy: A node that insert SRHs in the packets corresponding to client requests in order to have them routed to cache servers. o Cache server: A node that may have a certain number of chunks available. Upon receiving packets with a segment routing header, a cache server can either intercept the packets and reply directly if it has the requested chunk, or forward it to the next hop in the SRH. o Source server: A node that has a given list of chunks available. 3. Context The distributed cache system is composed of one or more proxies, cache servers, and source servers. When a client needs a chunk of data, it establishes a TCP connection towards the IPv6 address identifying the chunk. This TCP connection is routed through a proxy which allows to keep compatibility with existing clients. Depending on the content being requested, which is known by looking at the destination address of the packet, the proxy chooses a SR List. The SR List contains, in this order, the addresses of several cache servers, the address of a source server that has this content, and the address of the chunk. This SR List is converted to a SRH and inserted in the packet. No information is retained per connection, this operation is applied to each packet individually. The cache servers maintain a list of the chunks that they have cached and that are available locally. When receiving a packet, they look at the last address of the SRH. If the corresponding chunk is available, they intercept the packet and deliver it locally. If the chunk is not available, they forward it according to the SRH. This method ensures that the TCP connection is established with the first server in the SR List that has the requested chunk. Each cache server monitors the requests that it receives by counting the TCP SYN packets and looking at the last address in the SRH. It caches the most requested chunks by using a caching algorithm, such as Least Frequently Used or Least Recently Used. This implies that, in order to be efficient, a given proxy should always use the same SR List for a given chunk. From an other point of view, for a given SR List, the first server on the list caches as many chunks as possible among the most requested ones, the second server caches the most asked chunks that have not been cached by the first server, and so on. In order to minimize the distance that most requests cover in the network, proxies should Augustin Expires January 7, 2016 [Page 3] Internet-Draft DNCP Use Case July 2015 generate SR Lists that are dependant on the underlying topology: close servers should be put first in the SR List, then servers further away, and eventually a source server. Proxies should also balance the load between adjacent servers (clustering), stop using servers that are unavailable, and automatically start using new servers that become available. As the servers are passive, the efficiency of the system will be dependant on how smartly the proxies generate SR Lists. The exact logic of the proxy is out of scope of this document, but the proxies don't need a lot of information to generate good SR Lists. They can deduce many things from: o The list of proxies, cache servers and source servers that are available. o The distances between all servers in the system, which can be measured from several metrics (for instance the RTT). 4. Interest of using DNCP In this context, DNCP allows to extremely simply share the data needed (the list of nodes and the distances between them) across all nodes in the system, without reimplementing a full-fledged protocol. DNCP ensures that the data is synchronised between nodes and that data from unreachable nodes is removed. The distance is measured at startup and is not republished unless it changes significantly. Consequently, the data only changes when a server becomes available or unavailable, or when something changes in the underlying network. This should not happen too often, and so the DNCP Network State Hash should not change too often, which will limit DNCP excitation. Without DNCP, we would have needed to design a whole protocol with hello messages, keepalives, a flooding mechanism, and so on. DNCP manages all this automatically, all we had to do was to define which data had to be shared and adjust the profile for our needs (faster dead neighbor detection, unicast UDP, etc.). 5. DNCP Profile This section describes the particular DNCP Profile used by the nodes in this system. 5.1. DNCP Constants and parameters Augustin Expires January 7, 2016 [Page 4] Internet-Draft DNCP Use Case July 2015 o The unicast transport protocol is UDP, no multicast transport protocol is used. o The transport protocol is not secured. o The UDP port used is 16255. o Upon node identifier collision, both nodes will choose a new random node identifier. o Imin = 0.1s, Imax=20s, K=1 o The non cryptographic hash function used is MD5. o DNCP_NODE_IDENTIFIER_LENGTH = 4 o DNCP_GRACE_INTERVAL = 30s o Keepalives are enabled, DNCP_KEEPALIVE_INTERVAL = 5s, DNCP_KEEPALIVE_MULTIPLIER = 2.1 5.2. DCNP TLVs used 5.2.1. Server Announce TLV This TLV is published when a server is ready to join the system. It includes the node type: cache, source server or proxy; and the node's IPv6 addresses. 5.2.2. Server Distance TLV Whenever a node receives a new Server Announce TLV, it measures the distance to the new server (for instance by pinging it), and then publish a Server Distance TLV. This TLV includes the distance and the public IPv6 of the pinged server. 5.3. DNCP Setup Because this system is to be inserted in a ISP network, we do not assume that a multicast routing protocol is running. Because of this, we use only unicast communications. The system includes one or more nodes called "DNCP Relays" that have fixed addresses. Other nodes are configured with the addresses of these relays and contact them in unicast on startup. When they are ready, the nodes publish their Server Announce TLV, and start sending Server Distance TLVs for each Server Announce TLV they receive. Augustin Expires January 7, 2016 [Page 5] Internet-Draft DNCP Use Case July 2015 By extracting the data from DNCP, the proxies can get an idea of where each server is, and optimize the SR Lists they generate accordingly. Moreover, as they know that other proxies are using exactly the same data, they can know what their decisions will be and collaborate to a certain extent without exchanging additionnal data. 6. IANA Considerations This draft includes no requests to IANA. 7. Security Considerations No security considerations. 8. References 8.1. Normative References [I-D.ietf-homenet-dncp] Stenberg, M. and S. Barth, "Distributed Node Consensus Protocol", draft-ietf-homenet-dncp-05 (work in progress), June 2015. 8.2. Informative references [I-D.previdi-6man-segment-routing-header] Previdi, S., Filsfils, C., Field, B., and I. Leung, "IPv6 Segment Routing Header (SRH)", draft-previdi-6man-segment- routing-header-06 (work in progress), May 2015. Author's Address Aloys Augustin Cisco Systems Email: aloys.augustin@polytechnique.org Augustin Expires January 7, 2016 [Page 6]