![]() Executive
Summary: This white paper provides an update on
industry progress on NFV since we published our last review in October
2013.
Since its first meeting in January 2013, the ETSI NFV Industry Specification Group (NFV ISG) has grown to 235 companies, including 34 service provider organisations. The first outputs published in October 2013 which included an NFV Architectural Framework are being widely referenced across the industry to inform product development, standardisation, and new open source initiatives such as Open Platform for NFV (OPNFV). At the same time, the NFV ISG issued a call for Proof of Concept demonstrations (PoCs) to validate NFV assumptions and to encourage growth of an open ecosystem. To date, 25 PoCs are in progress or have been completed, spanning the breadth of NFV ISG scope with the results being openly available. In January 2015, the NFV ISG will publish a major release of documents that will be highly influential in setting the direction for NFV implementation and standardisation going forward. Drafts of these documents have been openly available on the NFV ISG portal since July. They have been brought to the attention of standards development organisations to help them frame their work to accommodate NFV concepts. In our original white paper we envisaged a two-year timeframe for the NFV ISG to complete its work. With the upcoming release of documents in January 2015, we are satisfied that the NFV ISG has achieved its goals. It has exceeded our expectations in both fostering an open ecosystem for the emerging technology of NFV, and in the degree of influence it has had on the wider industry, including standards development organisations and open source communities. It is also evident that vendor roadmaps have been dramatically influenced by this effort, which bodes well for the emergence of competitive solutions for NFV. The key challenge for growth of an open ecosystem is to achieve interoperability for the key interfaces identified in the NFV Architectural Framework. To ensure that momentum is not lost in achieving interoperability, we have encouraged the NFV ISG to work beyond its original two-year limit with a specific focus on addressing the barriers to interoperability. A second two-year phase of work will begin in February 2015. We also encouraged industry and academia to participate in the NFV ecosystem by creating research programmes around NFV and to create new teaching courses to train a new generation of students to be multi-skilled in networks and software. NFV will have a significant impact on the design of future telecommunications support systems. Using virtualisation in an up-to-date cloud environment will offer new self-managed redundancy and failover scenarios. The evolved management/support systems to handle this new environment must be highly automated, which requires new thinking on OSS/BSS that will open up opportunities to gain significant operational benefits. ![]() ![]() Differences between drafts: [ IETF document history ] Presentations: [ IETF-91 ] Abstract:
This document specifies the TCP Echo and TCP Echo Reply options.
It provides a single field a TCP sender can use to store any type of
data that a TCP receiver simply echo unmodified back. In contrast
to the original TCP Echo and TCP Echo Reply options defined in RFC 1072
the options specified in this document have slightly different semantics
and support a variable option length.
![]() ![]() ![]() ![]() Differences between drafts: [ IETF document history ] Presentations: [ IETF-91 ] Abstract:
This document specifies a TCP Option called EchoCookie. It provides a
single field that a TCP server can use to store opaque cookie data 'in
flight' rather than in memory. As new TCP options are defined, they can
require that implementations support the EchoCookie option. Then if a
server's SYN queue is under pressure from a SYN flooding attack, it can
ask clients to echo its connection state in their acknowledgement. This
facility is similar to the classic SYN Cookie, but it provides enough
space for connection state associated with TCP options. In contrast,
the classic location for a SYN Cookie only provides enough space for a
degraded encoding of the Maximum Segment Size (MSS) TCP option and no
others.
![]() Presentations: [ IETF-89 | IETF-88 ] Abstract: Data
Center TCP (DCTCP) is an ECN-based congestion control and AQM scheme.
It has provoked widespread interest because it keeps queuing delay and
delay variance very low. There is no theoretical reason why DCTCP
cannot scale to the size of the Internet, resulting in greater absolute
reductions in delay than achieved in data centres. However, no way has
yet been found for DCTCP traffic to coexist with conventional TCP
without being starved. This paper introduces a way to deploy DCTCP
incrementally on the public Internet that could solve this coexistence
problem. Using the widely deployed Weighted Random Early Detection
(WRED) scheme, we configure a second AQM that is applied solely to
ECN-capable packets. We focus solely on long-running flows, not because
they are realistic, but as the critical gating test for whether
starvation can occur. For the non-ECN traffic we use TCP New Reno;
again not to seek realism, but to check for safety against the
prevalent reference. We report the promising result that, not only does
the proposed AQM always avoid starvation, but it can also achieve equal
rates. We even derived how the sharing ratio between DCTCP and
conventional TCP traffic depends on the various AQM parameters. The
next step beyond this gating test will be to quantify the reduction in
queuing delay and variance in dynamic scenarios. This will support the
standardization process needed to define new ECN semantics for DCTCP
deployment that the authors have started at the IETF.
![]() Presentations: [ IAB SEMI 2105 ] Abstract: It is common but perhaps misguided to provide extensibility for a layer X header in the layer X header.
Strawman principle: For instance, extensions to the IP header should not be located in a chain of extensions to the IP header; they should be in an area of the payload that IP encapsulates (e.g. where you would expect UDP or TCP or an IPv6 destination option). Similarly, extensions to TCP should not be located in the TCP Options within the TCP header, they should be located within the TCP Data (i.e. in the space encapsulated by TCP that is intended for the app-layer). I'm not yet even convinced myself that this approach warrants promotion to the status of a principle. In the four examples this paper explores, it happened to be possible to make the approach work with some ingenious hackery, but it would not be easy in general. Therefore the message cannot be that existing protocols should be extended like this (because they were not designed to be extended in this way, so it will not always possible). The message is that we can at least try. And, in future, protocols would be more extensible in a middlebox world if they were designed so that they could be extended within their own encapsulation. ![]() ![]() ![]() ![]() Differences between drafts: [ IETF document history ] Presentations: [ ] Abstract: This
document describes an experimental redesign of TCP's extensibility
mechanism. It aims to traverse most known middleboxes including
connection splitters, by making it possible to tunnel all TCP options
within the TCP Data. It provides a choice between in-order and
out-of-order delivery for TCP options. In-order delivery is a useful
new facility for options that control datastream processing.
Out-of-order delivery has been the norm for TCP options until now, and
is necessary for options involved with acknowledging data, otherwise
flow control can deadlock. TCP's original design limits TCP option
space to 40B. In the new design there is no such arbitrary limit, other
than the maximum size of a segment. The TCP client can immediately
start to use the extra option space optimistically from the very first
SYN segment, by using a dual handshake. The dual handshake is designed
to prevent a legacy server from getting confused and sending the
control options to the application as user-data. The dual handshake is
only one strategy - a single handshake will usually suffice once
deployment is underway. In summary, the protocol should allow new TCP
options to be introduced i) with minimal middlebox traversal problems;
ii) with incremental deployment from legacy servers; iii) with zero
handshaking delay iv) with a choice of in-order and out-of-order
delivery v) without arbitrary limits on available space.
![]() ![]() ![]() ![]() Differences between drafts: [ IETF document history | history of predecessor (syn-op-sis) ] Presentations: [ TCPM IETF-91 | TCPINC IETF-91 ] Abstract:
This document describes an experimental method to extend the limited
space for control options in every segment of a TCP
connection. It can use a dual handshake so that, from the
very first SYN segment, extra option space can immediately start to be
used optimistically. At the same time a dual handshake prevents a
legacy server from getting confused and sending the control options to
the application as user-data. The dual handshake is only one
strategy - a single handshake will usually suffice once deployment has
got started. The protocol is designed to traverse most known
middleboxes including connection splitters, because it sits wholly
within the TCP Data. It also provides reliable ordered
delivery for control options. Therefore, it should allow new TCP
options to be introduced i) with minimal middlebox traversal problems;
ii) with incremental deployment from legacy servers; iii) without an
extra round of handshaking delay iv) without having to provide its own
loss recovery and ordering mechanism and v) without arbitrary limits on
available space.
![]() Differences between drafts: [ IETF document history ] Presentations: [ IETF-90 ] Abstract:
This document describes an experimental method to extend the option
space for connection parameters within the initial TCP SYN segment,
at the start of a TCP connection. This method effectively extends
the option space of an initial SYN by using an additional coupled
segment. It complements the proposed Extended Data Offset (EDO)
option that is applicable only after the initial segment.
![]() ![]() Differences between drafts: [ IETF document history ] Presentations: [ IETF-101 | IETF-100 | IETF-99 | IETF-94 | IRTF Jul'14 | IETF-90 ] Abstract:
Explicit Congestion Notification (ECN) is a mechanism where network
nodes can mark IP packets instead of dropping them to indicate incipient
congestion to the end-points. Receivers with an ECN-capable
transport protocol feed back this information to the sender. ECN is
specified for TCP in such a way that only one feedback signal can be
transmitted per Round-Trip Time (RTT). Recently, new TCP
mechanisms like Congestion Exposure (ConEx) or Data Center TCP (DCTCP)
need more accurate ECN feedback information whenever more than one
marking is received in one RTT. This document specifies an
experimental scheme to provide more than one feedback signal per RTT in
the TCP header. Given TCP header space is scarce, it overloads the
three existing ECN-related flags in the TCP header and provides
additional information in a new TCP option.
![]() Differences between drafts: [ IETF document history ] Presentations: [ IETF-89 ] Abstract:
Explicit
Congestion Notification (ECN) is a mechanism where network nodes can
mark IP packets, instead of dropping them, to indicate congestion to the
endpoints. An ECN-capable receiver will feed this information
back to the sender. ECN is specified for TCP in such a way that it
can only feed back one congestion signal per Round-Trip Time
(RTT). In contrast, ECN for other transport protocols, such as
RTP/UDP and SCTP, is specified with more accurate ECN feedback. Recent
new TCP mechanisms (like Congestion Exposure (ConEx) or Data Center TCP
(DCTCP)) need more accurate ECN feedback in the case where more than one
marking is received in one RTT. This document specifies
requirements for an update to the TCP protocol to provide more accurate
ECN feedback.
![]()
Abstract:
The present document aims to: • To identify potential security vulnerabilities of NFV and to determine whether they are new problems, or just existing problems in different guises. • To provide a reference framework within which these vulnerabilities can be defined. Out of scope: To list vulnerabilities that NFV suffers from that are no different from pre-existing vulnerabilities of networking and virtualisation technologies and are not altered by the virtualisation of network functions. Intended audience: Security experts wanting to deploy NFV but needing to identify and solve potential security issues and then to attain security accreditation for systems. Ultimate goal of the NFV Security Expert Group: Identify and propose solutions to any new vulnerabilities that result from the introduction of NFV. To enable checks for these vulnerabilities to be incorporated into processes for security accreditation of products based on NFV. ![]() Workshop: description and materials Abstract:
This paper reports on a workshop convened to develop an action
plan to reduce Internet latency. Internet latency has become a focus of
attention at the leading
edge of the industry as the desire to make Internet applications
more responsive outgrows the ability of increased bandwidth to
address this problem. There are fundamental limits to the extent
to which latency can be reduced, but there is considerable capacity for
improvement throughout the system, making Internet latency a
multifaceted challenge. Perhaps the greatest challenge of
all is to re-educate the mainstream of the industry to understand
that bandwidth is not the panacea, and other optimizations, such
as reducing packet loss, are at odds with latency reduction.
![]() Abstract:
<Identical text to the ACM CCR article above>
![]() Presentations: [ IRTF-Jul'14 ] Abstract:
Latency is increasingly becoming a performance bottleneck for
Internet Protocol (IP) networks, but historically networks have been
designed with aims of
maximizing throughput and utilization.
This article offers a broad survey of techniques aimed at tackling
latency in the literature up to March 2014 and their merits.
A goal of this work is to be
able to quantify and compare the merits of the different
Internet
latency reducing techniques,
contrasting their gains
in delay reduction versus the pain required to
implement and deploy them. We
found that classifying techniques according to the sources
of delay they alleviate provided the best insight into the
following issues: 1) the structural arrangement of a network, such as
placement of
servers and suboptimal routes, can contribute significantly to
latency; 2) each interaction between communicating endpoints adds a
Round
Trip Time (RTT) to latency, especially significant for short flows; 3)
in addition to base propagation delay, several sources of delay
accumulate along transmission
paths, today intermittently dominated by queuing delays; 4) it takes
time to sense and use available capacity, with overuse
inflicting latency on other flows sharing the capacity; and 5) within
end systems delay sources include operating system buffering,
head-of-line
blocking, and hardware interaction.
No single source of delay dominates in all cases, and
many of these sources are spasmodic and highly
variable. Solutions addressing these sources often both reduce the
overall
latency and make it more predictable.
Index Terms: Data communication, networks, Internet, performance, protocols, algorithms, standards, cross-layer, comparative evaluation, taxonomy, congestion control, latency, queuing delay, bufferbloat ![]() Abstract: This paper is a digest of [1], an extensive survey discussing the merits of over 300 techniques for reducing Internet latency. It gives a broad overview of the causes, solutions, and trade-offs involved in reducing latency in the Internet. The overview covers key sources of delays and proposed solutions: due to the structural arrangement of the network, how network end-points interact, along the end-to-end path, related to link capacities, within end-hosts, and those that address multiple sources. Trade-offs are discussed in terms of the latency reduction different techniques provide versus their deployability. ![]() Presentations: [ Latency Workshop Sep'13 ] Abstract:
Our working assumptions are that i) the performance of data
communications is increasingly held back by limits other than bandwidth
and ii) removing these limits will often involve simple inexpensive
changes to protocols and code. If true, removing these limits would be
a more effective use of time and resources than expensive link hardware
upgrades. Indeed, upgrading link speeds would waste investment if it
made little difference to performance because the limits were elsewhere.
This position paper gives a status report on work we have recently started to survey techniques for reducing the delays in communications. The immediate aim is to organise all the techniques into a meaningful categorisation scheme, then to quantify the benefit of each approach and produce visualisations that highlight those approaches that are likely to be most fruitful. ![]() ![]() ![]() ![]() Differences between drafts: [ IETF document history ] Presentations: [ IETF-87 | IETF-84 | IETF-83 ] Abstract: This
document describes why policing using congestion information can
isolate users from network performance degradation due to each
other's usage, but without losing the multiplexing benefits of a LAN-
style network where anyone can use any amount of any resource.
Extensive numerical examples and diagrams are given. The document is
agnostic to how the congestion information reaches the policer. The
congestion exposure (ConEx) protocol is recommended, but other tunnel
feedback mechanisms have been proposed.
![]() ![]() ![]() ![]() Differences between drafts: [ IETF document history ] Presentations: [ IRTF Jul'14 | IETF-87 | IETF-84 | IETF-83 ] Abstract: This
document describes how a multi-tenant (or multi-department) data
centre operator can isolate tenants from network performance
degradation due to each other's usage, but without losing the
multiplexing benefits of a LAN-style network where anyone can use any
amount of any resource. Zero per-tenant configuration and no
implementation change is required on network equipment. Instead the
solution is implemented with a simple change to the hypervisor (or
container) beneath the tenant's virtual machines on every physical
server connected to the network. These collectively enforce a very
simple distributed contract - a single network allowance that each
tenant can allocate among their virtual machines, even if distributed
around the network. The solution uses layer-3 switches that support
explicit congestion notification (ECN). It is best if the sending
operating system supports congestion exposure (ConEx). Nonetheless,
the operator can unilaterally deploy a complete solution while
operating systems are being incrementally upgraded to support ConEx
and ECN.
![]() Workshop: description and materials Presentations: [ ISOC Oct'11 ] Abstract:
At the macro scale there is a good story to tell about new fiber
deployments, and more open and competitive cable consortia. However,
dark fiber availability is a local concern for some as fiber
infrastructure operators seek to provide higher margin services.
Content Delivery Networks are part of a larger architectural shift toward localized content delivery and content aggregation services. This shift yields benefits for network users in terms of quality of experience. Content aggregators are helping to meet the growing demand for Internet content but there still remain huge spikes in traffic related to new releases of software and other kinds of popular content that are creating new challenges for network capacity planners and performance engineers. Latency management is the key to understanding the causes and solutions to many of the performance problems witnessed on today’s broadband access networks. There are opportunities for development and research stemming from this fact in terms of new algorithms, an improved access network router ecosystem and greater consumer and network operator awareness of the long-term costs of poor engineering and cheap products in this critical region of the end-to-end network path. ![]() ![]() Differences between drafts: [ ] Presentations: [ IETF-86 ] Abstract: This
document proposes an update to the advice given in RFC 3819.
Subsequent research has altered understanding of buffer sizing and
queue management. Therefore this document significantly revises the
previous recommendations on buffering. The advice applies to all
packet buffers, whether in network equipment, end hosts or
middleboxes such as firewalls or NATs. And the advice applies to
packet buffers at any layer: whether subnet, IP, transport or
application.
![]() ![]() Differences between drafts: [ IETF document history ] Presentations: [ IETF-85 | IETF-84 ] Abstract:
Pseudowires (PWs) have become a common mechanism for tunneling traffic
and may be found in unmanaged scenarios competing for network resources
both with other PWs and with non-PW traffic, such as TCP/IP flows.
Thus, it is worthwhile specifying under what conditions such
competition is acceptable, i.e., the PW traffic does not significantly
harm other traffic or contribute more than it should to
congestion. We conclude that PWs transporting responsive traffic
behave as desired without the need for additional mechanisms. For
inelastic PWs (such as Time Division Multiplexing (TDM) PWs), we derive a
bound under which such PWs consume no more network capacity than a TCP
flow. For TDM PWs, we find that the level of congestion at which
the PW can no longer deliver acceptable TDM service is never
significantly greater, and is typically much lower, than this bound.
Therefore, as long as the PW is shut down when it can no longer deliver
acceptable TDM service, it will never do significantly more harm than
even a single TCP flow. If the TDM service does not automatically
shut down, a mechanism to block persistently unacceptable TDM
pseudowires is required.
![]() Abstract:
A virtual queue can be used to predict when a real queue is about to
grow. This memo explains why using a leaky bucket to implement a
virtual queue is not useful, despite a superficial similarity. However,
it is possible to implement a useful virtual queue using two leaky buckets.
It requires a simple trick that can typically be implemented with
existing hardware.
![]() Abstract:
Admission control is a well known technique to explicitly admit or
block new flows for a domain to keep its traffic load at a moderate
level and to guarantee quality of service (QoS) for admitted flows.
Flow termination is a new flow control function that terminates some
admitted flows when the network capacity does not suffice, e.g., in
case of unexpected failures. Admission control and flow termination are
useful to protect QoS for inelastic flows that require a minimum
bitrate. Examples are real-time applications like voice and video.
Pre-congestion notification (PCN) provides for Differentiated Services
IP networks feedback about their load conditions to their boundary
nodes. This information is used to implement lightweight admission
control and flow termination without per-flow states in interior nodes
of a domain. Hence, these mechanisms are significantly simpler than
explicit reservation schemes. We explain the conceptual idea of
PCN-based admission control and flow termination, present recent IETF
standards, and discuss benefits, limitations, and application scenarios.
![]() ![]() ![]() ![]() Differences between drafts: [ IETF document history ] Presentations: [ IETF-83 | IETF-82 ] Abstract:
This
document gives examples of how ConEx deployment might get
started, focusing on unilateral deployment by a single network.
![]() ![]() Differences between drafts: [ IETF document history ] Presentations: [ IETF-80 ] Abstract:
This specification takes a new approach to
extensibility that is both
principled and a hack. It builds on recent moves to formalise the
increasingly common practice where fragmentation in IPv4 more closely
matches that of IPv6. The large majority of IPv4 packets are now
'atomic', meaning indivisible. In such packets, the 16 bits of the IPv4
Identification (IPv4 ID) field are redundant and could be freed up for
the Internet community to put to other uses, at least within the
constraints imposed by their original use for reassembly. This
specification defines the process for redefining the semantics of these
bits. It uses the previously reserved control flag in the IPv4 header
to indicate that these 16 bits have new semantics. Great care is taken
throughout to ease incremental deployment, even in the presence of
middleboxes that incorrectly discard or normalise packets that have the
reserved control flag set.
![]() ![]() Differences between drafts: [ IETF document history | briscoe-03-02 ] Presentations: [ IETF-101 | IETF-99 | IETF-96-tsvwg | IETF-96-intarea | IETF-95 | IETF-94 | IETF-92 | IETF-89 | IETF-88 | IETF-86 | IETF-85 | IETF-80 ] Abstract: The purpose of
this document is to guide the design of congestion notification in any
lower layer or tunnelling protocol that encapsulates IP. The aim is for
explicit congestion signals to propagate consistently from lower layer
protocols into IP. Then the IP internetwork layer can act as a
portability layer to carry congestion notification from non-IP-aware
congested nodes up to the transport layer (L4). Following these
guidelines should assure interworking between new lower layer congestion
notification mechanisms, whether specified by the IETF or other
standards bodies.
![]() Presentations: [ IRTF ICCRG Apr'11 | PFLDNeT'10] Abstract:
We present lessons from implementing a bandwidth
probing scheme termed
chirping as part of congestion control in the Linux kernel. Chirping
was first introduced for bandwidth estimation in the pathChirp tool. A
chirp is a group of several packets that are sent with decreasing
inter-packet gaps in order to continuously probe for spare bandwidth.
Current congestion control schemes are either slow to find new
bandwidth or they overshoot due to lack of fast feedback information.
The attraction of using chirping as a building block for congestion
control is to be able to non-intrusively probe for available capacity
in a very short time.
But implementing chirping is challenging because it requires an exact timing of every packet which is very different to the traditional approach in the network stack. As there are changes needed at the receiver as well, we also discuss a potential approach for deployment. Success in detecting fast feedback information using chirping opens the possibility of future work on new congestion control designs that should be more responsive with less overshoot. ![]() Differences between drafts: [ IETF document history | ietf00-mathis00 ] Presentations: [ IETF-87 | IETF-80 | IETF-79 ] Abstract:
This
document describes an abstract mechanism by which senders inform
the network about the congestion encountered by packets earlier in
the same flow. Today, network elements at any layer may signal
congestion to the receiver by dropping packets or by Explicit Congestion Notification (ECN) markings,
and the receiver passes this information back to the sender in
transport-layer feedback. The mechanism described here enables the
sender to also relay this congestion information back into the
network in-band at the IP layer, such that the total amount of
congestion from all elements on the path is revealed to all IP
elements along the path, where it could, for example, be used to
provide input to traffic management. This mechanism is called
congestion exposure or ConEx. The companion document "ConEx Concepts
and Use Cases" (RFC6679) provides the entry-point to the set of ConEx
documentation.
![]() Differences between drafts: [ IETF document history | moncaster02-01 | 01-00 ] Presentations: [ IETF-81| IETF-80 | IETF-79 | IETF-78 ] Abstract: This
document provides the entry point to the set of documentation about the
Congestion Exposure (ConEx) protocol. It explains the
motivation
for including a ConEx marking at the IP layer: to expose information
about congestion to network nodes. Although such information
may
have a number of uses, this document focuses on how the information
communicated by the ConEx marking can serve as the basis for
significantly more efficient and effective traffic management than what
exists on the Internet today.
![]() ![]() Differences between drafts: [ IETF document history ] Presentations: [ ] Abstract:
Deploying
new transport protocols on the Internet is a well-known problem, as
NATs and firewall drop packets with e.g. new protocol types or
unidentified TCP options. Tunnelling over UDP is one way to make IP
packets hide the actual payload and enable end-to-end
delivery. This document proposes a simple UDP tunnelling
encapsulation and end-host operation to enable new (and old) IP
payloads, e.g., new transport protocols, to be deployed on the Internet.
![]() ![]() Presentations: [ Slides in IETF Proceedings of ConEx BoF (Nov'09) ] Abstract:
Today's
Internet is a product of its history. TCP is the
main transport protocol responsible for sharing out bandwidth
and
preventing a recurrence of congestion collapse while packet drop is the
primary signal of congestion at bottlenecks. Since packet
drop
(and increased delay) impacts all their customers negatively,
networkoperators would like to be able to distinguish between overly
aggressive congestion control and a confluence of many low-bandwidth,
low-impact flows. But they are unable to see the actual
congestion signal and thus, they have to implement bandwidth and/or
usage limits based on the only information they can see or measure (the
contents of the packet headers and the rate of the traffic).
Such measures don't solve the packet-drop problems effectively and are
leading to calls for government regulation (which also won't solve the
problem).
We propose congestion exposure as a possible solution. This allows packets to carry an accurate prediction of the congestion they expect to cause downstream thus allowing it to be visible to ISPs and network operators. This memo sets out the motivations for congestion exposure and introduces a strawman protocol designed to achieve congestion exposure. Architecting the Future Internet; Re-Capturing the Internet Value Chain, Andrea Soppera, Toby Moncaster, Bob Briscoe (BT), Institute of Telecommunications Professionals (ITP) Journal (May 2009). (7pp, 4 figs, 9 refs) [BibTeX] Abstract: Many
people believe the Internet is perfect and are amazed to find
researchers working on the so-called Future Internet. However, what
these researchers realise is that users and application writers are
locked in an endless battle over the allocation of resources in the
network. Often they don’t even know they are fighting this
battle
– users simply want the fastest service they can get and application
writers have responded. Many ISPs seek to control the resulting
Internet congestion by imposing volume caps or rate limiting certain
types of traffic at peak times. These are only palliative measures that
lead to a breakdown in trust between users and their ISPs and limit the
space for innovation in the network. Our strategic innovation is based
on providing better visibility of the underlying congestion in the
network, with separation of accounting mechanisms and resource control.
Within the IETF we are pushing for “Re-Feedback”; a small modification
to TCP-IP to reveal the Internet’s congestion to all users. Our aim is
an economic incentive framework that incentivises the various players
to design efficient resource control mechanisms to maximize the value
of the Internet, thus ensuring a sustainable evolution towards the
Future Internet.
![]() Abstract:
Pre-congestion
notification (PCN) provides feedback about load conditions in a network
to its boundary nodes. The PCN working group of the IETF discusses the
use of PCN to implement admission control (AC) and flow termination
(FT) for prioritized realtime traffic in a DiffServ domain. Admission
control (AC) is a well-known flow control function that blocks
admission requests of new flows when they need to be carried over a
link whose admitted PCN rate already exceeds an admissible rate. Flow
termination (FT) is a new flow control function that terminates already
some admitted flows when they are carried over a link whose admitted
PCN rate exceeds a supportable rate. The latter condition can occur in
spite of AC, e.g., when traffic is rerouted due to network failures.
This survey gives an introduction to PCN in an early stage of the standardization process. It presents and discusses the multitude of architectural design options for PCN in a comprehensive and streamlined way before only a subset of them is standardized by the IETF. It brings PCN from the IETF to the research community and serves as historical record. Practical Microeconomics and Internet Resource Sharing Protocols, Bob Briscoe (BT & UCL), Recording of a lecture given for the Trilogy Future Internet summer school, at Université catholique de Louvain, Louvain-la-Neuve, Belgium (1hr 32min 35s + 1hr 33min 31s) (Sep 2009) Presentation [.ppt|.pdf] Multimedia sources [ Trilogy summer school ]
![]() Abstract:
This
dissertation concerns
adding resource accountability to a simplex internetwork such as the
Internet, with only necessary but sufficient constraint on freedom.
That is, both freedom for applications to evolve new innovative
behaviours while still responding responsibly to congestion; and
freedom for network providers to structure their pricing in any way,
including flat pricing.
The big idea on which the research is built is a novel feedback arrangement termed `re-feedback'. A general form is defined, as well as a specific proposal (re-ECN) to alter the Internet protocol so that self-contained datagrams carry a metric of expected downstream congestion. Congestion is chosen because of its central economic role as the marginal cost of network usage. The aim is to ensure Internet resource allocation can be controlled either by local policies or by market selection (or indeed local lack of any control). The current Internet architecture is designed to only reveal path congestion to end-points, not networks. The collective actions of self-interested consumers and providers should drive Internet resource allocations towards maximisation of total social welfare. But without visibility of a cost-metric, network operators are violating the architecture to improve their customer's experience. The resulting fight against the architecture is destroying the Internet's simplicity and ability to evolve. Although accountability with freedom is the goal, the focus is the congestion metric, and whether an incentive system is possible that assures its integrity as it is passed between parties around the system, despite proposed attacks motivated by self-interest and malice. This dissertation defines the protocol and canonical examples of accountability mechanisms. Designs are all derived from carefully motivated principles. The resulting system is evaluated by analysis and simulation against the constraints and principles originally set. The mechanisms are proven to be agnostic to specific transport behaviours, but they could not be made flow-ID-oblivious. ![]() Workshop: description and materials Abstract:
This
article summarises
the presentations and discussions during a workshop on end-to-end
protocols for the future Internet in June 2008. The aim of the workshop
was to establish a dialogue at the interface between two otherwise
fairly distinct communities working on future Internet protocols: those
developing internetworking functions and those developing end-to-end
transport protocols. The discussion established near-consensus on some
of the open issues, such as the preferred placement of traffic
engineering functionality, whereas other questions remained
controversial. New research agenda items were also identified.
![]() Abstract:
The purpose of this document is to provide a first account of the
discussions within the EIFFEL think tank, set within the context of
broad commercial, regulatory and academic concerns about the nature of
and process of arriving at the Future Internet. It is, therefore,
divided into three parts: technology, business and society.
The report is addressed both to the EIFFEL membership and more widely to members of the community interested in networking developments in the medium to long term. Whilst the report is not intended as a verbatim account of any specific Think Tank meeting, it is founded on the discussions that were held within the first two meetings. The overall aim of the report is to stimulate focussed debate on desirable research and regulatory goals, actions to be taken in reaching them, and potential barriers to their realisation. ![]() Abstract:
The
Internet is founded on a very simple premise: shared communications
links are
more efficient than dedicated channels that lie idle much of the time.
We share
local area networks at work and neighbourhood links from home. Indeed,
a multi-gigabit
backbone cable is shared among thousands of folks surfing the Web,
downloading
videos, and talking on Internet phones. But
there’s a
profound flaw in the protocol that governs how people share the
Internet’s
capacity. The protocol allows you to seem to be
polite, even as
you take
far more resources than others.
Network providers like Verizon or BT either throw capacity at the problem or patch over it with homebrewed attempts to penalize so-called bandwidth hogs or the software they tend to use. From the start it needs to be crystal clear that those with an appetite for huge volumes of data are not the problem. There is no need to stop them downloading vast amounts of material, if they can do so without starving others. But no network provider can solve this on their own. At the Internet standards body, work has started on fixing the deeply entrenched underlying problem. A leading proposal claims to have found a way to deploy a tweak to the Internet protocol itself—the Internet’s ‘genetic material’. The intent is to encourage a profound shift in the incentives that drive capacity sharing. The following 6pp article for IEEE Spectrum magazine is adapted for an engineering audience from the above 7pp white paper—it has some of the economic motivation and figures edited out. ![]() Abstract:
The Internet is founded on a very simple
premise: shared communications links are more efficient than dedicated
channels that lie idle much of the time. ¶ And so we
share. We
share local area networks at work and neighborhood links from home. And
then we share again—at any given time, a terabit backbone cable is
shared among thousands of folks surfing the Web, downloading videos,
and talking on Internet phones. ¶ But
there’s a
profound flaw in the protocol that governs how people share the
Internet’s capacity. The protocol allows you to seem to be polite, even
as you elbow others aside, taking far more resources than they do. ¶
Network providers like Verizon and BT either throw capacity at the
problem or improvise formulas that attempt to penalize so-called
bandwidth hogs. Let me speak up for this much-maligned beast right
away: bandwidth hogs are not the problem. There is no need to prevent
customers from downloading huge amounts of material, so long as they
aren’t starving others. ¶
Rather than patching over the problem, my
colleagues
and I at BT
(formerly British Telecom) have worked out how to fix the root cause:
the Internet’s sharing protocol itself. It turns out that this solution
will make the Internet not just simpler but much faster too.
![]() Presentations: [ Freiburg'08 | links to all seminar slides (Deutsch | English) ] Abstract:
(see
the
IEEE Spectrum
article above—a variant of the same article, but with more figures and
covering network interconnection in addition).
![]() Differences between drafts: [ IETF document history ] Presentations: [ IETF80 | IETF77 ] Abstract:
The objective of Pre-Congestion Notification (PCN) is to protect the
quality of service (QoS) of inelastic flows within a Diffserv domain.
On every link in the PCN domain, the overall rate of the PCN-traffic is
metered, and PCN-packets are appropriately marked when certain
configured rates are exceeded. Egress nodes provide decision
points with information about the PCN-marks of PCN-packets which allows
them to take decisions about whether to admit or block a new flow
request, and to terminate some already admitted flows during serious
pre-congestion.
The PCN Working Group explored a number of approaches for encoding this pre-congestion information into the IP header. This document provides details of all those approaches along with an explanation of the constraints that had to be met by any solution. ![]() Differences between drafts: [ IETF document history ] Presentations: [ IETF83 | IETF81 | IETF80 | IETF-73 ] Abstract:
The objective of Pre-Congestion Notification
(PCN) is to protect
the quality of service (QoS) of inelastic flows within a Diffserv
domain. On every link in the PCN domain, the overall rate of the
PCN-traffic is metered, and PCN-packets are appropriately marked when
certain configured rates are exceeded. Egress nodes provide
decision points with information about the PCN-marks of PCN-packets
which allows them to take decisions about whether to admit or block a
new flow request, and to terminate some already admitted flows during
serious pre- congestion.
This document specifies how PCN-marks are to be encoded into the IP header by re-using the Explicit Congestion Notification (ECN) codepoints within a PCN-domain. This encoding builds on the baseline encoding of RFC5696 and provides for three different PCN marking states using a single DSCP: not-marked (NM), threshold-marked (ThM) and excess-traffic-marked (ETM). Hence, it is called the 3-in-1 PCN encoding. ![]() Presentations: [ ReArch'08 | NGN Interconnection Strategies'08 ] Abstract:
Ideally,
everyone
should be free to use as much of
the Internet
resource pool as they can take. But, whenever too much load meets too
little capacity, everyone's freedoms collide. We show that attempts to
isolate users from each other have corrosive side-effects -
discouraging mutually beneficial ways of sharing the resource pool and
harming the Internet's evolvability. We describe an unusual form of
traffic policing which only pushes back against those who use their
freedom to limit the freedom of others. This offers a vision of how
much better the Internet could be. But there are subtle aspects missing
from the current Internet architecture that prevent this form of
policing being deployed. This paper aims to shift the research agenda
onto those issues, and away from earlier attempts to isolate users from
each other.
![]() ![]() Differences between drafts: [ IETF document history ] Abstract:
Pre-congestion notification (PCN) is a
link-specific and load- dependent packet re-marking mechanism and
provides in Differentiated Services networks feedback to egress nodes
about load conditions within the domain. It is used to
support admission control and flow termination decision in a simple
way. This document proposes how PCN marks can be encoded into
the IP header for packet-specific dual marking (PSDM). PSDM
encoding provides three different codepoints: not-ETM, not-ThM, and
PM. Excess-traffic-marking may re-mark not-ETM-packets to PM
and threshold-marking may re-mark not-ThM-packets to PM.
![]() ![]() Differences between drafts: [ IETF document history ] Presentations: [] Abstract:
Pre-congestion
notification (PCN) is a mechanism designed to protect the Quality of
Service of inelastic flows within a controlled domain. It does this by
marking packets when traffic load on a link is approaching or has
exceeded a threshold below the physical link rate. This experimental
encoding scheme specifies how three encoding states can be carried in
the IP header using a combination of two DSCPs and the ECN
bits.
The Basic scheme only allows for three encoding states. The
Full
scheme provides 6 states, enough for limited end-to-end support for ECN
as well.
![]() ![]() Differences between drafts: [ IETF document history | moncaster-02-01 | moncaster-01-00 ] Presentations: [ IETF-73 | IETF-72 ] Abstract:
The objective of the pre-congestion notification (PCN) architecture is
to protect the QoS of inelastic flows within a Diffserv domain. It
achieves this by marking packets belonging to PCN-flows when the rate
of traffic exceeds certain configured thresholds on links in the
domain. These marks can then be evaluated to determine how
close the domain is to being congested. This document
specifies how such marks are encoded into the IP header by redefining
the Explicit Congestion Notification (ECN) codepoints within such
domains. The baseline encoding described here provides only
two PCN encoding states: not- marked and PCN-marked. Future
extensions to this encoding may be needed in order to provide more than
one level of marking severity.
![]() Abstract:
Peer-to-peer
(P2P) applications, especially BitTorrent, have been one of the great
success stories on the Internet. Unfortunately that success brings with
it a downside for end-users that don’t use P2P. This memo seeks to more
precisely understand the nature of this problem and thus hopefully make
some progress towards solving it.
![]() Presentation: [ IETF p2p infrastructure wkshp ] Abstract:
A
Challenge: Some ISPs say they throttle p2p file-sharing sessions to
protect lighter usage like Web. Actually we could make lighter apps go
much faster without prolonging p2p transfers. Basic scheduling theory
says if shorter jobs go faster they finish earlier, leaving the same
capacity on average for longer jobs. As Figure 1 shows, rather than
throttling p2p bit-rate, the key is for p2p file-sharing to have a
lower weighted share. Then it would be much less aggressive to
real-time streaming(e.g. VoIP) as well.
![]() Differences between drafts: [ IETF document history ] Abstract: This
document describes some of the open problems in Internet congestion
control that are known today. This includes several new challenges that
are becoming important as the network grows, as well as some issues
that have been known for many years. These challenges are generally
considered to be open research topics that may require more study or
application of innovative techniques before Internet-scale solutions
can be confidently engineered and deployed.
![]() ![]() ![]() ![]() Differences between drafts: [ 01-00 ] Presentations: [ NGN Interconnection Strategies'08 | IETF-70 ] Abstract: The
Internet is an amazing achievement - any of the thousand million hosts
can freely use any of the resources anywhere on the public
network. At
least that was the original theory. Recently issues with how
these
resources are shared among these hosts have come to the fore.
Applications are innocently exploring the limits of protocol design to
get larger shares of available bandwidth. Increasingly we are seeing
ISPs imposing restrictions on heavier usage in order to try to preserve
the level of service they can offer to lighter customers. We believe
that these are symptoms of an underlying problem: fair resource sharing
is an issue that can only be resolved at run-time, but for years
attempts have been made to solve it at design time. In this
document
we show that fairness is not the preserve of transport protocols,
rather the design of such protocols should be such that fairness can be
controlled between users and ISPs at run-time.
![]() Differences between drafts [ rfc6040-draft-10 | IETF document history | 06-04 ] Presentations: [ IETF-77 | IETF-76 | IETF-75 | IETF-74 | IETF-73 | IETF-72 | IETF-69 ] Abstract:
This document redefines how the explicit
congestion notification (ECN)
field of the IP header should be constructed on entry to and exit from
any IP-in-IP tunnel. On encapsulation, it updates RFC 3168 to
bring all IP-in-IP tunnels (v4 or v6) into line with RFC 4301 IPsec ECN
processing. On decapsulation, it updates both RFC 3168 and
RFC
4301 to add new behaviours for previously unused combinations of inner
and outer headers. The new rules ensure the ECN field is
correctly propagated across a tunnel whether it is used to signal one
or two severity levels of congestion; whereas before, only one severity
level was supported. Tunnel endpoints can be updated in
anyorder
without affecting pre-existing uses of the ECN field, thus ensuring
backward compatibility. Nonetheless, operators wanting to
support
two severity levels (e.g., for pre-congestion notification -- PCN) can
require compliance with this new specification. A thorough
analysis of the reasoning for these changes and the implications is
included. In the unlikely event that the new rules do not
meet a
specific need, RFC 4774 gives guidance on designing alternate ECN
semantics, and this document extends that to include
tunnelling issues.
![]() ![]() ![]() ![]() Differences between drafts: [ IETF document history | ietf00-briscoe02 | briscoe02-01 | briscoe01-00] Presentations: [ IETF-80 | IETF-79 | IETF-78 | IETF-76 | IETF-73 | IETF-71 | IETF-70 | IETF-69 ] Abstract: This
document provides recommendations of best current practice for
dropping or marking packets using any active queue management (AQM)
algorithm, including Random Early Detection (RED), BLUE, Pre-Congestion
Notification (PCN), and newer schemes such as CoDel
(Controlled Delay) and PIE (Proportional Integral controller
Enhanced). We give three strong recommendations: (1) packet size
should be taken into account when transports detect and respond to
congestion indications, (2) packet size should not be taken into
account when network equipment creates congestion signals (marking,
dropping), and therefore (3) in the specific case of RED, the byte-
mode packet drop variant that drops fewer small packets should not be
used. This memo updates RFC 2309 to deprecate deliberate
preferential treatment of small packets in AQM algorithms.
![]() ![]() ![]() ![]() Differences between drafts: [ IETF document history ] Presentations: [ IETF-90 | IETF-69 | IETF-68 ] Abstract:
The TCP protocol relies on receivers sending accurate and timely
feedback to the sender. Currently the sender has no means to
verify that a receiver is correctly sending this feedback according to
the protocol. A receiver that is non-compliant has the potential to
disrupt a sender's resource allocation, increasing its transmission
rate on that connection which in turn could adversely affect the
network itself. This document presents a two stage test process that
can be used to identify whether a receiver is non-compliant. The tests
enshrine the principle that one shouldn't attribute to malice that
which may be accidental. The first stage test causes minimum impact to
the receiver but raises a suspicion of non-compliance. The second stage
test can then be used to verify that the receiver is
non-compliant. This specification does not modify the core
TCP
protocol - the tests can either be implemented as a test suite or as a
stand-alone test through a simple modification to the sender
implementation.
![]() ![]() ![]() ![]() ![]() ![]() Differences between drafts: [ 02-01 | 01-00 ] Presentations: [ PFLDnet'09 | NGN Interconnection Strategies'08 | IETF-69 | IETF-68 | IRTF-E2ERG'0702 | IRTF-ICCRG'0702 | PFLDnet'07 | IETF-67 ] Abstract:
Resource
allocation and
accountability have been major unresolved problems with the Internet
ever since its inception. The reason we never resolve these issues is a
broken idea of what the problem is. The applied research and standards
communities are using completely unrealistic and impractical fairness
criteria. The resulting mechanisms don't even allocate the right thing
and they don't allocate it between the right entities. We explain as
bluntly as we can that thinking about fairness mechanisms like TCP in
terms of sharing out flow rates has no intellectual heritage from any
concept of fairness in philosophy or social science, or indeed real
life. Comparing flow rates should never again be used for claims of
fairness in production networks. Instead, we should judge fairness
mechanisms on how they share out the `cost' of each user's actions on
others.
![]() Presentation: [ WESII'06 | CRN_DoS'06 | CRN_DoS_Nov'05 | CRN_DoS_Jan'05 ] Abstract: This
paper describes the
economic intent of a proposed change to the Internet protocol. Denial
of service is the extreme of a spectrum of anti-social behaviour
problems it aims to solve, but without unduly restricting unexpected
new uses of the Internet. By internalising externalities and removing
information asymmetries it should trigger evolutionary deployment of
protections for Internet users. To be worthwhile architectural change
must solve the last stages of the arms race, not just the next. So we
work through the competitive process to show the solution will
eventually block attacks that other researchers consider unsolvable,
and that it creates the right incentives to drive its own deployment,
from bootstrap through to completion. It also encourages deployment of
complementary solutions, not just our own. Interestingly, small
incentives in the lower layer infrastructure market amplify to ensure
operators block attacks worth huge sums on the black market in the
upper layers.
![]() Presentations: [ NGN Interconnection Strategies'08 ] Abstract: Of
all
the popular ideas
of the internet boom, one of the most dangerously influential was
Metcalfe’s law. simply put, it says that the value of a communications
network is proportional to the square of the number of its users. We
propose, instead, that the value of a network of size n grows in
proportion to n log(n).
When a ‘Law’ isn’t a Law at all, Bob Briscoe (BT) and Andrew Odlyzko (Uni Minnesota) and Benjamin Tilly (Google), International Commerce Review 8(2-4) 146--149 Springer (Winter 2009). [BibTeX] Abstract: Of
all the popular ideas of the Internet boom, one of the most
dangerously influential was Metcalfe’s law. Simply put, it states that
the value of a communications network is proportional to the square of
the number of its users.
![]() Differences between drafts: [ IETF document history | rfc-02 | ietf02-01 | ietf01-00 | ietf00-davie01 | davie01-00] Presentations: [ IETF-69 | IETF-68 | IETF-67 | IETF-66 ] Abstract:
RFC 3270 defines how to support the Diffserv
architecture in MPLS
networks, including how to encode Diffserv Code Points (DSCPs) in an
MPLS header. DSCPs may be encoded in the EXP field, while other uses of
that field are not precluded. RFC3270 makes no statement about how
Explicit Congestion Notification (ECN) marking might be encoded in the
MPLS header. This document defines how an operator might define some of
the EXP codepoints for explicit congestion notification, without
precluding other uses.
![]() ![]() ![]() ![]() Differences between drafts: [ pcn03-pcn02 | pcn02-pcn01 | pcn01-pcn00 | pcn00-tsvwg01 | tsvwg01-tsvwg00] Presentations: [ IETF-66 | IETF-65 ] Abstract:
Scaling
per flow admission
control to the Internet is a hard problem.
The approach of combining Diffserv and pre-congestion notification
(PCN) provides a service slightly better than Intserv controlled load
that scales to networks of any size without needing Diffserv's usual
overprovisioning, but only if domains trust each other to comply with
admission control and rate policing. This memo claims to
solve
this trust problem without losing scalability. It provides a
sufficient emulation of per-flow policing at borders but with only
passive bulk metering rather than per-flow processing.
Measurements are sufficient to apply penalties against cheating
neighbour networks.
![]() ![]() Abstract: Guaranteed
QoS Synthesis
(GQS) is a distributed measurement-based admission control scheme. It
is
designed as a simple and scalable approach to providing strong service
guarantees using bulk packet congestion marking across a core network
region.
We describe the operation and performance of GQS, with particular
reference to
its use for fair resource-sharing between guaranteed traffic and a
rate-responsive non-guaranteed class. This analysis includes a detailed
simulation study which fully represents the interactions between events
at
packet and session timescales. Results confirm that GQS provides strong
guarantees under normal conditions, is robust to different traffic
configurations, and readily recovers from network failure events.
![]() Presentations [ CFP Jan 06 | CRN Jun 06 ] Goal of this document: To
lay
out the space of possible activity across the technical, economic,
contractual and regulatory fields in order to prioritise activity. In
particular:
![]() ![]() ![]() ![]() Abstract:
This
review thoroughly
analyses draft
01 of the Quick-Start
proposal, focusing mostly on security issues. It is argued that the
recent new QS nonce proposal gives insufficient protection against
misbehaving receivers, and a new approach is suggested. But it would be
perverse to strengthen protection against malicious receivers too much
when the protocol only works if all senders can be trusted to comply.
The review argues this is an inevitable result of choosing to have
routers allocate rate to senders without keeping per-flow state. The
paper also questions whether Quick-Start's under-utilisation assumption
defines a distinct range of operation where fairness can be ignored.
Because traffic variance will always blur the boundary, we argue that
under-utilisation should be treated as the extreme of a spectrum where
fairness is always an issue to some extent.
If we are to avoid per-flow state on routers, the review points to an alternative direction where endpoints allocate rate to themselves. Counter-intuitively, this allows scalable security and a spectrum of fairness to be built in from the start, but rate allocation is less deterministic. Issues not related to security are also raised, including the possibility of a catastrophic overload if path delays are atypical. A solution to this is offered, as well as solutions to scalability issues with the range and precision of the Rate Request field. Many other more minor review comments are given. ![]() ![]() <Identical
body text to
the above IETF Internet Draft>
![]() ![]() ![]() ![]() Differences between drafts: [ conex: IETF document history | tsvwg: 09-08 | 08-07 | 07-06 | 06-05 | 05-04 | 04-03 | 03-02 | 02-01 ] Presentations: [ IETF-76 | ECOC-FID'07 | IETF-69 | IETF-68 | CMU'06 | IETF-67 | IETF-66 | IETF-65 | IETF-64 ] Abstract:
This
document introduces re-ECN (re-inserted explicit congestion
notification), which is intended to make a simple but far-reaching
change to the Internet architecture. The sender uses the IP header
to reveal the congestion that it expects on the end-to-end path. The
protocol works by arranging an extended ECN field in each packet so
that, as it crosses any interface in an internetwork, it will carry a
truthful prediction of congestion on the remainder of its path. It
can be deployed incrementally around unmodified routers. The purpose
of this document is to specify the re-ECN protocol at the IP layer
and to give guidelines on any consequent changes required to
transport protocols. It includes the changes required to TCP both as
an example and as a specification. It briefly gives examples of
mechanisms that can use the protocol to ensure data sources respond
sufficiently to congestion, but these are described more fully in a
companion document.
![]() ![]() ![]() ![]() Differences between drafts: [ conex: IETF document history | tsvwg: 02-01 | 01-00 ] Presentations: [ MIT CFP Oct'09 | IRTF-May'09 | ECOC-FID'07 | IETF-69 | ParisNetNeutrality'07 | IETF-68 | CRN_NetNeutrality'06 | CMU'06 | IETF-67 | IETF-66 | IETF-65 | IETF-64 ] Abstract: This
document describes a framework for using a new protocol called
re-ECN (re-inserted explicit congestion notification), which can be
deployed incrementally around unmodified routers. Re-ECN allows
accurate congestion monitoring throughout the network thus enabling
the upstream party at any trust boundary in the internetwork to be
held responsible for the congestion they cause, or allow to be
caused. So, networks can introduce straightforward accountability
for congestion and policing mechanisms for incoming traffic from end-
customers or from neighbouring network domains. As well as giving
the motivation for re-ECN this document also gives examples of
mechanisms that can use the protocol to ensure data sources respond
correctly to congestion. And it describes example mechanisms that
ensure the dominant selfish strategy of both network domains and end-
points will be to use the protocol honestly.
![]() Abstract:
In the current Internet, congestion control is
voluntary and not
responding sufficiently to congestion is becoming a growing problem.
Rate policers in the literature are based on the assumption of
placement at a single bottleneck and a known minimum round trip time.
We aim to characterise the limitations of these policers in many
practical scenarios where we believe these assumptions break down. We
present the design of a policer based on a novel feedback architecture
that transcends these assumptions. The new arrangement places our
policer at the interface with the sender. The sender is trapped into
sending packets through the policer that honestly declare the
congestion and round trip time of the whole downstream path. We compare
the theoretical limits of these different classes of policers.
![]() Presentations: [ IETF-66 | IETF-63 ] Abstract:
This
document specifies the extensions to RSVP for support of the Controlled
Load (CL) service over a Diffserv cloud using Pre-Congestion
Notification as defined in [CL-DEPLOY].
![]() Differences between drafts: [ IETF document history ] Presentations: [ IETF-72 | IETF-71 ] Abstract:
This
document
describes a general architecture for flow admission
and termination based on pre-congestion information in order
to protect the quality of service of established, inelastic flows
within a single Diffserv domain.
![]() Differences between drafts: [ 04-03 ] Presentations: [ IETF-66 | IETF-65 | IETF-64 | IETF-63 ] Abstract:
This
document describes a
deployment
model for pre-congestion notification (PCN) operating in a large
DiffServ-based region of the Internet. PCN-based admission control
protects the quality of service of existing flows in normal
circumstances, whilst if necessary (eg after a large failure)
pre-emption of some flows preserves the quality of service of the
remaining flows. Each link has a configured-admission-rate and a
configured-pre-emption-rate, and a router marks packets that exceed
these rates. Hence routers give an early warning of their own potential
congestion, before packets need to be dropped. Gateways around the
edges of the PCN-region convert measurements of packet rates and their
markings into decisions about whether to admit new flows, and (if
necessary) into the rate of excess traffic that should be pre-empted.
Per-flow admission states are kept at the gateways only, while the PCN
markers that are required for all routers operate on the aggregate
traffic - hence there is no scalability impact on interior routers.
![]() ![]() Differences between drafts: [ IETF document history | eardley01-00 ] Abstract:
The objective of Pre-Congestion Notification (PCN)
is to protect the
quality of service (QoS) of inelastic flows within a Diffserv domain in
a simple, scalable, and robust fashion. This document defines
the two metering and marking behaviours of PCN-nodes.
Threshold-metering and -marking marks all PCN-packets if the rate of
PCN-traffic is greater than a configured rate
("PCN-threshold-rate"). Excess-traffic-metering and -marking
marks a proportion of PCN-packets, such that the amount marked equals
the rate of PCN-traffic in excess of a configured rate
("PCN-excess-rate"). The level of marking allows
PCN-boundary-nodes to make decisions about whether to admit or
terminate PCN-flows.
![]() Differences between drafts: [ 03-02 ] Presentations: [ IETF-66 | IETF-65 | IETF-63 ] Abstract:
Pre-Congestion Notification (PCN) builds on the concepts of RFC 3168,
"The addition of Explicit Congestion Notification to IP". However,
Pre-Congestion Notification aims at providing notification before any
congestion actually occurs. Pre-Congestion Notification is applied to
real-time flows (such as voice, video and multimedia streaming) in
DiffServ networks. As described in [CL-DEPLOY],
it enables "pre"
congestion control through two procedures, flow admission control and
flow pre-emption. The draft proposes algorithms that determine when a
PCN-enabled router writes Admission Marking and Pre-emption Marking in
a packet header, depending on the traffic level. The draft also
proposes how to encode these markings. We present simulation results
with PCN working in an edge-to-edge scenario using the marking
algorithms described. Other marking algorithms will be investigated in
the future.
![]() Presentations: [ NGN Interconnection Strategies'08 | IP Interconnection Forum | CFP ] Abstract:
Interconnection of IP QoS capabilities between
networks releases
considerable value. In this paper we show where this value will be
realised. We give technical and economic arguments for why QoS will be
provided in core and backbone networks as a bulk QoS facility incapable
of distinguishing or charging differentially between sessions. While
between edge networks a vibrant mix of retail QoS solutions will be
possible, including Internet-wide per flow guarantees.
We outline cutting edge research on how to coordinate QoS between networks, using a session-based overlay between the edges that will extract most surplus value, underpinned by a bulk QoS layer coordinating the whole. We survey today's interconnect tariffs and the current disconnected state of IP QoS. Then we describe a commercial `model of models' that allows incremental evolution towards an interconnected future. The paper covers intertwined engineering and economic/commercial issues in some depth, but considerable effort has been made to allow both communities to understand the whole paper. ![]() Presentation Abstract:
With
the
transition of
services like IP telephony to
be carried
over IP networks there is the potential for catastrophic numbers of
calls to fail whenever sufficient demand is focused on unpredictable
points in the core IP network. This is well-known; Service
differentiation helps but does not alleviate the problem - call
admission control is required but seems expensive for the few occasions
it is required.This paper describes a BT-developed experimental
mechanism called guaranteed QoS synthesis (GQS) that performs call
admission control for core IP networks for constant bit-rate streams
(voice and video). The mechanism is primarily aimed at Internet
services but it may be possible to extend it for VPN
applications. The GQS mechanisms is economic to deploy and operate ,
and scales without any increase in complexity. It achieves
these
properties by keeping no flow state in the network and basing call
admission decisions on the measured congestion across the network. The
paper describes the high-level GQS architecture as well as some of the
deployment issues and potential savings in the operational support
area. How GQS enables the separation of the interconnect QoS and retail
business models is also explained.
![]() Presentation: [ SIGCOMM'05 | CFP_BB'05 | UCL'04 | Cam'04 | ICSI'04 ] Abstract:
This paper introduces a novel feedback
arrangement, termed re-feedback.
It ensures metrics in data headers such as time to live and congestion
notification will arrive at each relay carrying a truthful prediction
of the remainder of their path. We propose mechanisms at the network
edge that ensure thedominant selfish strategy of both network domains
and endpoints will be
to set these headers honestly and to respond correctly to path
congestion and delay, despite conflicting interests. Although these
mechanisms influence incentives, they don’t involve tampering with
end-user pricing. We describe a TCP rate policer as a specific example
of this new capability. We show it can be generalised to police various
qualities of service. We also sketch how a limited form of re-feedback
could be deployed incrementally around unmodified routers without
changing IP.
![]() Presentation Abstract:
Properly characterising paths is an important
foundation for resource
sharing and routing in packet networks. We realign metrics so that
fields in packet headers characterise the path downstream of any point,
rather than upstream. Then closed loop control is possible for either
end-points or network nodes. We show how incentives can be arranged to
ensure that honest reporting and responsible behaviour will be the
dominant strategies of selfish parties, even for short flows. This
opens the way for solutions to a number of problems we encounter in
data networking, such as congestion control, routing and denial of
service.
![]() Presentation The
above
document
supersedes the
article below
![]() Abstract:
This paper concerns how computing devices will
impact on how we design
networking as they increasingly pervade the fabric of the world. We
identify the pressure points where pervasive computing will push
current approaches to their limits, covering both technical and
business implications. We use a broad definition of communications
technology, to include not only infrastructure equipment and services,
but also communications facilities within the devices themselves.
We outline progress redesigning the Internet for pervasive computing. We cover components of communications such as transport, routing and security. But we also consider how the industry will be arranged; explaining why new modes of communications (e.g. publish-subscribe) will become prevalent, where functions will be placed and how their deployment will happen. We give the rationale behind the most respected approaches being adopted. We give reasoned, if sometimes controversial, views of what should happen, built on our own research. We dispel some myths and outline the research agenda that still stands between us and realisation of the vision of ubiquitous computing. ![]() Presentation Abstract:
We
describe the Generic
Announcement Protocol (GAP), a two-tier generic multicast transport
designed for scalable event notification. GAP requires no extra central
infrastructure or administration beyond a multicast enabled network or
an equivalent overlay. GAP’s scalability arises from the use of
announcement indexes, which exploit the underlying openness and
flexibility of the raw GAP protocol. Event notifications can be
massively multiplexed onto a multicast group channel, with interested
receivers only joining the group for the brief duration of the
announcement, coordinated by an acyclic graph of indexes, which are
themselves announcements on
other channels. This indexing technique, combined with the GAP protocol
is particularly efficient when waiting for events to occur, since the
network resources (for addressing and filtering) are kept to a minimum.
![]() Presentation Abstract:
The fundamental economics of packet networking has led us to a
mechanism to guarantee
quality of service (QoS) with no flow handling in the core Internet,
giving far better scalability, robustness and simplicity than
previously. The same packet congestion mechanism is then generalised to
encourage customers to manage all
classes of traffic responsibly and with optimal utilisation. A vision
of the future is given, driven by the inexorable logic of economics.
The economic concepts behind the engineering are briefly explained.
![]() ![]() Presentation Abstract: We present and analyse an approach to service differentiation in third generation mobile networks based on Wideband CDMA, that exposes a new weighting parameter designed to reflect allocation of the congestible resource. The approach naturally takes into account the difference in resource scarcity for the uplink and downlink, because it is grounded on fundamental economic models for efficient utilization of resources in WCDMA. If required, discrete values of this weight parameter can be presented as different service classes. Finally we present numerical experiments demonstrating the effectiveness of our approach, and investigate its performance and transient behaviour under power control and signal quality estimation errors. ![]() ![]() Abstract: We present a model based on congestion pricing for resource control in wireless CDMA networks carrying traffic streams that have fixed rate requirements, but can adapt their signal quality. Our model is based on resource usage in the uplink direction of CDMA networks, and does not differentiate users based on their distance from the base station. We compare our model with other economic models that have appeared in the literature, identifying their similarities and differences. Our investigations include the effects of a mobile's distance and the wireless network's load on the target signal quality, the transmission power and the user's benefit and charge. ![]() Presentation Abstract: In this paper, we describe our approach to managing quality of service (QoS) using pricing. We show how it is possible to synthesise network QoS in the end-systems along the lines of the end to end design principle, as one of many possible business models. We have: i) developed an architecture for market management; ii) invented new business models to test and demonstrate its flexibility; iii) implemented generic mechanisms that not only enable these models but also many others; iv) modelled selected features of the resulting systems & markets and v) conducted experiments on users to assess acceptability and the feasibility of the overall approach. Each of these aspects is outlined in brief overview, with numerous references to more ![]() Abstract: This draft describes a very flexible and efficient protocol for distributing price information (tariffs) inside an Internet Service Provider's management system and to its customers. It is designed to work with multiple QoS architectures, for example Intserv [2] and Diffserv [4]. It can also be used for dynamic pricing. It can use a number of different transport mechanisms, e.g. embedding tariff messages as policy objects in RSVP [9] messages. As tariffs can get very complex, it is possible but not necessary to send tariffs as code (e.g. Java). The draft also contains clear definitions of tariff and related terms. ![]() Abstract: This document introduces Timed Efficient Stream Loss-tolerant Authentication (TESLA). TESLA allows all receivers to check the integrity and authenticate the source of each packet in multicast or broadcast data streams. TESLA requires no trust between receivers, uses low-cost operations per packet at both sender and receiver, can tolerate any level of loss without retransmissions, and requires no per-receiver state at the sender. TESLA can protect receivers against denial of service attacks in certain circumstances. Each receiver must be loosely time-synchronized with the source in order to verify messages, but otherwise receivers do not have to send any messages. TESLA alone cannot support non-repudiation of the data source to third parties. ![]() ![]() ![]() Abstract: This document contributes to the effort to add explicit congestion notification (ECN) to IP. In the current effort to standardise ECN for TCP it is unavoidably necessary to standardise certain new aspects of IP. However, the IP aspects will not and cannot only be specific to TCP. We specify interaction with features of IP such as fragmentation, differentiated services, multicast forwarding, and a definition of the service offered to higher layer congestion control protocols. This document only concerns aspects related to the IP layer, but includes any aspects likely to be common to all higher layer protocols. Any specification of ECN support in higher layer protocols is expected to appear in a separate specification for each such protocol. ![]() [Full report, on which the above paper is based] ![]() ![]() ![]() ![]() ![]() ![]()
Abstract: Some applications only make sense within a very tightly bounded range of quality of service (QoS) from the network. Others are far more adaptive. For the former type of application, it is relatively easy to determine their QoS requirements. This document primarily concerns how to determine the QoS requirement of the latter type of application, given a tariff for ![]() ![]() Presentation Abstract: We present an architecture for the Internet that both enables and manages network supply and demand using market mechanisms. The technical approach a network takes to controlling its load is typically termed its ‘control architecture’. This is defined by the protocols and algorithms used and determines how tightly customers can control quality of service (QoS). On the other hand, the provider’s commercial approach is defined by the contractual offer it makes, in particular the tariff on offer. To avoid using the term ‘architecture’ for two things, we use the term service plan for this combination of a provider’s technical and commercial approaches. The M3I Architecture encompasses the internal working of each service plan as well as the overall approach to combining all service plans across the Internet. For instance, the Differentiated Services Architecture (Diffserv [24, 9]) is ‘just’ a service plan by our definition, as it defines not only its QoS signalling technologies, but also service level agreements, thus defining the form of contract the customer is expected to agree to, how the value chain is arranged, etc. As well as existing service plans like Diffserv, the M3I Architecture enables a rich variety of novel service plans in different networks. That is, specific technical control architectures and specific commercial approaches interworking across an internetwork. Network providers are then able to differentiate themselves through their approaches to QoS and pricing, in turn giving customers wider choice. ![]() ![]() Abstract: This document presents our architecture for a market managed multi-service Internet (M3I). As explained in Part I, the task is to encompass all multi-service Internet architectures simultaneously in one architecture. To avoid confusion, we therefore term these sub-architectures ‘service plans’. A service plan is a combination of a network control architecture and the business model used to offer it as a service. The architecture is open, not only encompassing current and proposed service plans, but also facilitating the creation of new ones. ![]() ![]() ![]() Abstract: In this paper we describe an intelligent, client based charging middleware that can be used to enable customers' self policing over the access of network resources in a multi service network like Internet (and ultimately higher level services). By intelligence we mean the charging software, data stores and the human or agent based reaction to dynamic pricing. The middleware components described in this paper are part of the MWARE client based middleware being researched and developed at the BT Advanced Communications Technology Centre [mware]. ![]() Abstract: In this paper we present a novel scalable accounting infrastructure to support charging for network usage and Quality of Service (QoS) in an Internet context. Measurement and accounting are two core processes of a charging mechanism that make heavy demand on resources. They reduce the resource available for the core processes of the network i.e. routing and forwarding packets. Increasing the processing power and data storage capacity of the affected network elements lead to an increment in the cost of the network. The underlying principle of the infrastructure we propose is the transfer of these processes onto the edge systems to reduce their impact on the cost of the network. The measurement, accounting, applying pricing and billing processes and related sets of data are relocated on the edge systems of the network while allowing the provider to retain control over them. This paper focuses on the measurement and accounting aspects of this infrastructure. To achieve scalability we propose not to meter all the data or QoS control packet but only samples of them. We also discuss which controls both users and network providers could desire over the relocated processes. Early implementation of this work is introduced as a practical example of the concepts we present.
Abstract: The goal of this work is to separately control individual secure sessions between unlimited pairs of multicast receivers and senders. At the same time, the solution given preserves the scalability of receiver initiated Internet multicast for the data transfer itself. Unlike other multicast key management solutions, there are absolutely no side effects on other receivers when a single receiver joins or leaves a session and no smartcards are required. The cost per receiver-session is typically just one short set-up message exchange with a key manager. Key managers can be replicated without limit because they are only loosely coupled to the senders who can remainoblivious to members being added or removed. The technique is a general solution for access to an arbitrary sub-range of a sequence of information and for its revocation,as long as the end of each sub-range can be planned at the time each access is requested. ![]() ![]() ![]() [A full length report describing five variations on the solution to the problem and a mathematical model encompassing them all. The above NGC'99 paper is a brief extract describing one solution] Abstract: The goal of this work is to separately control individual secure sessions between unlimited pairs of multicast receivers and senders. At the same time, the solution given preserves the scalability of receiver initiated Internet multicast for the data transfer itself. Unlike other multicast key management solutions, there are absolutely no side effects on other receivers when a single receiver joins or leaves a session and no smartcards are required. Solutions are presented for single and for multi-sender multicast. Further, we show how each receiver's data can be subject to an individual, watermarked audit trail. The cost per receiver-session is typically just one short set-up message exchange with a key manager. Key managers can be replicated without limit because they are only loosely coupled to the senders who can remain oblivious to members being added or removed. The technique is a general solution for access to an arbitrary sub-range of a sequence of information and for its revocation, as long as each session end can be planned at the time each access is requested. It might therefore also be appropriate for virtual private networks or for information distribution on other duplicated media such as DVD. ![]() ![]() ![]() ![]() Abstract: The goal of this work is to separately control individual secure sessions between unlimited pairs of multicast receivers and senders while preserving the scalability of receiver initiated Internet multicast for the data transfer itself. Unlike other secure multicast solutions, there are absolutely no side-effects on other receivers when a single receiver joins or leaves a session. Each individual receiver can also reliably prove whether any fragment of the data hasn't been delivered or wasn't delivered on time (e.g. late video frames). Further, each receiver's data can be subject to an individual, watermarked audit trail. The cost per receiver-session is typically just one set-up message exchange with a key manager. Key managers can be replicated without limit because they are only loosely coupled to the senders who can remain oblivious to members being added or removed. The solution requires a tamper-resistant processor such as a smartcard at each receiver. However, generic cards supplied by a trusted third party are used rather than cards specific to each information provider. The technique can be applied to other bulk data distribution channels instead of multicast, such as DVD. ![]() [Full report, on which the above paper is based]
Abstract: [The union of the two papers below]
![]() ![]() ![]() Abstract: The underlying objective of the work presented in this paper is to create an active multi-service network which uses pricing to manage supply and demand of resources. The paper describes a dynamic pricing framework designed to support a radical approach to usage-based charging for packet-switched networks. This approach addresses the scalability problem normally associated with usage-based charging by shifting responsibility for accounting over to customer systems, which are also assigned the task of applying tariffs to create a bill. ![]() ![]() ![]() ![]() Abstract: This paper suggests that a multi-service packet network might be achieved by adding classification and scheduling to routers, but not policing. Instead, a lightweight, packet-granularity charging system is presented that emulates a highly open policing function and is completely separated from the data path. A high proportion of charging operations runs on customer systems to achieve this, the proportion being configurable per-customer. Functions dispersible to customers include not only metering, accounting and billing but also per-packet or per-flow policing and admission control. Lower cost is achieved through simplicity without sacrificing commercial flexibility or security. Inter-provider charging, multicast charging and open bundling of network charges with those for higher class services are all catered for within the same, simple design. The paper is primarily architectural, referring to supporting papers for reports of early implementation experience in an Internet context. ![]()
In this paper we propose a pricing model which is session based and we look at the impact of this on real-time multimedia conferencing over the Internet. In this model, we are trying to allow for the optional integration of charging at the network layer with charging at the session layer, while keeping the underlying technologies still cleanly apart. This paper also highlights the fact that the main problem of pricing application on the Internet is not just a simple case of analyzing the most technically feasible pricing mechanism but also making the solution acceptable to users. We take the position that session based pricing is easier for end users to accept and understand and show why this is the case in this paper. ![]() Abstract: [near-identical to the above ISCC'99 paper] ![]() ![]() ![]() ![]()
![]() ![]() ![]()
![]() ![]() Presentation to IETF LSMA working group, Pete Bagnall, Munich, Aug 1997, Washington, Dec 1997 [broken link - presentation lost]
![]() Also published as Chapter 15, "Distributed Objects on the Web" in Steve Sim and John Davies (Eds), "The Internet and Beyond," BT Telecommunications series, pub. Chapman & Hall, ISBN 0-412-83170-8 (1998) (pre-print) [BibTeX]
![]()
It is fashionable to criticise how well the Web achieves this or that goal then invent a "proper" service to do it better. It is tempting to suppose that technology for structured applications from the traditions of the distributed object world should be inserted into the Web on the day of their marriage. This paper aims to show that, in the field of service discovery, the Web deserves a long hard look before we click on the button marked "Fixed in the Next Release". As such, no new technology is proposed, merely some optimistic thoughts leading to the insight that the Web is a "proper" system for resource discovery (well, nearly). |