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

Hi, Theresa,

On Thu, Oct 25, 2018 at 3:14 AM Theresa Enghardt <theresa@inet.tu-berlin.de>
wrote:

> 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:
>
>
>>
>> (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.
>>
>
> 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?
>
> 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 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"
> https://tools.ietf.org/id/draft-tuexen-tsvwg-sctp-multipath-16.txt
> _______________________________________________
> Panrg mailing list
> Panrg@irtf.org
> https://www.irtf.org/mailman/listinfo/panrg
>