Internet DRAFT - draft-augustin-homenet-dncp-use-case
draft-augustin-homenet-dncp-use-case
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]
