IAB Workshop Call for Papers: Design Expectations vs. Deployment Reality

[IAB Chair <[e-mail]>]

Design Expectations vs. Deployment Reality in Protocol Development


A number of protocols have presumed specific deployment models during 
the development or early elaboration of the protocol.  Actual 
deployments have sometimes run contrary to these early expectations when 
economies of scale, DDoS resilience, market consolidation, or other 
factors have come into play. These factors can result in the deployed 
reality being highly concentrated.


This is a serious issue for the Internet, as concentrated, centralized 
deployment models present risks to user choice, privacy, and future 
protocol evolution.


On occasion, the differences to expectations were almost immediate, but 
they also occur after a significant time has passed from the protocol’s 
initial development.


Examples include:


Email standards, which presumed many providers running in a largely 
uncoordinated fashion, but which has seen both significant market 
consolidation and a need for coordination to defend against spam and 
other attacks. The coordination and centralized defense mechanisms scale 
better for large entities, which has fueled additional consolidation.


The DNS, which presumed deep hierarchies but has often been deployed in 
large, flat zones, leading to the nameservers for those zones becoming 
critical infrastructure. Future developments in DNS may see 
concentration through the use of globally available common resolver 
services, which evolve rapidly and can offer better security. 
Paradoxically, concentration of these queries into few services creates 
new security and privacy concerns.


The Web, which is built on a fundamentally decentralized design, but 
which is now often delivered with the aid of Content Delivery Networks. 
  Their services provide scaling, distribution, and Denial of Service 
prevention in ways that new entrants and smaller systems operators would 
find difficult to replicate.  While truly small services and truly large 
ones may operate using only their own infrastructure, many others are 
left with the only practical choice being the use of a globally 
available commercial service.


Similar developments may happen with future technologies and services. 
For instance, the growing use of Machine Learning technology presents 
challenges for distributing effective implementation of a service 
throughout a pool of many different providers.


In RFC 5218 <https://tools.ietf.org/html/rfc5218>the IAB tackled what 
made for a successful protocol.  In RFC 8170 
<https://tools.ietf.org/html/rfc8170>, the IAB described how to handle 
protocol transitions.  This workshop will explore cases where the 
initial system design assumptions turned out to be wrong, looking for 
patterns in what caused those assumptions to fail (e.g., concentration 
due to DDoS resilience) and in how those failures impact the security, 
privacy, and manageability of the resulting deployments.


While the eventual goals might include proposing common remediations for 
specific cases of confounded protocol expectations, the IAB is currently 
inviting papers which:


  *

    Describe specific cases where systems assumptions during protocol
    development were confounded by later deployment conditions.

  *

    Survey a set of cases to identify common factors in these confounded
    expectations.

  *

    Explore remediations which foster user privacy, security and
    provider diversity in the face of these changes.


Important Dates


The workshop will be held June 4-5 in Helsinki, Finland.


Position papers must be submitted by May 3rd at the latest. The program 
committee will review submitted position papers and send an invitation 
to the workshop to one of the paper authors. Invitations will be 
distributed by May 9 at the latest.


Position Paper Requirements


Interested parties must submit a brief document of one to four pages, 
formatted as HTML, PDF, or plain text. We welcome papers that describe 
existing work, answers to the questions listed above, new questions, 
write-ups of deployment experience, lessons-learned from successful or 
failed attempts, and ideally a vision towards taking deployment 
considerations better in account when designing new Internet technology. 
Re-submissions from work presented elsewhere are allowed.


Program Committee


The following persons are IAB contacts for this workshop:


Jari Arkko

Stephen Farrell

Ted Hardie

Christian Huitema

Melinda Shore

Brian Trammell


Position papers should be sent by email to [e-mail].