draft-arkko-path-signals-information.md   draft-iab-path-signals-collaboration.md 
--- ---
title: Considerations on Information Passed between Networks and Applications title: Considerations on Application - Network Collaboration Using Path Signals
abbrev: Path Signals Info abbrev: Path Signals Collab
docname: draft-arkko-path-signals-information-latest docname: draft-iab-path-signals-collaboration-latest
date: date:
category: info category: bcp
ipr: trust200902 ipr: trust200902
keyword: Internet-Draft keyword: Internet-Draft
stand_alone: yes stand_alone: yes
pi: [sortrefs, symrefs] pi: [sortrefs, symrefs]
author: author:
- -
ins: J. Arkko ins: J. Arkko
name: Jari Arkko name: Jari Arkko
org: Ericsson org: Ericsson
email: jari.arkko@ericsson.com email: jari.arkko@ericsson.com
-
ins: T. Hardie
name: Ted Hardie
org: Cisco
email: ted.ietf@gmail.com
-
ins: T. Pauly
name: Tommy Pauly
org: Apple
email: tpauly@apple.com
-
ins: M. Kühlewind
name: Mirja Kühlewind
org: Ericsson
email: mirja.kuehlewind@ericsson.com
normative: normative:
informative: informative:
RFC0793: RFC0739:
RFC5218: RFC5218:
RFC6709: RFC6709:
RFC7305: RFC7305:
RFC8558: RFC8558:
I-D.ietf-quic-transport: I-D.ietf-quit-transport:
I-D.irtf-panrg-what-not-to-do: I-D.irtf-panrg-what-not-to-do:
I-D.per-app-networking-considerations: I-D.per-app-networking-considerations:
I-D.iab-covid19-workshop: I-D.iab-covid19-workshop:
title: "Report from the IAB COVID-19 Network Impacts Workshop 2020" title: "Report from the IAB COVID-19 Network Impacts Workshop 2020"
author: author:
- ins: J. Arkko - ins: J. Arkko
- ins: S. Farrell - ins: S. Farrell
- ins: M. Kuhlewind - ins: M. Kühlewind
- ins: C. Perkins - ins: C. Perkins
date: February 2021 date: February 2021
seriesinfo: "Internet Draft (Work in Progress), draft-iab-covid19-workshop, IETF" seriesinfo: "Internet Draft (Work in Progress), draft-iab-covid19-workshop, IETF"
--- abstract --- abstract
Path signals are messages seen by on-path elements examining transport Path signals are messages seen by on-path elements examining transport
protocols. Current preference for good protocol design indicates protocols. Current preference for good protocol design indicates
desire for constructing explict rather than implicit signals to carry desire for constructing explict rather than implicit signals to carry
information. For instance, the ability of various middleboxes to read information. For instance, the ability of various middleboxes to read
TCP messaging was an implicit signal that lead to difficulties in TCP messaging was an implicit signal that lead to difficulties in
evolving the TCP protocol without breaking connectivity through some evolving the TCP protocol without breaking connectivity through some
of those middleboxes. of those middleboxes.
This document discusses the types of information that could be passed This document discusses how information could be passed in these path
in these path signals, and provides some advice on what types of signals, and provides some advice on what collaboration modes might be
information might be provided in a beneficial manner, and which beneficial, and which might be less likely to be used by applications
information might be less likely to be revealed or used by or networks.
applications or networks.
--- middle --- middle
# Introduction # Introduction
{{RFC8558}} discusses the topic of path signals: Path signals are {{RFC8558}} discusses the topic of path signals: Path signals are
messages seen by on-path elements examining transport protocols. messages seen by on-path elements examining transport protocols.
There's a difference between implicit and explicit signals. For There's a difference between implicit and explicit signals. For
instance, TCP's well-known messages {{RFC0793}} are in the clear, and instance, TCP's well-known messages {{RFC0793}} are in the clear, and
often interpreted in various ways by on-path elements. In contrast, often interpreted in various ways by on-path elements. In contrast,
QUIC protects almost all of this information, and hence end-to-end QUIC protects almost all of this information, and hence end-to-end
signaling becomes opaque for network elements in between. QUIC signaling becomes opaque for network elements in between. QUIC
does provide some information, but has chosen to make these does provide some information, but has chosen to make these
signals (such as the Spin bit) explicit {{I-D.ietf-quic-transport}}. signals (such as the Spin bit) explicit {{I-D.ietf-quic-transport}}.
Many attempts have been made at network - application collaboration Many attempts have been made at network - application collaboration
using path signals. Section 2 discusses some of the experiences and using path signals. Section 2 discusses some of the experiences and
guidelines determine from those attempts. This draft then focuses guidelines determine from those attempts. This draft then focuses on
on the specific question of what kind of data can be passed. the specific question of what collaboration modes are useful. The
draft attempts to provide guidance in the form of architectural
principles.
# Past Experiences and Guidance # Past Guidance
Incentives are a well understood problem in general but perhaps not Incentives are a well understood problem in general but perhaps not
fully internalised for various collaborative like designs. The fully internalised for various collaborative like designs. The
principle is that both receiver and sender of information must acquire principle is that both receiver and sender of information must acquire
tangible and immediate benefits from the communication, such as tangible and immediate benefits from the communication, such as
improved performance, improved performance,
A related issue is understanding whether there is or is not a business A related issue is understanding whether there is or is not a business
model or ecosystem change. Some designs may work well without any model or ecosystem change. Some designs may work well without any
monetary or payment or cross-administrative domains agreements. For monetary or payment or cross-administrative domains agreements. For
skipping to change at line 120 skipping to change at line 139
There are also more general guidance documents, e.g., {{RFC5218}} There are also more general guidance documents, e.g., {{RFC5218}}
discusses protocol successes and failures, and provides general advice discusses protocol successes and failures, and provides general advice
on incremental deployability etc. Internet Technology Adoption and on incremental deployability etc. Internet Technology Adoption and
Transition (ITAT) workshop report {{RFC7305}} is also recommended Transition (ITAT) workshop report {{RFC7305}} is also recommended
reading on this same general topic. And {{RFC6709}} discusses protocol reading on this same general topic. And {{RFC6709}} discusses protocol
extensibility, and provides general advice on the importance of global extensibility, and provides general advice on the importance of global
interoperability and so on. interoperability and so on.
# Principles # Principles
This section attempts to provide some further guidelines, relating to This section attempts to provide some architecture-level principles
information that can be passed in path signals. Hopefully, these that would help future designers, explain past issues and recommend
guidelines can help future designers, explain past issues and useful models to apply.
recommend useful models to apply.
...
## Parties Need to Consent
...
## Information Specificity ## Information Specificity
One common problem in finding a workable solution for network - One common problem in finding a workable solution for network -
application collaboration is information leakage. All parties are application collaboration is information leakage. All parties are
afraid of either their own propietary information or the users' data afraid of either their own propietary information or the users' data
leaking to others. Oddly enough, no one is usually worried about leaking to others. (Oddly enough, no one is usually worried about
users' data leaking to themselves, but I digress. :-) users' data leaking to themselves, but I digress. :-) )
{{I-D.per-app-networking-considerations}} discusses how applications {{I-D.per-app-networking-considerations}} discusses how applications
may be identified through collaboration mechanisms. This can be may be identified through collaboration mechanisms. This can be
harmful, as in extreme cases it may lead to undesirable prioritization harmful, as in extreme cases it may lead to undesirable prioritization
decisions or even blocking certain decisions or even blocking certain
applications. {{I-D.per-app-networking-considerations}} explains how applications. {{I-D.per-app-networking-considerations}} explains how
to reduce the latter problem by categories or requested service rather to reduce the latter problem by categories or requested service rather
than specific application identity, such as providing the category than specific application identity, such as providing the category
"video call service" rather than the name of a particular application "video call service" rather than the name of a particular application
performing conference call or video call services. This points to a performing conference call or video call services. This points to a
skipping to change at line 153 skipping to change at line 177
information that is needed for the other party to perform the information that is needed for the other party to perform the
collaboration task that is desired by this party, and not more. This collaboration task that is desired by this party, and not more. This
applies to information sent by an application about itself, applies to information sent by an application about itself,
information sent about users, or information sent by the network. information sent about users, or information sent by the network.
An architecture can follow the guideline from RFC 8558 in using An architecture can follow the guideline from RFC 8558 in using
explicit signals, but still fail to differentiate properly between explicit signals, but still fail to differentiate properly between
information that should be kept private and information that should be information that should be kept private and information that should be
shared. shared.
In looking at what information can or cannot easily be passed, we ## Authenticating Discussion Partners
can look at both information from the network to the application,
and from the application to the network.
For the application to the network direction, user-identifying (even outside the client and server)
information can be problematic for privacy and tracking reasons.
Similarly, application identity can be problematic, if it might form
the basis for prioritization or discrimination that the that
application provider may not wish to happen. It may also have
undesirable economic consequences, such as extra charges for the
consumer from a priority service where a regular service would have
worked.
On the other hand, as noted above, information about general classes ...
of applications may be desirable to be given by application providers,
if it enables prioritization that would improve service, e.g.,
differentiation between interactive and non-interactive services.
For the network to application direction there's less directly ## Authentication does not equal Trust
sensitive information. Various network conditions, predictive
bandwidth and latency capabilities, and so on might be attractive
information that applications can use to determine, for instance,
optimal strategies for changing codecs.
However, care needs to be take to ensure that neither private ...
information about the individual user (such as user's physical
location) is not indirectly exposed through this
information. Similarly, this information should not form a mechanism
to provide a side-channel into what other users are doing.
## Granularity ## Granularity
In the IAB Covid-19 Network Impacts workshop Jana Iyengar brought up In the IAB Covid-19 Network Impacts workshop Jana Iyengar brought up
the granularity of operations {{I-D.iab-covid19-workshop}}. There are the granularity of operations {{I-D.iab-covid19-workshop}}. There are
many reasons why per-flow designs are problematic: scalability, need many reasons why per-flow designs are problematic: scalability, need
to release information about individual user’s individual activities, to release information about individual user’s individual activities,
etc. Perhaps designs that work on aggregates would work better. etc. Perhaps designs that work on aggregates would work better.
## Incentives and Business Models
Incentives are a well understood problem in general but perhaps
not fully internalised for APN or QoS-like designs; a principle might
be that both receiver and sender of information must acquire tangible
and immediate benefits from the communication, such as improved
performance,
A related issue is understanding whether there is or is not a business
model or ecosystem change. Some designs may work well without any
monetary or payment or cross-administrative domains agreements. For
instance, I could ask my packets to be prioritised relative to each
other and that shouldn’t affect anything else. Some other designs may
require a matching business ecosystem change to support what is being
proposed, and may be much harder to achieve. For instance, requesting
prioritisation over other people’s traffic may imply that you have to
pay for that which may not be easy even for a single provider let
alone across many.
# Acknowledgments # Acknowledgments
The author would like to thank Mirja Kuhlewind, Tommy Pauly, Ted The authors would like to thank everyone at the IETF, the IAB, and our day jobs for interesting thoughts and proposals in this space.
Hardie, David Allan, Brian Trammell, Szilvezter Nadas, Zaheduzzaman
Sarker, Joel Halpern, Magnus Westerlund, Jana Iyengar and Balaz Varga
for interesting thoughts and proposals in this space.
 End of changes. 18 change blocks. 
46 lines changed or deleted 69 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/