Re: [Stackevo] Breakfast Tuesday Morning

[Spencer Dawkins at IETF <[e-mail]>]

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 <
[e-mail]> wrote:

> I'm thinking we're not going to have time to talk about this bullet from
> my previous e-mail:
>
>    - 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.
>
> 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 <
> [e-mail]> wrote:
>
>> Hi, Brian,
>>
>> On Thu, Jul 12, 2018 at 7:54 AM Brian Trammell (IETF) <[e-mail]>
>> 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
>>
>>
>>> Cheers,
>>>
>>> Brian
>>>
>>> _______________________________________________
>>> Stackevo mailing list
>>> [e-mail]
>>> https://www.iab.org/mailman/listinfo/stackevo
>>>
>>