Subject: [Stackevo] Breakfast Tuesday Morning

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Thu, 12 Jul 2018 14:54:11 +0200

Greetings, all,

We have a meeting of the Stack Evolution Program on Tuesday morning 17 July in the IAB room, Saint-Denis. Meeting at 08:00, food available 07:30.

Our agenda this time is free-form (i.e. Brian was too lazybusy to actually put anything together); feel free to propose a concrete topic of discussion. If none arises, I'd propose we contemplate the following:

The program was chartered by the IAB to address the problem, perceived and actual, that new protocols (especially at layer 4 in its current incarnation) seemed difficult to impossible to deploy.

We (the IETF) are now apparently more optimistic about this proposition, at least as can be measured by both the work being done in the QUIC WG, as well as by semi-passive interest in that work. That optimism is driven by two aspects of the QUIC work, one technical (encrypting wire images is taken to make them ossification-nullifying and ossification-resistant) and one non-technical (the state of consolidation in Internet infrastructure at this layer in 2018 means that you don't need to convince many people to get something deployed, and the WG represents a large cross-section of the group of potential initial deployers).

I also see a bit more awareness in the IETF population (at least the tribes of it I interact with: the DNS aficionados, the security/management gurus, the applied networking researchers, the hackers; not so much the YANG enthusiasts) of the principles in 8170. Maybe they're not following them, but they're at least more aware that a deployment story is a good thing to have.

I suggested a meeting or two ago that these, taken together, might suggest that we can declare victory and wrap stackevo up. Nobody seemed to like that idea (hence next week's agendaless breakfast). I've started wondering whether these insights are unique to Layer 4, or whether they could be applied to other places the Internet is "stuck".

Cheers,

Brian

---

From: Lee Howard <[email-masked]>
Date: Sat, 14 Jul 2018 13:36:41 -0400

> We have a meeting of the Stack Evolution Program on Tuesday morning 17 July in the IAB room, Saint-Denis. Meeting at 08:00, food available 07:30.

I will only be in Montreal Saturday noon through Monday late afternoon, 
so I won't be there.

> We (the IETF) are now apparently more optimistic about this proposition, at least as can be measured by both the work being done in the QUIC WG, as well as by semi-passive interest in that work. Th…

Stuff above Layer 4 can be quickly adopted by getting a half dozen of 
the right people to agree. Browser and OS vendors, essentially. This is 
also true at Layer 4, though it may require more.

One reason for many of the assumptions that led to ossification was 
stateful firewall rules and/or NAT. Stateful firewalls blocked inbound 
TCP SYN by default, and NAT blocked everything unless a mapping rule 
state had been established (and then often allowed everything).
Stateful firewalls are still universally deployed at enterprises; the 
use of UDP for QUIC is specifically to bypass enterprise security policy.
I wonder if the deployment of IPv6, and the correlated reduction of NAT 
is (or should be) affecting the assumptions that led to ossification?

> I suggested a meeting or two ago that these, taken together, might suggest that we can declare victory and wrap stackevo up. Nobody seemed to like that idea (hence next week's agendaless breakfast)…

I'm not willing to say the stack is done, but it might be that the 
program is not needed for driving specific architectures. I've been 
asked to have the IAB issue an Internet Architecture, which I suppose 
would define what happens at different layers and how they interact, but 
I haven't given it too much thought, and am unlikely to put cycles into it.

Also, happy belated birthday, Brian.

Lee

>
> Cheers,
>
> Brian
>
>
>
> _______________________________________________
> Stackevo mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/stackevo

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sun, 15 Jul 2018 09:28:12 -0500

Hi, Brian,

On Thu, Jul 12, 2018 at 7:54 AM Brian Trammell (IETF) <[email-masked]>
wrote:

> Greetings, all,
>
> We have a meeting of the Stack Evolution Program on Tuesday morning 17
> July in the IAB room, Saint-Denis. Meeting at 08:00, food available 07:30.
>
> Our agenda this time is free-form (i.e. Brian was too lazybusy to actually
> put anything together); feel free to propose a concrete topic of
> discussion. If none arises, I'd propose we contemplate the following:
>
>
> The program was chartered by the IAB to address the problem, perceived and
> actual, that new protocols (especially at layer 4 in its current
> incarnation) seemed difficult to impossible to deploy.
>
> We (the IETF) are now apparently more optimistic about this proposition,
> at least as can be measured by both the work being done in the QUIC WG, as
> well as by semi-passive interest in that work. That optimism is driven by
> two aspects of the QUIC work, one technical (encrypting wire images is
> taken to make them ossification-nullifying and ossification-resistant) and
> one non-technical (the state of consolidation in Internet infrastructure at
> this layer in 2018 means that you don't need to convince many people to get
> something deployed, and the WG represents a large cross-section of the
> group of potential initial deployers).
>
> I also see a bit more awareness in the IETF population (at least the
> tribes of it I interact with: the DNS aficionados, the security/management
> gurus, the applied networking researchers, the hackers; not so much the
> YANG enthusiasts) of the principles in 8170. Maybe they're not following
> them, but they're at least more aware that a deployment story is a good
> thing to have.
>
> I suggested a meeting or two ago that these, taken together, might suggest
> that we can declare victory and wrap stackevo up. Nobody seemed to like
> that idea (hence next week's agendaless breakfast). I've started wondering
> whether these insights are unique to Layer 4, or whether they could be
> applied to other places the Internet is "stuck".
>

I'd like to thank the program for the work you've done, especially during
your first year when I was not a member of the program.

Here's what I'm thinking. Keep in mind that I've been wrong before.

   - I really like the work that program members have done, such as
   Martin's work on "Long-term Viability of Protocol Extension Mechanisms",
   and the work you/Ted will be talking about in TSVAREA this week ("Wire
   Images, Path Signals, And the (Inter)network ahead"). Maybe that's more
   properly done by the IAB itself, or maybe we need to be more helpful in
   this program that I've been so far, but I'd love to know the plan for that
   kind of thing.
   - We have a number of bits and pieces somewhere between Layer 3 and
   Layer 4 that we know how to do, except for the parts where they are broken.
   I'm thinking of ECN and Path MTU Discovery because they're both active
   topics in TSV now, but I'd be surprised if those were the only two. Is
   there anything we can do, to get the Internet from a place where those sort
   of work except when they don't, to a place where they work consistently?
   - We still don't have a good story for Network Management and/or Path
   Aware Networking in a post-Snowden world. We've kind of been hoping that
   would magically happen since PLUS, or the problem would magically go away,
   but it hasn't. Perhaps that is happening in
   https://www.iab.org/activities/programs/privacy-and-security-program/,
   although I'd be sad if it was and I knew nothing about it. But this is
   still broken. If the answer is that we need to stop trying to fix this and
   start trying to design networks that don't need this kind of help, that
   would also be useful to know.

Which brings up my next question - will there be remote participation for
the discussion in StackEvo this time?

Thanks,

Spencer

---

From: Dave Thaler <[email-masked]>
Date: Sun, 15 Jul 2018 20:52:09 +0000

Brian Trammell writes:
> feel free to propose a concrete topic of discussion

I have a topic to propose.  
draft-thaler-appsawg-multi-transport-uris is basically a problem statement, surveying various things people do today.
It was reviewed by artarea/dispatch back at IETF 99 and had support (all issues raised so far have been addressed), and I've been talking to Alexey and Adam about AD-sponsoring.

However, there's no actual recommendations, which would be a separate effort/doc, as discussed in artarea at IETF 99.
The W3C TAG tried and failed to get any consensus, so I'm not optimistic the IETF could either (and I'm not sure whether the IAB could either for that matter).

Adam wrote:
> I'll bend the ear of various IAB members to see whether they think there's hope of making progress on the second document you mention.

Since one of the main issues is how to deal with protocol stacks, it seems that the Stackevo program might the most logical program for such question.

Dave

---

From: "Aaron Falk" <[email-masked]>
Date: Mon, 16 Jul 2018 08:23:23 -0400

On 14 Jul 2018, at 13:36, Lee Howard wrote:

> I've been asked to have the IAB issue an Internet Architecture

wut?  can you expand?

--aaron

---

From: Dave Thaler <[email-masked]>
Date: Mon, 16 Jul 2018 21:46:30 +0000

Since undoubtedly someone will ask me to send pointers to this list after the discussion, I'll do so now.
Pre-reading anything before the meeting is not required.

Slides from IETF 99: https://datatracker.ietf.org/meeting/99/materials/slides-99-dispatch-mult-transport-uris-00
Minutes from IETF 99 artarea discussion: https://datatracker.ietf.org/meeting/99/materials/minutes-99-dispatch-00
Subsequent ART/URI-review thread (on one page): http://ietf.10.n7.nabble.com/art-Internet-Draft-Using-URIs-With-Multiple-Transport-Stacks-td538558.html 

During the program meeting, I plan to talk to slides 2-3 of the deck above, and verbally summarize 
what's in the other two links.  We can then discuss Adam's question to the IAB.

Dave

-----Original Message-----
From: Dave Thaler 
Sent: Sunday, July 15, 2018 4:52 PM
To: 'Brian Trammell (IETF)' <[email-masked]>; Stackevo <[email-masked]>
Subject: RE: [Stackevo] Breakfast Tuesday Morning

Dave

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 16 Jul 2018 17:37:55 -0500

> July in the IAB room, Saint-Denis. Meeting at 08:00, food available 07:30.

I haven't seen information about coordinates for remote participation in
this breakfast meeting.

What Mirja and I have been doing for a couple of side meetings so far, was
that she runs Skype on her laptop and calls me directly. Works great.

I believe that Mirja will be in the Tuesday breakfast meeting, so I'm
likely covered, but if other folks are also planning to participate
remotely, please reply to me, and I'll set up a WebEx conference using the
TSV AD bridge, or some such brilliant plan.

Looking forward to it, no matter how it happens.

Spencer

---

From: Eliot Lear <[email-masked]>
Date: Tue, 17 Jul 2018 14:29:30 +0200

Hi Dave,

I'm sorry I couldn't attend.  I think the draft is definitely timely and
worthwhile.  Maybe even overdue ;-). I particularly like your example on
slide 4.  One observation I would make: the IETF is in a good position
to codify the technical aspects of these schemes so as to keep them to a
minimum.  As a for instance. <hashofpublickey> doesn't seem to me to be
something that is particualrly unique to OCF.  What *could be* unique to
OCF is perhaps the algorithm that is used in the hash, but then perhaps
that is something that could be worked on if people care enough.

Anyway, just some thoughts.

Eliot

---

From: Dave Thaler <[email-masked]>
Date: Tue, 17 Jul 2018 13:10:54 +0000

Thanks Eliot.

Attached are the slides I used during breakfast (same slides as IETF 99, plus ones at the end with quotes from the email link).

-----Original Message-----
From: Eliot Lear <lear=[email-masked]> 
Sent: Tuesday, July 17, 2018 8:30 AM
To: Dave Thaler <[email-masked]>; Brian Trammell (IETF) <[email-masked]>; Stackevo <[email-masked]>
Subject: Re: [Stackevo] Breakfast Tuesday Morning

Hi Dave,

I'm sorry I couldn't attend.  I think the draft is definitely timely and worthwhile.  Maybe even overdue ;-). I particularly like your example on slide 4.  One observation I would make: the IETF is in a good position to codify the technical aspects of these schemes so as to keep them to a minimum.  As a for instance. <hashofpublickey> doesn't seem to me to be something that is particualrly unique to OCF.  What *could be* unique to OCF is perhaps the algorithm that is used in the hash, but then perhaps that is something that could be worked on if people care enough.

Eliot

On 16.07.18 23:46, Dave Thaler wrote:
> Slides from IETF 99: 
> https://datatracker.ietf.org/meeting/99/materials/slides-99-dispatch-m
> ult-transport-uris-00 Minutes from IETF 99 artarea discussion: 
> https://datatracker.ietf.org/meeting/99/materials/minutes-99-dispatch-
> 00 Subsequent ART/URI-review thread (on one page): 
> http://ietf.10.n7.nabble.com/art-Internet-Draft-Using-URIs-With-Multip
> le-Transport-Stacks-td538558.html
>
> During the program meeting, I plan to talk to slides 2-3 of the deck 
> above, and verbally summarize what's in the other two links.  We can then discuss Adam's question to the IAB.
>
> Dave
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 17 Jul 2018 08:18:32 -0500

I'm thinking we're not going to have time to talk about this bullet from my
previous e-mail:

And maybe that's a good thing - the MaRNEW workshop report is still in the
RFC Editor queue, and (have people seen this one?)
https://datatracker.ietf.org/doc/draft-fairhurst-tsvwg-transport-encrypt/
is still an individual draft - TSVWG should be adopting it after IETF 102 -
but I think this is only going to matter more by the next IETF meeting than
it matters now ... and the IESG and IAB are spending more time talking to
operators than we have in previous years, so it's likely to keep coming up
for the foreseeable future.

The topic crosses TSV, ART, SEC, and OPS, so it's not a super-easy topic to
handle in the IETF, where everything fits in one area.

Spencer

On Sun, Jul 15, 2018 at 9:28 AM Spencer Dawkins at IETF <
[email-masked]> wrote:

>> Our agenda this time is free-form (i.e. Brian was too lazybusy to
>> actually put anything together); feel free to propose a concrete topic of
>> The program was chartered by the IAB to address the problem, perceived
>> and actual, that new protocols (especially at layer 4 in its current
>> I suggested a meeting or two ago that these, taken together, might
>> suggest that we can declare victory and wrap stackevo up. Nobody seemed to
>> like that idea (hence next week's agendaless breakfast). I've started
>> wondering whether these insights are unique to Layer 4, or whether they
>> could be applied to other places the Internet is "stuck".
>>
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 17 Jul 2018 08:46:06 -0500

Dear All,

Thanks for the quick pre-Bangkok chat about my bullet below.

The ANRW talk I mentioned was

* - TCP Congestion Signatures Invited talk Speaker: Srikanth Sundaresan (UC
Berkeley) or Amogh Dhamdhere (CAIDA)- Current speedtests tell you upload
and download bandwidth, but they don't tell you much else - even whether
the speedtest limit was reached because of self-congestion, or external
congestion due to cross traffic. Assertion is that self-congestion is more
likely to result in higher RTT variance during slow start than external
congestion, and that can be measured and detected. They also think they can
identify bottleneck links. Jana says self-congestion would be very helpful
in Google BBR, which can suffer from sustained self-congestion in some
scenarios. They're keying off TCP-level observable header fields like
sequence numbers and acks, which won't be there for QUIC, but I wonder if
this could make sense with the In-Situ OAM work in IPPM.As I said on the
call, I won't be surprised to discover there is architectural work as we
rely more and more on endpoints for management in encrypted networks
...Thanks,Spencer*
On Tue, Jul 17, 2018 at 8:18 AM Spencer Dawkins at IETF <
[email-masked]> wrote:

> I'm thinking we're not going to have time to talk about this bullet from
> my previous e-mail:
>
> The topic crosses TSV, ART, SEC, and OPS, so it's not a super-easy topic
> to handle in the IETF, where everything fits in one area.
>
> Spencer
>