Subject: [Stackevo] the future of path signals

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 6 Sep 2017 11:08:27 +0200

Hi, all,

I've taken a look at the path signals draft for the first time in a little while, with an eye toward what we should do with it. It seems to me that if we'd like to make this a statement for the IAB to make, that Section 5 should serve as the basis of it, with abbreviated examples from Section 3 and further guidance from section 4. With some I've-only-had-one-coffee-for-some-reason editing, something like:

Most widely deployed transport protocols in the Internet currently do not encrypt their headers. This visibility of headers to network elements has led to their use as implicit signals for a variety of in-network functions, such as firewalls which infer end-to-end connection state by observing TCP flags, or passive measurement of application latency. The binding of these implicit signals to related but distinct end-to-end protocol functions causes a variety of problems, including a difficulty in deploying new versions of protocols or protocol extensions which interfere with the inferred meanings of certain header bits.

The encryption of transport protocol headers, to reinforce the boundary between network-visible and end-to-end information, is a promising approach to solve these problems, but raises the question of what to do with the network functions using inferences based on current implicit signals.

In principle, these implicit signals should be removed from future transports and, where necessary, replaced with explicit signals. An explicit signal should be exposed to the path only when the signal's originator intends that it be used by the network elements on the path. In some cases, the correct choice is to remove the implicit signal without replacement, while in other cases the implicit signal should be replaced with an explicit signal tailored to the desired usage by elements on the path, whether in an unencrypted part of the transport layer header, or in a network layer header or extension.

On the other hand, if we'd like an IAB stream RFC, IMO it's ready to go. At the IAB/IESG retreat in Montreal in May we determined that in order for the discussion to go further, we need to spend some time with the details of each proposed signal. The QUIC RTT DT is presently doing this for one particular implementation of RTT exposure for QUIC, but there are probably only design and implementation questions to ask and answer about each of the other potential explicit signal; i.e., all the details work is a research project, not a matter of architecture.

Since all these signals save the basic flow state information are in essence properties of the path as well as of the traffic, the PAN proposed RG might be a good home to do this work -- though we still need to find people willing to do it.

Cheers,

Brian

---

From: Lee Howard <[email-masked]>
Date: Wed, 06 Sep 2017 15:53:29 -0400

On 9/6/17, 5:08 AM, "Stackevo on behalf of Brian Trammell (IETF)"
<[email-masked] on behalf of [email-masked]> wrote:

>Hi, all,
>
>I've taken a look at the path signals draft for the first time in a
>little while, with an eye toward what we should do with it. It seems to
>me that if we'd like to make this a statement for the IAB to make, that
>Section 5 should serve as the basis of it, with abbreviated examples from
>Section 3 and further guidance from section 4. With some
>I've-only-had-one-coffee-for-some-reason editing, something like:
>
>
>Most widely deployed transport protocols in the Internet currently do not
>encrypt their headers. This visibility of headers to network elements has
>led to their use as implicit signals for a variety of in-network
>functions, such as firewalls which infer end-to-end connection state by
>observing TCP flags, or passive measurement of application latency. The
>binding of these implicit signals to related but distinct end-to-end
>protocol functions causes a variety of problems, including a difficulty
>in deploying new versions of protocols or protocol extensions which
>interfere with the inferred meanings of certain header bits.
>
>The encryption of transport protocol headers, to reinforce the boundary
>between network-visible and end-to-end information, is a promising
>approach to solve these problems, but raises the question of what to do
>with the network functions using inferences based on current implicit
>signals.
>
>In principle, these implicit signals should be removed from future
>transports and, where necessary, replaced with explicit signals. An
>explicit signal should be exposed to the path only when the signal's
>originator intends that it be used by the network elements on the path.
>In some cases, the correct choice is to remove the implicit signal
>without replacement, while in other cases the implicit signal should be
>replaced with an explicit signal tailored to the desired usage by
>elements on the path, whether in an unencrypted part of the transport
>layer header, or in a network layer header or extension.
>

The draft's note on reusability (let’s make a set of signals thats common
between mutliple transports) should note that we would then ossify on
those bits or mechanisms being the ones available. It also notes that if
each protocol develops its own path signal, it risks being the bone on
which future protocols ossify. Which is kind of what we have now, with
QUIC etc. using UDP not because it’s good but because it can get through
firewalls.

>
>
>On the other hand, if we'd like an IAB stream RFC, IMO it's ready to go.
>At the IAB/IESG retreat in Montreal in May we determined that in order
>for the discussion to go further, we need to spend some time with the
>details of each proposed signal. The QUIC RTT DT is presently doing this
>for one particular implementation of RTT exposure for QUIC, but there are
>probably only design and implementation questions to ask and answer about
>each of the other potential explicit signal; i.e., all the details work
>is a research project, not a matter of architecture.
>
>Since all these signals save the basic flow state information are in
>essence properties of the path as well as of the traffic, the PAN
>proposed RG might be a good home to do this work -- though we still need
>to find people willing to do it.

I’m torn on this. I think it would be a sound IAB statement, if we could
get consensus.
But I’d like to hear broader review, and PANRG sounds like a good place to
get that.

Lee

---

From: Martin Thomson <[email-masked]>
Date: Thu, 7 Sep 2017 10:12:51 +1000

I would prefer an IAB stream document here.  If only because that
becomes easier to reference.

The draft includes a bunch more nuance that I think is valuable, such
as the bone Lee mentions.

I haven't done a good hard review in a while.  I can't commit to doing
that in the next two weeks (a good portion of that time is allocated
for the beach), but would like to do so.  My recollection of my last
read through was "yes, this is good, but..." with the "but" being a
vague sort of unease, but I couldn't tell you if it was purely
editorial or not without spending some good thinkin' time on this and
I have close to 20 outstanding patches that need some loving and
attention that take priority.

On Thu, Sep 7, 2017 at 5:53 AM, Lee Howard <[email-masked]> wrote:
> _______________________________________________
> Stackevo mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/stackevo