Subject: [PANRG] Performance Implications of PATH CHaracteristics (PIPC) Brainstorming session at IETF 104

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 28 Mar 2019 16:20:44 -0500

Earlier tonight, I held the brainstorming session on PIPC that I announced
at HotRFC on Sunday night.

Tl;Dr

We have work to do.
It's related to path awareness.
We'd like to use the PANRG mailing list while we get organized.

The details ...

Co-conspirators:

Spencer Dawkins
Aaron Falk
Marcus Ihlar
JianJian Zhu
Michael Scharf
Joerg Deutschmann
John Border
Chi-Jiun Su
Zaheduzzaman Sarker
Anna Brunstrom
Nicolas Kuhn
Zhen Cao
emile stephan
Szilveszter Nadas

Agenda, ripe for bashing

We all know the story of the PILC working group, right? Questions I was
hoping to check on for about 45 minutes

Is it time for a discussion about paths and performance?

Are path characteristics different from link characteristics? We think so.
We were trying to give advice to link designers
Pervasice encryption before we figure out how to delegate trust (network is
potentially an attacker).
Multipath protocols are a lOT more common, and different paths may have
wildly different characteristics.
Packet-level Network Coding/FEC is a lot more realistic than it was in
2002.
We fixed satellites, but the wifi network in front of the satellite link is
now where the packet loss is happening.
How many levels are we having problems at? TLS means web acceleration stops
working but TCP repair continues to work.
Berkeley survey of middleboxes.
CDNs are new
Multipath plus TCP splitting on one path breaks things - window sizes are
wrong, etc.
Problematic path segments could be in series or in parallel, and
collections of problematic segments could be in series or in parallel.

What problems should be in scope?

Worth cleaning up BCP advice from 20 years ago.
But we do have new problems, too
TAPS is starting to look at policy. Policies for path selection and usage
is a general multipath problem.

Are we talking about providing guidance on protocol use, or about inventing
or extending protocols? Translation: are there gaps in protocols, or gaps
in practice using those protocols?

We think we could be producing BCPs.

What is research, and what is engineering?

Even figuring that out is probably research ...

Which parts of the problem space fit in already-chartered WGs/RGs.

We can figure that out as we go, as long as we have a place to start
(PANRG, we hope you won't mind too much).

What are next steps between IETF 104 and IETF 105?

Request a new mailing list - actually we suspect that all this is in scope
for PANRG
Spencer to heads-up the PANRG chairs
Spencer to do a write-up about this for PANRG list

---

From: Markku Kojo <[email-masked]>
Date: Thu, 28 Mar 2019 23:30:57 +0200 (EET)

Hi Spencer,

Couldn't join the brainstorming due to confilcting schedule. So, many 
thanks for the summary.

I'd be happy to contribute. Have also some background in PILC wg and 
otherwise ;)

Cheers,

/Markku

On Thu, 28 Mar 2019, Spencer Dawkins at IETF wrote:

> Earlier tonight, I held the brainstorming session on PIPC that I announced at HotRFC on Sunday
> night.
> 
> Tl;Dr
> 
> We have work to do.
> We all know the story of the PILC working group, right? Questions I was hoping to check on for
> about 45 minutes
> 
> Pervasice encryption before we figure out how to delegate trust (network is potentially an
> attacker)..
> Multipath protocols are a lOT more common, and different paths may have wildly different
> characteristics.
> Packet-level Network Coding/FEC is a lot more realistic than it was in 2002. 
> We fixed satellites, but the wifi network in front of the satellite link is now where the packet
> loss is happening. 
> How many levels are we having problems at? TLS means web acceleration stops working but TCP repair
> continues to work. 
> Multipath plus TCP splitting on one path breaks things - window sizes are wrong, etc. 
> Problematic path segments could be in series or in parallel, and collections of problematic
> segments could be in series or in parallel.
> 
> TAPS is starting to look at policy. Policies for path selection and usage is a general multipath
> problem. 
> 
> Are we talking about providing guidance on protocol use, or about inventing or extending
> protocols? Translation: are there gaps in protocols, or gaps in practice using those protocols?
> 
> Even figuring that out is probably research ....
> 
> We can figure that out as we go, as long as we have a place to start (PANRG, we hope you won't
> mind too much).
> 
> Request a new mailing list - actually we suspect that all this is in scope for PANRG