# DINRG Meeting at IETF-116   {#dinrg-meeting-at-ietf-116}

Date-time: 2023-03-30, 09:30 to 11:30 UTC  
Notetaker(s): Flo Driscoll, Ryo Yanagida, Caspar Schutijser

## 1. DINRG Chairs’ Presentation: Status, Updates Chairs 10 min   {#1-dinrg-chairs-presentation-status-updates-chairs-10-min}

*   General reminders about venue rules, IRTF goals
*   Notetaker is requested by the chair
    *   Volunteer found in the room onsite

## 2. Avoiding Internet Centralization   {#2-avoiding-internet-centralization}

Speaker: **Mark Nottingham**  
Draft has been around for ~2 years, started when Mark was on IAB.
Inspired by arguments in the IETF about the centralising or
decentralising effects of proposals.

Current version is in three sections:

1.  What is centralisation, why this community finds it undesirable
2.  Decentralisation - techniques, why effects aren't always desirable
3.  Recommendations for IETF community, what we can or can't do.

Has been an individual draft for a long time. IAB decided not to adopt
it in early 2023. Taken to independent stream where it's currently in
review. Mark is currently incorporating feedback. New version planned in
the next week or two.

### Discussion/Questions:   {#discussionquestions}

**Geoff Huston**: Good document in parts. In other parts you wonder if
it's trying to carry an agenda which is impossible. Consensus is rare
here, I wonder if it's better to advance a thesis from a particular
direction rather than producing a document that doesn't offend anyone.
Part 3 has a perspective, parts 1 and 2 don't. I'd encourage you to take
a position. I don't think we have consensus. The problem is complex, and
while difficult, having a unique, specific position is valuable.  
**Mark Nottingham**: Draft has been around for a long time, my view has
changed over time. I had a period where I received a lot of feedback
that I felt obligated to incorporate, I'm pulling that out now.  
**Geoff**: Be bold, say what you think. \[don't water it down\]  
**Mark N.**: If you don't acknowledge different views a reader will
think the document is biased.  
**Geoff**: We can discuss cause and effect. In a market based on volume,
how to balance the social and economic incentives is hard.   
**Mark**: I think you'll be happier reading the current editor's draft.

**Corinne Cath**: What is the current definition of centralisation you
use and what aspects are you specifically concerned about? Different
examples are hard to compare, do we need to be worried about them in the
same way (e.g. in cloud computing v. DNS).  
**Mark N.**: It's case by case. There are situation very small number of
individuals have large influence/power. The discussion about DNS vs
cloud: DNS has maybe avoided the impact of centralisation but some may
disagree. Now, with cloud, while centralisation might be an issue but I
can still take my compute workload from one provider to another. There
are additional services that provide 'value-adds' and they are 'sticky',
and that makes it hard maybe.   
**Corinne**: I agree that as an individual consumer it's easy to move
from one cloud provider to another. However, I've seen it being very
difficult for big educational providers to move from one cloud provider
to another for cost reasons.  
**Mark N.**: I see that happening and maybe there needs to be
regulations.

**Marie-Jose Montpetit**: There was a presentation on the effect of
centralisation on data privacy and data protection. Hyper-centralisation
was probably not eco-friendly. It was in the context of AI and data
centres - laws requiring data to be kept in national boundaries means
can't take advantage of green energy in some locations. You could add
this to your document, hyper-centralisation is not taking advantage of
edge capabilities being put together. Decentralisation may be good for
the planet.  
**Mark N.**: First, I can't agree that Australia is interested in
privacy, at least not enough. Second, I also don't think I agree that
legal privacy requiriments are driving the centralisation too.  
**Marie-Jose**: I've seen studies that show if you need to keep data in
the US you can't take advantage of hydropower. Can share slides. I
always had the impression that there were a lot of edge capabilities
that could be used to provide currently hyper-centralised services.  
**Mark N.**: I'd emphasise that effect of centralisation but the main
focus is how this community relates to it and the effect of it.   
**Marie-Jose**: Will share the report later. Acknowledge that it's a
complicated problem.  
**Mark N.**: It is broad so I want to narrow down on it.

**Dirk Kutscher**: Do you have any recommendations of IETF work on this?

**Mark N.**: One of my todos is to outline potential next steps.

## 3. Effects of Internet Consolidation   {#3-effects-of-internet-consolidation}

Speaker: **Mark McFadden**

Rewrite of a draft from 2022. The intention is to talk about effects of
internet consolidation. Aim is to analyse how consolidation has changed
the internet. Motivations: 1. protocol design has real effects on
centralisation, see that expand over time; 2. centralisation has changed
how we deploy services on the internet; 3. difference between
centralisation and consolidation.

This document is targeted at this research group, we want to contribute
to research.

This draft acknowledges that there is a lot of writing on Internet
centralisation. We need to acknowledge this and there are many types of
those work. It's not just engineers, various parties like operators,
designers are also looking at this.

Centralisation v. consolidation - decentralised technology alone does
not guarantee decentralised outcomes. Important for dinrg and charter.
Think of consolidation as an outcome, a combination of motivations that
causes centralisation to take place. Centralisation can be an outcome of
economic reality, protocol choices, engineering efficiency and reality.

Draft argues that centralisation changes architecture. Not necessary
outcome, but what has happened in the last ten years or more. Principles
that used to be true are no longer true e.g. end-to-end principle. There
are intermedieries that provide services, that is far beyond what
traditional proxies would do. Examples include OHAI and Privacy Pass.

Summary: Implications for architecture, implications move beyond
research, look at DINRG charter. This draft doesn't make prescriptive
suggestions.

### Discussions/Questions   {#discussionsquestions}

**Haiguang Wang**: Can't find your draft online.  
**Mark M**: It's on datatracker and in meeting materials for this
meeting.

**Ryo Yanagida**: You mentioned that protocol design drives
centralisation. I thought IETF was about interoperability. Have you seen
examples where that isn't the case? Could you elaborate?  
**Mark M**: One of the most fundamental things the IETF do is
interoperability. I want to distinguish interoperability from protocol
design which gives certain players dominance - be that economic or
capital. I want to highlight protocols which give the opportunity for
large scale players to become dominant. E.g. Privacy Pass - adds
intermediary between user and service, risk of these intermediaries
being controlled by a small number of players. Companies could exploit
that. Privacy Pass does a good job of increasing privacy, but
intermediaries have opportunity for exploitation. Still interoperable.  
**Ryo**: Is it only feasible for a large company to be in the middle?  
**Mark M**: Some protocols require only a small number of intermediaries
for cryptographic or engineering reasons.

**Colin Perkins**: Your examples are relatively recent privacy focused
protocols. They're reasonable examples. The IETF have been developing
protocols that require in-network intermediaries for a long time. How
are these protocols different from those e.g. SIP, email protocols?  
**Mark M**: There are different. We have things like HTTP, which can
have intermediaries. SIP is an interesting example, this was designed to
fulfill a specific requirement. Newer protocols differ, in that, they
have certain properties that leads to the consolidation.  
**Colin**: Some older protocols like SIP/Email has led to
centralisations, and would be worth discussing how it differs.   
**Mark M**: I'm not sure SIP, email, WebRTC led to centralisation. But
that is true. Will look more into it, and let's discuss further.

**Arnaud Taddei**: In ECH, the centralisation comes from the fact that
you cannot offer ECH if you aren't a CDN. There is a choice by the IETF
that because they don't like network security at a network level, they
want it to be offered at the content level. Compliance and security can
only be done at the CDN level. I understand the argument that ECH could
be optional, but the first customers will be cyber criminals. What
happens if centralisation points are breached? I think this is a very
good paper, I agree we Colin that maybe we can improve that part.

**Dirk Kutscher**: Interesting discussion. For SIP specifically, the key
word is federation. The previous suite of multimedia protocols were not
good enough, leading to WebRTC which has factored into web
centralisation. What would be good topics for this group to work on? We
don't have a protocol police, but there are always technology
consequences that aren't discussed enough e.g. impacts of OHAI. Could
these be topics for this group?

**Mark M**: There are a lot of work to define the landscape. The goal is
to talk about the effects of centralisation but another goal is to help
the architectural design to consider those impacts and be conscious of
it in the protocol development.

**Alexander Railean**: Perhaps we should start making it mandatory to
include a section called consolidation considerations in drafts.  
**Mark M**: I like that. RFC 3552 is very old. I think considerations at
the back of RFCs need some rethinking.  
**Colin Perkins**: That's out of scope for the IRTF.

**Mark Nottingham**: I'd encourage you to focus on the connection and
causality. Privacy Pass is a good exploration. Some of the others are
more tenuous, and you need to establish that to be credible.
Centralisation is a political topic, we need to be conscious of that.
I'd encourage you to be very concrete and to think about the
centralisation effects and causality.  
**Mark M**: Thanks for that, I'll take away your suggestion about more
concrete linkage between protocol design and effects. Privacy Pass is
interesting because the designers realised the problems, but went ahead
anyway.   
**Mark N**: With privacy - one of the few techniques we have to obscure
traffic is mixing it all together. Also need to acknowledge that not
standardising things doesn't mean they won't happen.  
**Mark M**: We make these kind of trade offs all the time, not just in
protocol design. Should acknowledge that somewhere.

**Diego Lopez**: Do you think it's feasible to maybe redesign protocols?

**Mark M**: We've had intermediaries forever, but things have changed.
Our design needs to establish a concrete link between new protocols and
impacts on consolidation.

## 4. Discussion of Issues (E2E etc.) Lixia Zhang, Dirk Kutscher 30 min   {#4-discussion-of-issues-e2e-etc-lixia-zhang-dirk-kutscher-30-min}

### Is the End-to-End argument in system design still needed?   {#is-the-end-to-end-argument-in-system-design-still-needed}

Speaker: **Lixia Zhang** (as individual)  
Inspired by Mark M's draft - "rapidly the end-to-end principle is
becoming the edge-to-edge principle". There are people who share these
views, there's a popular youtube video. In late 90s Lixia coined the
word middlebox (Notetaker's view - that's cool.). Papers on this topics
go back to the early 80s.

Internet started without middle boxes. No address shortage so no NAT,
few users so no need for scalable content distribution, low security
concerns so no firewalls. There were attempts to enhance network for
better delivery, nothing succeeded. Mid/late 90s - middleboxes showed up
which manipulated packets e.g. NAT, firewalls. Today there are loads of
middleboxes, internet wouldn't work without them. Middleboxes,
particularly CDNs and security enhancements , are incrasingly provided
by dominant players. We need to understand what the End-to-End argument
means to properly discuss whether we need it or not.

From paper: The function in question can completely and correctly be
implemented only with the knowledge and help of the application at the
end points of the comunication system. Therefore, providing that
questioned function as a feature of the communication system itself is
not possible.

I think the end-to-end principle remains essential.

What, if any, are the functions that can't be done in the middle? Look
at popular middleboxes today - NAT, proxies for mobility/performance,
CDNs, security. Note that some of the about intercept end-to-end TLS,
particularly CDNs and security services.

Note, distributed applications can move us away from centralisation.
Problem is that we don't have enabled primitives to allow edge devices
to communicate with each other. Can we have smart homes that don't
depend on cloud services? The cloud is useful, but that's not the same
as being controlled by the cloud e.g. I can encrypt my files when stored
in the cloud. But my identity is controlled by Google. How do we get
from here (being controlled) to there (using services, not controlled).
We should explore that.

#### Discussions:   {#discussions}

**Dirk K.**: Middle boxes are different — Middleboxes used to
manipulate, but now, 'middleboxes' of today like CDN endpoints are
terminating the connection, then initiating another to the origin.
Perhaps this is still end-to-end of some form.  
**Lixia Z.**: Not sure if that's the case. TLS authentication is not
through to the origin server.  
**Dirk K.**: So TLS is delegated to those servers  
**Lixia Z.**: That means I don't have end-to-end secrecy between myself
and the origin server

**Haiguang Wang**: We can't have E2E connection today because we don't
have global IP addresses. Also, we don't have identity. Users don't have
certificates. Unless one day we can assign credentials to individual
users and have global IP addresses we can't have device to device
connection.  
**Lixia**: Agree about the identity issue. But whether we need global IP
addresses I'm not sure. Certificates are issued to names not addresses. 

**Haiguang**: Certs issued to domain names but as a person I don't have
a domain name.  
**Lixia**: You can get one.  
**Colin Perkins**: You don't have an IP address either.  
**Lixia**: IP addresses are very dynamic, as opposed to domain name
identifiers.  
**Haiguang**: Issue is that we have to pay for domain names currently.

**Colin Perkins**: Interesting questions for naming and identity here.
You should be careful what you wish for if you want to give everyone a
unique name. Discussion on E2E argument is interesting. We always run
into question about what the endpoints are. I worry that we don't have
enough terminology, we're trying to apply old terms to modern networks.

**Richard Li**: Research like ICN (Information Centric
Networking)\[note: Lixia is working on NDN, a type of ICN system, they
are connectionless\] is a clear violation of the E2E principle. We don't
know where it will be terminated. This principle isn't important any
more, we have to go beyond that. There are real problems, some of which
are due to end-to-end principle e.g. can increase latency. I see values
violating the end-to-end principle.  
**Lixia**: I think CDNs are a violation of the E2E principle. ICN/NDN is
actually building the E2E principle back. As a network you just
distribute the data. ICN/NDN is about data not connection. and data is
secured E2E.  
**Richard**: We need to define the end-to-end principle.  
**Lixia**: Stated very clearly in the paper.  
**Dirk**: Let's take this offline in the interest of time.

**Arnaud Taddei**: Happy you're presenting this. History is useful. When
we did IMAP we realised there was a risk of centralisation. I'm
concerned about security and the prioritisation of privacy at the
expense of security.  
**Lixia**: Security and privacy is a great topic to discuss, contact me.

**Marie-Jose Montpetit**: People say that by adding computing we're
breaking the end-to-end principle, what's your position on that?  
**Lixia**: Another great topic.

**Erik Nordmark**: Great topic. One question, where are the actual ends?
It's complicated. Need more taxonomy.  
**Lixia**: It's a policy decision, do you trust the CDN or not? We
should support different policies.

**Colin Perkins**: Ends aren't so much a physical place as who is in
control of the data. Models are poorly defined.

**Dirk K.**: We'll have charter discussion first, then see if we have
time for the taxonomy discussion.

## 5. DINRG Charter Discussion   {#5-dinrg-charter-discussion}

### DINRG History:   {#dinrg-history}

Firstly wanted to understand applicability and constraints of certain
technology, then systematic analysis of centralisation became more
relevant. Had workshop in 2021. Noted two major contributing factors -
economies of scale and security threats.

### Re-chartering proposal:   {#re-chartering-proposal}

working on identifying and mitigating internet centralisation. Evolving
group to be focal point for discussions around internet
(de)centralisation. Had IAB review earlier this week. Perhaps rename
group to “Decentralization of Internet Research Group” \[note: from the
current name "Decentralized Internet Infrastructure"\]. Main objectives
focused on measurement, characterisation and impacts of centralisation.
Want to provide advice to legislators. Still want DINRG to be space for
new research ideas and technical solutions. People dismiss
decentralisation and equate it with blockchain - that's not very useful.
Want to document outcomes of the above in a useful way.

Got feedback on mailing list, would like to continue the discussion
today. People like the fact the charter is clearer, more concise and
doesn't mention specific technologies. Shouldn't prevent bringing
dedicated technologies, as long as decentralisation aspect highlighted.
It was suggested that technical solutions aimed at improving
decentralisation aren't just for RG but it could be a focal point. Need
to think about that more. One comment said that blockchain and internet
centralisation are too different for a recharter, needs a new group.
Discussed this with IAB and IRTF Chair. The idea of this group has
always been to look at internet centralisation. It started on specific
technologies, but it's shifted over the last two years. We don't think a
new group is necessary, we've been working on this for two years and we
have the right people in the group.

Feedback from IAB review: Think about how to achieve these objective and
develop specific approaches to engage research community. What are these
communities and what communities are we missing? E.g. might need new
experts for economics discussion.

### Discussion:   {#discussion}

**Niels ten Oever**: Work in IAB faltered. I think there were a lack of
economists and legal experts. It's difficult to get these people to
provide solutions. How are you going to address this issue?  
**Lixia**: Some suggestions on slides. We need to explain the goal of
this group to others. Disseminate goal of group and proactively reach
out. Thanks for an excellent suggestion.  
**Dirk**: Research groups are contribution driven, so don't just wait
for Lixia and me to get work started, we need you input. We could do
unusual things e.g. invitation only workshops.

**Mark McFadden**: I support rechartering. Refocusing will be
constructive. I will contribute effort. Group needs drafts. 2021
workshop was successful, but not much has been built on top since. It
would be valuable and important to continue the work and build further.
I don't think this needs a complete re-write, re-construction. But
rechartering is still a good idea.  
**Dirk**: Would be really useful to have document with issues and
threats, and one group that calls this out.

**Colin**: I am happy to support re-chartering. Neil and IAB to some
extent highlighted the issue: make sure to consult widely, work with IAB
to get the wider perspective.

**Niels**: Work in IAB went wrong because different understanding of
centralisation existing. Could do a literature review/taxonomy. At least
then we know what we're talking about. I'm happy to contribute to that. 

**Dirk**: This is a highly political topic. We need to think about most
productive way to produce useful and interesting results. I think what
Geoff Huston mentioned earlier could be important. Don't try to arrive
at harmonised view to early, allow for different opinions.  
**Colin**: In IRTF we can publish documents with particular viewpoints
provided it's clear where they're coming from.

## 6. Taxonomy Discussion   {#6-taxonomy-discussion}

Cut due to time.

Meeting end: 11:30