Figure there may be a few people on this list that might have opinions
about this... :)
-Toke
--- Begin Message ---
Hi folks,
please see a call for (position) papers for an IAB workshop on Design
Expectations vs. Deployment Reality below. This could be particular interesting
for this groups as what is usually measured is deployment reality part of the
questions targeted below.
Submission deadline is already May 3, however, a short summary of deployment
problem you have detected in an eventually already published study would be
sufficient.
The workshop will be on June 4/5 in Helsinki. Find more information below also
here: https://www.iab.org/activities/workshops/dedr-workshop/
Mirja
On 12.04.19, 20:30, "IETF-Announce on behalf of IAB Chair"
<[email protected] on behalf of [email protected]> wrote:
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 RFC5218 <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
[email protected] <mailto:[email protected]>.
_______________________________________________
Maprg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/maprg
--- End Message ---
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
