Subject: [PANRG] I-D Action: draft-irtf-panrg-what-not-to-do-00.txt

From: [email-masked]
Date: Mon, 15 Oct 2018 15:02:48 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Path Aware Networking RG RG of the IRTF.

        Title           : Path Aware Networking: Obstacles to Deployment (A Bestiary of Roads Not Taken)
        Author          : Spencer Dawkins
	Filename        : draft-irtf-panrg-what-not-to-do-00.txt
	Pages           : 20
	Date            : 2018-10-15

Abstract:
   At the first meeting of the Path Aware Networking Research Group,
   Oliver Bonaventure led a discussion of mostly-unsuccessful attempts
   to exploit Path Awareness to achieve a variety of goals, for a
   variety of reasons, over the past decade.  At the end of that
   discussion, the research group agreed to catalog and analyze these
   ideas, in order to extract insights and lessons for path-aware
   networking researchers.

   This document contains that catalog and analysis.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-irtf-panrg-what-not-to-do-00
https://datatracker.ietf.org/doc/html/draft-irtf-panrg-what-not-to-do-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 16 Oct 2018 09:51:57 -0400

I had a chance to look at this draft, and here are some comments:

(1) Section 4.1.2 on RSVP says: "BGP uses Flow Specs to distribute 
firewall filters.

That's not quite right.  BGP flowspecs (RFC 5575) are not related to 
RSVP flowspecs.  The same term is used for different things, unfortunately.

(2) Would it make sense to say anything about XCP, PCN, or CONEX?

(3) In the shim6 discussion in Section 4.4.1, I'm not sure what is meant 
by "file descriptions with associated HTTP state" ... something is 
missing in the description of the problem, because HTTP is mentioned out 
of nowhere.

(4) Section 4.4.2 talks about SCTP and MPTCP somehow, but I don't think 
those are really related to shim6 as coherently as the text might imply 
(they're transport layer versus network layer), nor do I think those are 
really "path aware" in any meaningful way.  They know about multiple 
interfaces locally, which lets them possibly use multiple paths, but 
they're not really aware of anything about the innards of those paths in 
the way that other technologies mentioned are.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 16 Oct 2018 18:13:08 -0500

Hi, Wes,

> I had a chance to look at this draft, and here are some comments:

Thank you for that.

> RSVP flowspecs.  The same term is used for different things, unfortunately.

I'm editing some of the subsections on protocols outside my area of
expertise, so especially appreciate guidance like this. I'll investigate
further.

Keeping in mind that the RG now owns the draft, my thinking is that we
should include subsections for path-aware proposals that add to the Lessons
Learned listed in Section 2 - if any of these protocols faced obstacles to
deployment that aren't already on the list in Section 2, adding subsections
using the template in Section 3 would be helpful and appreciated.

> missing in the description of the problem, because HTTP is mentioned out

Shim6 is actually one of the proposals I was involved with, when it was
being worked on, so that made more sense to me (with context) than it would
to most people (without context). Thanks for calling this out - I'll
definitely look at it.

> the way that other technologies mentioned are.

So, that section was pretty much Spencer's Opinion. Here's what I was
trying to get at:

   - Shim6 put interface selection (which, if you're multihomed to multiple
   providers, gives you pretty disjoint paths to choose from) under host
   control, without any particular reason to believe that hosts know much
   about which path should be preferred.
   - Operators were not happy at the idea that hosts (and, especially in
   2009, hosts that might be controlled by malicious attackers) might be
   swinging significant amounts of traffic onto, and off of, their network
   paths, with no coordination with the operator. The doomsday scenario was
   something like a few tens of thousands of hosts in a botnet simultaneously
   redirecting all their outgoing packets from the interface connected to
   Provider A to the interface connected to Provider B.
   - SCTP and MP-TCP also put interface selection (and, so, path selection)
   under host control, and hosts running these protocols don't know much about
   the paths, either.
   - For some reason I don't understand, operators haven't responded to
   hosts selecting interfaces for SCTP and MP-TCP as negatively as they did to
   hosts doing what seemed like the same thing for Shim6.

I might be missing something (that happens, I have references if you need
them), or it might be that this isn't useful to point out, so no reason to
fix the text, of course.

But does that make sense to you?

Thanks,

Spencer

---

From: Theresa Enghardt <[email-masked]>
Date: Thu, 25 Oct 2018 10:13:58 +0200

Hi,

just my two cents on path selection in SCTP and MPTCP vs. Shim6:

On 17.10.18 01:13, Spencer Dawkins at IETF wrote:
>   * Shim6 put interface selection (which, if you're multihomed to
>     multiple providers, gives you pretty disjoint paths to choose
>     from) under host control, without any particular reason to believe
>     that hosts know much about which path should be preferred.
>   * Operators were not happy at the idea that hosts (and, especially
>     in 2009, hosts that might be controlled by malicious attackers)
>     might be swinging significant amounts of traffic onto, and off of,
>     their network paths, with no coordination with the operator. The
>     doomsday scenario was something like a few tens of thousands of
>     hosts in a botnet simultaneously redirecting all their outgoing
>     packets from the interface connected to Provider A to the
>     interface connected to Provider B.
>   * SCTP and MP-TCP also put interface selection (and, so, path
>     selection) under host control, and hosts running these protocols
>     don't know much about the paths, either.
>   * For some reason I don't understand, operators haven't responded to
>     hosts selecting interfaces for SCTP and MP-TCP as negatively as
>     they did to hosts doing what seemed like the same thing for Shim6.
>
> I might be missing something (that happens, I have references if you
> need them), or it might be that this isn't useful to point out, so no
> reason to fix the text, of course.
>

I see value in comparing end-host based path selection between Shim6 and
SCTP/MPTCP in the draft, if only to point out the advantage of
implementing this on the transport layer instead of the network layer.

Recently I've discussed this with my professor, and we think the key
reason is that on the transport layer, there's a lot of work done on
fairness and how to distribute traffic across paths [0]. Perhaps that
reduces the perceived danger of suddenly flooding the network, and maybe
that has something to do with there being fewer negative response from
operators.

If we're missing something here, please tell me. Also, I'm interested in
those references.

Thanks,
Theresa

[0] Personally I would point to work such as "MPTCP is not
pareto-optimal" https://hal.inria.fr/hal-01086030/document or "Load
Sharing for SCTP"
https://tools.ietf.org/id/draft-tuexen-tsvwg-sctp-multipath-16.txt

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 25 Oct 2018 08:10:02 -0500

Hi, Theresa,

On Thu, Oct 25, 2018 at 3:14 AM Theresa Enghardt <[email-masked]>
wrote:

>    - Shim6 put interface selection (which, if you're multihomed to
>    multiple providers, gives you pretty disjoint paths to choose from) under
>    host control, without any particular reason to believe that hosts know much
>    - SCTP and MP-TCP also put interface selection (and, so, path
>    selection) under host control, and hosts running these protocols don't know
>    much about the paths, either.
> SCTP/MPTCP in the draft, if only to point out the advantage of implementing
> this on the transport layer instead of the network layer.
>
Thanks for these comments, and I'll definitely have this point, as well as
Wes's other comments, on my list to talk about at IETF 103 in a couple of
weeks.

I am balancing between what's in scope for this draft, and what's not, but
would be in scope for other drafts in PANRG, as I understand the PANRG
scope from the chairs and from Allison, so I'll try to do the right thing
with this comment - whatever that is :-)

And the chairs are happy to tell me when I'm confused. I can provide e-mail
archive URLs on request :D

Spencer

> Thanks,
> Theresa
>
>
> [0] Personally I would point to work such as "MPTCP is not pareto-optimal"
> https://hal.inria.fr/hal-01086030/document or "
> <https://hal.inria.fr/hal-01086030/documentor>Load Sharing for SCTP"
> _______________________________________________
> Panrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/panrg
>