Subject: [edu-team] Spherical routers...

From: Warren Kumari <[email-masked]>
Date: Wed, 12 Dec 2018 12:15:00 -0500

Hi there all (Edu-team, IESG, IAB),

The impetus for finally sending this was the most recent IPv6 Extension
Headers thread, but it is an idea / concern which has been floating around
in my head for a while now. I'll use the routers discussion as an example
(it is freshest in my mind), but I think that this applies more generally.

The way that routers are described in general literature (and in RFCs) is
that a packet comes into the box. The CPU then looks at the Ether-type,
then the IP version, then the destination IP address. It then looks into a
big list of routes, chooses the right one, and sends the packet out the
appropriate port.

This is generally / mostly / kinda correct, but is sufficiently abstract /
high level that it isn't helpful for a protocol designer -- it is like
trying to train a rocket scientist by saying "make something pointy that
goes up very fast..." (or, https://xkcd.com/1133/ ). The original
description is useful for a high-level understanding, but a: it is wildly
out of date and b: not useful for protocol designers - there are a number
of (physical-type) limitations which are important to keep in mind.
Not knowing the way modern devices are implemented / how devices actually
work in the real world has real implications for protocol design.
I tried (unsuccessfully) to move this needle by inviting John Scudder to
present on "MODERN ROUTER ARCHITECTURE FOR PROTOCOL DESIGNERS" (
http://www.iepg.org/2015-11-01-ietf94/IEPG-RouterArchitecture-jgs.pdf) at
the IEPG meeting in Yokohama (IETF94, 2015) -- this was very well received,
but was talking to the wrong audience.

I'm sure that there are a significant number of other places where things
like this happen -- for example I've seen similar thing happen around DNS.
People (in the IETF) understand the concepts, and how things are *supposed*
to work; most participants have set up some domains, many deployed a
nameserver or three -- but there is all sorts of (useful) knowledge which
either isn't documented in the RFCs / literature, and is only learnt by
practitioners.

This isn't only "operations" type stuff -- I personally largely know how
TLS works - it's a foundational protocol used by, well, pretty much
everything... but I'm *sure* that there are all sort of interesting and
useful knowledge which I *don't* know, and which would be really useful for
me to know.

So, what I think would be useful (hello Edu team :-)) would be "deep dive"
(or "Technology X,the good bits") type presentations aimed at the general
IETF participant -- in many ways this would be similar to the "Technical
Tutorials" (https://www.ietf.org/about/participate/tutorials/technical/ )
but with a slightly different focus -- speaking of the Technical Tutorials,
the most recent one I see is IETF96 (Emerging IEEE), with the majority in
the early 90s -- were they deemed not effective? Or too hard to get
presentations? Or something else?

Anyway, I think that:
a: having something not called a "tutorial" would make it more palatable to
many long time participants
b: a focus on the bits that the RFCs don't tell you
c: overviews of how things actually work
d: presented at some time other than Sunday
might be a good idea -- thoughts?

W
-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 12 Dec 2018 12:56:28 -0600

Thoughts. I have them.

> presentations? Or something else?

I don't have a strong feeling about how we teach ourselves what we need to
know (other than "making our own mistakes" isn't the optimal path), but
agree that whatever we can do to get from "this is the way it worked in
2008/1998/1988/..." to "this is what you need to know NOW", would be
helpful.

At IETF 102 TSVAREA, the speaker basically said, "we would have designed
MP-TCP differently if we had known what it would take to get our design
into the production Linux kernel, because reasons". I think a lot of people
learned something (and maybe something that would be useful to MP-QUIC,
which is actually chartered work now, although the working group has been
focused on finishing UniPath-QUIC.

So, what you're talking about shows up in TSV as well, I think.

> Anyway, I think that:
> a: having something not called a "tutorial" would make it more palatable
> to many long time participants
>

Yeah. Just between us chickens, I'm also thinking that this fits well into
my thoughts about spending face-to-face time on things that make more of a
difference than "changes since -08/the last IETF meeting", which we spend
considerable time on now.

> b: a focus on the bits that the RFCs don't tell you

"What they never told me when I started working on $whatever".

> c: overviews of how things actually work

Back to the discussion about EH, "overviews of how things actually work,
including the reasons why things work this way NOW, although they didn't
work this way THEN" would be useful. And, back to the non-tutorial point
above - people think they know this stuff, so aren't likely to go to a
"tutorial", but they aren't current, so focusing on what changed and why
seems useful.

> d: presented at some time other than Sunday

Ditto my point above about what we spend face-to-face time on, but in
addition, this stuff isn't a replacement for what we do tutorials about
now, so clobbering the tutorial slot without some fallback plan is not a
great strategy ("webcast/webinar" could be a fallback plan, but we'd need
to agree on that, or something else). I think "MODERN ROUTER ARCHITECTURE
FOR PROTOCOL DESIGNERS" sounds about right.

> might be a good idea -- thoughts?

Spencer

> W
> --
> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.

---

From: Christian Huitema <[email-masked]>
Date: Wed, 12 Dec 2018 14:57:53 -0800

> Not knowing the way modern devices are implemented / how devices
> actually work in the real world has real implications for protocol
> design. 
> I tried (unsuccessfully) to move this needle by inviting John Scudder
> to present on "MODERN ROUTER ARCHITECTURE FOR PROTOCOL DESIGNERS"
> (http://www.iepg.org/2015-11-01-ietf94/IEPG-RouterArchitecture-jgs.pdf)
> at the IEPG meeting in Yokohama (IETF94, 2015) -- this was very well
> received, but was talking to the wrong audience.

It is an interesting presentation, but I am not exactly surprised by its
content. The IPv6 architecture was influenced at the time by the work of
Craig Partridge on high speed routers. The details were not the same as
shown in John Scudder's presentation, but the broad lines did not change
all that much.

What did change is something else: expectations of what a router should
do. The original expectation was that the router looks at "the
Ether-type, then the IP version, then the destination IP address". The
updated expectation is that the routers looks at "the Ether-type, then
the IP version, then the destination IP address *and then the source
address, and the protocol type, and the port numbers.*" There are a
bunch of reasons for that, and there are different options on whether it
is useful network management or a power grab by ISP. For example:

* Equal cost load balancing, clearly a router function, works better if
it does not introduce packet reordering within a connection. Thus, the
unit of load balancing is often the five tuple of addresses, protocol
and ports.

* DDOS defense often requires shutting down traffic that originates from
a specific protocol and port.

* Forcing video senders to pay more requires the capability to recognize
the addresses and ports used by video sources.

The IPv6 extension mechanism was designed specifically to enable high
speed processing in a router, but it was designed before network routers
started to insist on looking at port numbers. The extension mechanism
replaces the variable length option field of IPv4 by a chain of headers,
which would enable the 1992 idea of service function chaining. The
headers were meant to be only processed once the destination is reached,
and thus would not slow down packet processing in high speed routers.
But the extension chain design has a critical consequence: it places the
protocol type and port numbers at the end of a potentially long chain of
extensions. And if you insist that protocol and port numbers are
essential for routing, that's really bad.

Part of me wants to argue that protocol and port numbers should really
not be used by routing, and that the whole networking industry is wrong.
But the realist in me knows that one seldom wins such arguments. And the
reality is thus that the current IPv6 header extension model has very
limited applicability.

-- Christian Huitema

---

From: Fred Baker <[email-masked]>
Date: Thu, 13 Dec 2018 00:00:52 -0500

I'm in favor.

I find myself thinking about the history books my wife bought for my kids. http://horrible-histories.co.uk/

> On Dec 12, 2018, at 12:15 PM, Warren Kumari <[email-masked]> wrote:
> 
> The impetus for finally sending this was the most recent IPv6 Extension Headers thread, but it is an idea / concern which has been floating around in my head for a while now. I'll use the routers discussion as an example (it is freshest in my mind), but I think that this applies more generally.
> 
> The way that routers are described in general literature (and in RFCs) is that a packet comes into the box. The CPU then looks at the Ether-type, then the IP version, then the destination IP address. It then looks into a big list of routes, chooses the right one, and sends the packet out the appropriate port.
> 
> This is generally / mostly / kinda correct, but is sufficiently abstract / high level that it isn't helpful for a protocol designer -- it is like trying to train a rocket scientist by saying "make something pointy that goes up very fast..." (or, https://xkcd.com/1133/ ). The original description is useful for a high-level understanding, but a: it is wildly out of date and b: not useful for protocol designers - there are a number of (physical-type) limitations which are important to keep in mind.
> Not knowing the way modern devices are implemented / how devices actually work in the real world has real implications for protocol design.
> I tried (unsuccessfully) to move this needle by inviting John Scudder to present on "MODERN ROUTER ARCHITECTURE FOR PROTOCOL DESIGNERS" (http://www.iepg.org/2015-11-01-ietf94/IEPG-RouterArchitecture-jgs.pdf) at the IEPG meeting in Yokohama (IETF94, 2015) -- this was very well received, but was talking to the wrong audience.
> 
> I'm sure that there are a significant number of other places where things like this happen -- for example I've seen similar thing happen around DNS. People (in the IETF) understand the concepts, and how things are *supposed* to work; most participants have set up some domains, many deployed a nameserver or three -- but there is all sorts of (useful) knowledge which either isn't documented in the RFCs / literature, and is only learnt by practitioners.
> 
> This isn't only "operations" type stuff -- I personally largely know how TLS works - it's a foundational protocol used by, well, pretty much everything... but I'm *sure* that there are all sort of interesting and useful knowledge which I *don't* know, and which would be really useful for me to know.
> 
> 
> So, what I think would be useful (hello Edu team :-)) would be "deep dive" (or "Technology X,the good bits") type presentations aimed at the general IETF participant -- in many ways this would be similar to the "Technical Tutorials" (https://www.ietf.org/about/participate/tutorials/technical/ ) but with a slightly different focus -- speaking of the Technical Tutorials, the most recent one I see is IETF96 (Emerging IEEE), with the majority in the early 90s -- were they deemed not effective? Or too hard to get presentations? Or something else?
> 
> 
> Anyway, I think that:
> a: having something not called a "tutorial" would make it more palatable to many long time participants
> I don't think the execution is relevant when it was obviously a bad idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
>    ---maf
> _______________________________________________
> edu-team mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/edu-team

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 13 Dec 2018 10:03:52 +0200

I’m in favor too.

Some history + present

Historically - the limiting factor in deep lookups has been - size of a
packet chunk that a chipset could fetch in a single “fetch” operation,
additional fetches would come at cost. This chunk would then be used to
lookup through pipeline and result in fw construct + metadata.
When MPLS first came around, it is was just 2 labels (top label to lookup),
still easily doable, with Fast-Reroute + InterAS + other stuff, suddenly we
were at 4+ labels (mind you - just about now, in 2018 we are getting first
“merchant” mid range silicon that could do more than 3-4 labels. On another
side - densification of connectivity resulted in a massive use of
ECMP/ethernet link aggregation (802.3ad), both often utilizing same code
for load-sharing. The need for additional entropy fields that would be used
for a better per-flow load-sharing/balancing (hashing on MPLS label stack
only, would result in a rather poor entropy) resulted in Entropy labels
work in IETF (RFC6790 and many more for applications) as well as larger
fetches on the routers- even though only top label was needed to make a
forwarding decision, looking up IP header+TCP/UDP would result in a much
better entropy (walking the MPLS stack -> finding BoS (bottom of stack)
indicator, looking up IP).

New(ish) technologies:
Segment Routing with MPLS data plane(aka SR-MPLS) requires:
1. Ingress device to push complete label (SID) stack to reach the
destination (this is source routing) with potentially a very deep label
stack (any deviation from the shortest path requires additional label) +
service labels. (MSD work - RFC8491/8476 address this)
2.Transit devices to look for entropy label indicator/entropy label
pair(s), that could be anywhere in the stack
(draft-ietf-mpls-spring-entropy-label)
We are still in “fixed offset” realm, it is reasonably straightforward to
lookup at line rate (always the requirement)

Segment Routing with IPv6 data plane (aka SRv6) is using Segment Routing
Extension Header (SRH) (draft-ietf-6man-segment-routing-header) to encode
the path (and potentially additional actions to be taken by the
transit/egress nodes) that brings its own set of challenges.

To finish with - NVO3 encaps (Geneve, VxLAN GPE) complicate fast-path
processing even further.

The contention in fast path realm has always been speed vs features, more
lookups result in higher power consumption, longer time to process, lower
throughput, etc.
Understanding these constrains when designing protocols, finding the right
balance between de-facto technology and what we ideally would like to see
would result in a much better adoption of the technologies we are
developing in IETF.

Thanks,
Jeff
On Thu, Dec 13, 2018 at 07:01 Fred Baker <[email-masked]> wrote:

> > The way that routers are described in general literature (and in RFCs)
> is that a packet comes into the box. The CPU then looks at the Ether-type,
> > This is generally / mostly / kinda correct, but is sufficiently abstract
> / high level that it isn't helpful for a protocol designer -- it is like
> actually work in the real world has real implications for protocol design.
> > I'm sure that there are a significant number of other places where
> things like this happen -- for example I've seen similar thing happen
> around DNS. People (in the IETF) understand the concepts, and how things
> are *supposed* to work; most participants have set up some domains, many
> deployed a nameserver or three -- but there is all sorts of (useful)
> knowledge which either isn't documented in the RFCs / literature, and is
> only learnt by practitioners.
> >
> > So, what I think would be useful (hello Edu team :-)) would be "deep
> dive" (or "Technology X,the good bits") type presentations aimed at the
> general IETF participant -- in many ways this would be similar to the
> "Technical Tutorials" (
> https://www.ietf.org/about/participate/tutorials/technical/ ) but with a
> slightly different focus -- speaking of the Technical Tutorials, the most
> recent one I see is IETF96 (Emerging IEEE), with the majority in the early
> 90s -- were they deemed not effective? Or too hard to get presentations? Or
> something else?
> >
> >
> > Anyway, I think that:

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Thu, 13 Dec 2018 11:42:11 +0100

hi Warren,

"Routing physics and impacts on protocol architecture" sounds like an excellent IAB technical plenary presentation; thank you for volunteering to pull this topic together. ;)

Actually, I'm not sure this topic would fit into the 30 minutes we generally allocate for tech plenary presentations. The IAB has been discussing recently whether we'd like to schedule IAB technical sessions during the week, in lieu of a tech plenary, in order to give us time to take a deeper dive than we can in a 30 minute slot. For something like this we've 

As for moving the IEPG off Sunday, I'd be in favor of that, too: I have never been to an IEPG meeting, because at the time I became aware of them, I had just joined the IAB, and the IEPG and IAB Sunday schedules have always conflicted.

(As a matter of process, the IEPG could be scheduled as a sui generis sort of thing, or it might make sense to consider spinning it up as an RG. I see a lot of parallels between what IEPG is doing and what MAPRG has become).

Cheers,

Brian

> On 12 Dec 2018, at 18:15, Warren Kumari <[email-masked]> wrote:
>

---

From: Mirjam Kuehne <[email-masked]>
Date: Thu, 13 Dec 2018 12:03:27 +0100

Hi Warren,

Thanks for including the Edu Team in this discussion. We're aiming to
organise one or two technical tutorials at each IETF meeting. The page
you refer to below is just a snapshot (but should indeed be updated).

The complete list is now on the datatracker (since IETF 100):
https://datatracker.ietf.org/group/edu/materials/
(before IETF 100 they are listed on the wiki:
https://trac.ietf.org/trac/edu/wiki/Tutorial_by_IETF ).

Recently there were for instance tutorials on traffic engineering, ILNP,
TLS, OAuth 2.0.

We're definitely open for suggestions on how to organise more in-depth
sessions. I agree that this would be useful for many participants. At
the moment the tutorials on Sunday are scheduled for one hour. But we
could for instance combine two slots and do an intro and an advanced
session in those two hours. Trying to find other time slots might be a
challenge, but not impossible.

Kind regards,
Mirjam

On 12/12/2018 18:15, Warren Kumari wrote:
> Headers thread, but it is an idea / concern which has been floating
> around in my head for a while now. I'll use the routers discussion as an
> example (it is freshest in my mind), but I think that this applies more
> generally.
> 
> is that a packet comes into the box. The CPU then looks at the
> Ether-type, then the IP version, then the destination IP address. It
> then looks into a big list of routes, chooses the right one, and sends
> the packet out the appropriate port. 
> 
> description is useful for a high-level understanding, but a: it is
> wildly out of date and b: not useful for protocol designers - there are
> a number of (physical-type) limitations which are important to keep in mind.
> present on "MODERN ROUTER ARCHITECTURE FOR PROTOCOL DESIGNERS"
> useful knowledge which I *don't* know, and which would be really useful
> for me to know. 
> 
> 
> "Technical Tutorials"
> (https://www.ietf.org/about/participate/tutorials/technical/ ) but with
> a slightly different focus -- speaking of the Technical Tutorials, the
> most recent one I see is IETF96 (Emerging IEEE), with the majority in

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Thu, 13 Dec 2018 12:39:32 +0000

Agree – this would be interesting – both for newcomers and long-timers. Maybe if one time window doesn’t allow “full” coverage, could do as multiple.

On Jeff’s list – “some history + present”/s/“some history + present + future” – as vRouter discussion is essential to include and it is a bit present+future. And while the “fast-path realm” is of high interest, there’s also consideration being given to alternative architectures for services not requiring “fast-path” which are of interest.

Deborah

From: IAB <[email-masked]> On Behalf Of Jeff Tantsura
Sent: Thursday, December 13, 2018 3:04 AM
To: Fred Baker <[email-masked]>
Cc: EDU Team <[email-masked]>; Warren Kumari <[email-masked]>; The IESG <[email-masked]>; IAB <[email-masked]>
Subject: Re: [IAB] [edu-team] Spherical routers...

I’m in favor too.

Some history + present

Historically - the limiting factor in deep lookups has been - size of a packet chunk that a chipset could fetch in a single “fetch” operation, additional fetches would come at cost. This chunk would then be used to lookup through pipeline and result in fw construct + metadata.
When MPLS first came around, it is was just 2 labels (top label to lookup), still easily doable, with Fast-Reroute + InterAS + other stuff, suddenly we were at 4+ labels (mind you - just about now, in 2018 we are getting first “merchant” mid range silicon that could do more than 3-4 labels. On another side - densification of connectivity resulted in a massive use of ECMP/ethernet link aggregation (802.3ad), both often utilizing same code for load-sharing. The need for additional entropy fields that would be used for a better per-flow load-sharing/balancing (hashing on MPLS label stack only, would result in a rather poor entropy) resulted in Entropy labels work in IETF (RFC6790 and many more for applications) as well as larger fetches on the routers- even though only top label was needed to make a forwarding decision, looking up IP header+TCP/UDP would result in a much better entropy (walking the MPLS stack -> finding BoS (bottom of stack) indicator, looking up IP).

New(ish) technologies:
Segment Routing with MPLS data plane(aka SR-MPLS) requires:
1. Ingress device to push complete label (SID) stack to reach the destination (this is source routing) with potentially a very deep label stack (any deviation from the shortest path requires additional label) + service labels. (MSD work - RFC8491/8476 address this)
2.Transit devices to look for entropy label indicator/entropy label pair(s), that could be anywhere in the stack (draft-ietf-mpls-spring-entropy-label)
We are still in “fixed offset” realm, it is reasonably straightforward to lookup at line rate (always the requirement)

Segment Routing with IPv6 data plane (aka SRv6) is using Segment Routing Extension Header (SRH) (draft-ietf-6man-segment-routing-header) to encode the path (and potentially additional actions to be taken by the transit/egress nodes) that brings its own set of challenges.

To finish with - NVO3 encaps (Geneve, VxLAN GPE) complicate fast-path processing even further..

The contention in fast path realm has always been speed vs features, more lookups result in higher power consumption, longer time to process, lower throughput, etc.
Understanding these constrains when designing protocols, finding the right balance between de-facto technology and what we ideally would like to see would result in a much better adoption of the technologies we are developing in IETF.

Thanks,
Jeff
On Thu, Dec 13, 2018 at 07:01 Fred Baker <[email-masked]<mailto:[email-masked]>> wrote:
I'm in favor.

I find myself thinking about the history books my wife bought for my kids. http://horrible-histories.co.uk/<https://urldefense.proofpoint.com/v2/url?u=http-3A__horrible-2Dhistories.co.uk_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=xqXXcIYFHNXkt2n4KLl2OrjrEllHNKLIjKkI5vvMhm8&s=Pb77X4Hyfk4ybqB-NJoBa_SWZB7WuFIQOAHzIdBDEJY&e=>

> On Dec 12, 2018, at 12:15 PM, Warren Kumari <[email-masked]<mailto:[email-masked]>> wrote:
>
> This is generally / mostly / kinda correct, but is sufficiently abstract / high level that it isn't helpful for a protocol designer -- it is like trying to train a rocket scientist by saying "make something pointy that goes up very fast..." (or, https://xkcd.com/1133/<https://urldefense.proofpoint.com/v2/url?u=https-3A__xkcd.com_1133_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=xqXXcIYFHNXkt2n4KLl2OrjrEllHNKLIjKkI5vvMhm8&s=tuMw7OJqCu7sdFI8SBNW2K_2c3D71NKeQLowPjGcGls&e=> ). The original description is useful for a high-level understanding, but a: it is wildly out of date and b: not useful for protocol designers - there are a number of (physical-type) limitations which are important to keep in mind.
> I tried (unsuccessfully) to move this needle by inviting John Scudder to present on "MODERN ROUTER ARCHITECTURE FOR PROTOCOL DESIGNERS" (http://www.iepg.org/2015-11-01-ietf94/IEPG-RouterArchitecture-jgs.pdf<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.iepg.org_2015-2D11-2D01-2Dietf94_IEPG-2DRouterArchitecture-2Djgs.pdf&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=xqXXcIYFHNXkt2n4KLl2OrjrEllHNKLIjKkI5vvMhm8&s=eKKovWUJQBTwse5fWQvvCv6ofdWyiUmy560CB3mocVQ&e=>) at the IEPG meeting in Yokohama (IETF94, 2015) -- this was very well received, but was talking to the wrong audience.
>
> So, what I think would be useful (hello Edu team :-)) would be "deep dive" (or "Technology X,the good bits") type presentations aimed at the general IETF participant -- in many ways this would be similar to the "Technical Tutorials" (https://www.ietf.org/about/participate/tutorials/technical/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_about_participate_tutorials_technical_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=xqXXcIYFHNXkt2n4KLl2OrjrEllHNKLIjKkI5vvMhm8&s=i3-GaYvZEhjh6Rg526RQDfiYwRZPDCth0uCsb65pAqk&e=> ) but with a slightly different focus -- speaking of the Technical Tutorials, the most recent one I see is IETF96 (Emerging IEEE), with the majority in the early 90s -- were they deemed not effective? Or too hard to get presentations? Or something else?
>
>
> Anyway, I think that:
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/edu-team<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_edu-2Dteam&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=xqXXcIYFHNXkt2n4KLl2OrjrEllHNKLIjKkI5vvMhm8&s=Lg9OAOnrA70ywltiTxeXRAZgDiOBPiQYpoZh0xu5AjQ&e=>

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 14 Dec 2018 15:23:21 +1100

Hey Warren,

Big +1. In the past, we've talked about doing this from the application side too -- e.g., what the major concerns / motivations are for a browser vendor (which IETF folks regularly misunderstand), how modern HTTP servers work, CDNs, etc.

Finding the right way to present this is probably the key factor; we were discussing it in the context of the plenary program, but I'm still on the fence as to whether that's the right venue.

Cheers,

> On 13 Dec 2018, at 4:15 am, Warren Kumari <[email-masked]> wrote:
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 14 Dec 2018 04:55:06 -0600

Hi, Mark,

On Thu, Dec 13, 2018, 22:23 Mark Nottingham <[email-masked] wrote:

> Hey Warren,
>
> Big +1. In the past, we've talked about doing this from the application
> side too -- e.g., what the major concerns / motivations are for a browser
> vendor (which IETF folks regularly misunderstand), how modern HTTP servers
> work, CDNs, etc.
>

Another big +1 on your point (Warren knows I'm +1 on his).

I think the QUIC WG will end up in the right place, but if a broader slice
of IETF participants understood (for example) current practices on load
balancers, we might end up in the right place sooner.

Our discussion about transport proxies in IETF 103 TSVAREA included what
seemed like a lot of information about thinking in ART, especially about
"inconspicuous HTTP proxies", that I wish we'd started with, for MaRNEW*,
SPUD**, and PLUS***.

And TSV, too. For example, I think
https://datatracker.ietf.org/doc/draft-fairhurst-tsvwg-transport-encrypt/
is a step in that direction.

* https://datatracker.ietf.org/meeting/103/session/tsvarea
**https://datatracker.ietf.org/doc/rfc8462/
*** https://datatracker.ietf.org/meeting/92/session/spud
**** https://datatracker.ietf.org/meeting/96/session/plus

ISTM that we usually describe what IS, as part of an effort to describe
what SHOULD BE, whether as a protocol or as an operational practice, and
trying to discuss the present and the future at the same time slows things
down.

If we agreed on a starting point, agreeing on a destination would likely
happen more quickly.

Finding the right way to present this is probably the key factor; we were
> discussing it in the context of the plenary program, but I'm still on the
> fence as to whether that's the right venue.
>

ISTM that we may have different kinds of material to present, at different
levels of detail, and that some topics might be appropriate for tech
plenaries and other topics might not.

Fortunately, we don't have to do "one size fits all".

Spencer

Cheers,

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 14 Dec 2018 13:03:42 -0800

On December 14, 2018 at 5:55:29 AM, Spencer Dawkins at IETF (
[email-masked]) wrote:

Right…but we do need to find a timely way to deliver the information, which
may have a direct effect on the how.  For example, a queue of 6 topics
would take a single plenary (or Sunday tutorial slot…just as examples) 2
years to drain!  I think that is a very long time for important information
to be shared.  A combination of mechanisms, somehow coordinated may be a
way to go to make sure priority topics are dealt with first.

My 1c.

Alvaro.

---

From: Fred Baker <[email-masked]>
Date: Fri, 14 Dec 2018 13:20:47 -0800

Personally, I would find this far more interesting and useful (meaning that I might sign up and attend) than a marketing slot for the host lunchtime on Thursday.

Sent using a machine that autocorrects in interesting ways...

> On Dec 14, 2018, at 1:03 PM, Alvaro Retana <[email-masked]> wrote:
> 
>> On December 14, 2018 at 5:55:29 AM, Spencer Dawkins at IETF ([email-masked]) wrote:
>> 
>> ISTM that we may have different kinds of material to present, at different levels of detail, and that some topics might be appropriate for tech plenaries and other topics might not.
>> 
> Right…but we do need to find a timely way to deliver the information, which may have a direct effect on the how.  For example, a queue of 6 topics would take a single plenary (or Sunday tutorial slot…just as examples) 2 years to drain!  I think that is a very long time for important information to be shared.  A combination of mechanisms, somehow coordinated may be a way to go to make sure priority topics are dealt with first.
> 
> My 1c.
> 
> Alvaro.
> 
>

---

From: Warren Kumari <[email-masked]>
Date: Fri, 14 Dec 2018 18:05:12 -0500

On Fri, Dec 14, 2018 at 4:20 PM Fred Baker <[email-masked]> wrote:

> Personally, I would find this far more interesting and useful (meaning
> that I might sign up and attend) than a marketing slot for the host
> lunchtime on Thursday.
>

Hey, me too!

Spencer and I chatted about this a bit this morning, and I also briefly
chatted with Karen (part of the Edu team) - it seems that there is more
interest in this idea than I'd initially thought; at some point it might be
worth having a separate thread to further discuss this, but for now I'd
like to keep it here so we can get more views. Spencer and I also wanted to
get out throughs more in order before sharing with the larger group...

The Edu team has organized a number of technical presentations which I
think would be useful / interesting for the general IETF participant - but
in many cases I think that established IETF participants don't attend
these, either because they are on Sunday (which is already a busy time), or
because they are viewed as "tutorials" (and the very people who would most
benefit don't think that they need a tutorial on these subjects) - having
the tone (and title) be much more of "here are some new and interesting
things happening in Area X, Working Group Y or Technology Z", and carefully
avoiding the word "tutorial" seems like it might be a reasonable idea.
Spencer also mentioned that the IEEE used to have something along the lines
of Late Night Deep Dives (or something), where there would be an after
dinner meeting / discussion where people not deeply involved in a specific
technology / PAR / project could come along and learn more...

This might be a nice model to try, but there are all sorts of logistical
issues, like rooms, getting people to talk, avoiding the sales pitch, etc
We already have some topics above, but some other ones which I / we think
would be interesting include:
Modern operational practices
HTTP server architecture
TLS in theory and practice
How congestion control works these days…
Especially problematic network paths (satellite, asymmetric paths, mobile
networks, mesh networks ...)

I still believe that "Modern Router Design" would make a good plenary
discussion (but I'm biased!) -- it is broad enough that it covers a wide
range of participants, has implications for many WGs / areas /
participants, and covers fascinating things from low level considerations
like ASIC design / DRAM & SRAM bandwidth, fabrics, power and cooling,
though parallel architectures, NPE, fast-path vs slow path, data vs control
plane, MPLS, RIB vs FIB, routing protocols, etc. One of the potential
issues with organizing a plenary like this (other than setting the
appropriate technical level) is getting someone competent and willing to
speak - as an example, Juniper markets the PTX10016 as being able to do up
to 48 Tbps -- and it can, but only under certain conditions - the whole
point of this sort of discussion is to talk about the limitations and where
the devices have a hard time.
Do other IAB folk also think that this might be worthy of plenary time?
Brian had mentioned longer session possibly during the week? Might someone
who works for a large router vendor (cough, Alvaro, Alissa) think they
might be able to find someone to talk? (I have a todo item to poke John
Scudder and see if he might be willing to repeat his IEPG presentation
somewhere else).

Anyway, I'm excited that people seem interested / willing, and want to
continue this conversation, but don't want to step on any toes...

So, more thoughts?
W

> Right…but we do need to find a timely way to deliver the information,
> which may have a direct effect on the how.  For example, a queue of 6
> topics would take a single plenary (or Sunday tutorial slot…just as
> examples) 2 years to drain!  I think that is a very long time for important
> information to be shared.  A combination of mechanisms, somehow coordinated
> may be a way to go to make sure priority topics are dealt with first.
>
> My 1c.
>
> Alvaro.
>

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 14 Dec 2018 23:06:09 -0800

Warren Kumari <[email-masked]> writes:

> dive" (or "Technology X,the good bits") type presentations aimed at
> the general IETF participant

Hi all (late to the reply party).

Warren, you know I've been thinking along the lines of how do we get
more cross-knowledge sharing within the IETF.  At IETF103 I ran my pitch
for a potential plenary to you and a couple of other people (whom I
actually don't remember who they were): a 5-minute Shakespeare style
overview of current major topics in each area.  For the same reason that
you suggested: I'm in deep in some areas of the IETF, but in others I
know very little (if you ask me for the current issues surrounding TCP
in the transport working group, you'll get a very very blank stare from
me).  I'd love to figure out a way to give even a short introduction to
the problem spaces of the rest of the areas to everyone.  Potentially an
impossible task, but ...  I have a vision.  And it works in my dream.

I think you bring up an excellent structure for the deep dives. Let me
clarify the most important part of what you started to lay out: we don't
need a deep dive *of the protocol in question* (e.g. routing), we need a
deep dive of the *problem space* (i.e. the real world scenarios affected
by how routers are implementing flinging packets as fast as possible).

So I'd like to back the idea of bringing the deep dive from the problem
space side, so we end up incorporating multiple protocols and problem
spaces for a given situation (another example: browsers and product
vendors want the lowest latency possible and the end result is a
deployed infrastructure of in-ISP CDNs (DNS), information bundling, stream
combining (HTTP2), display optimizations (they start drawing stuff
before all the DNS requests are event sent), too many round-trips
(affecting DNS, TLS startups, etc)).

I think many protocol designers (guilty as charged) have a hard time
understanding the real world consequences of the battles being fought in
deployment, because those deployment stories rarely reach the WGs of the
IETF.

(in fact, the notion of bringing operators to the IETF to explain these
problems has been one that has been lingering around for decades and
decades at this point)

So, in support yes!  And I think your router case is a great place to
start.  But we should probably brain storm what a larger and more
complete list should be and then do some structuring and priortiizing.

I have a sneaking suspicion that 2 plenaries may be coming back as a
result of this.  But if done right, I doubt anyone will mind.
-- 
Wes Hardaker
USC/ISI

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Sat, 15 Dec 2018 09:56:07 +0100

Hi Warren,

just a few quick comments/notes:

+1 for the plenary; that was my first thought when I read your initial mail.

On congestion control, there is a research group which usually has some very interesting talks. This might not be the right place for people not primarily interested in congestion control; however, to be honest the base principles haven’t changed that much and I wouldn’t want to bring something like BBR to the plenary because it’s still very experimental and got a lot of criticisms in ICCRG.

I don’t go to the tutorials because the week is already busy enough and I prefer to spend my time talking about new, up-coming stuff. I don’t think there is any time slot that would suit me well but there are very likely a whole bunch of people who are less busy than I am. However, I actually go to the tsv tutorials, not because I would learn something, but because I want to know what they said; and I have to said there are mostly tsv people in the room which is not quite the audience we are looking for (plus a few newcomers).

Mirja

> Am 15.12.2018 um 00:05 schrieb Warren Kumari <[email-masked]>:
> 
> 
> 
> Spencer and I chatted about this a bit this morning, and I also briefly chatted with Karen (part of the Edu team) - it seems that there is more interest in this idea than I'd initially thought; at some point it might be worth having a separate thread to further discuss this, but for now I'd like to keep it here so we can get more views. Spencer and I also wanted to get out throughs more in order before sharing with the larger group...
> 
> The Edu team has organized a number of technical presentations which I think would be useful / interesting for the general IETF participant - but in many cases I think that established IETF participants don't attend these, either because they are on Sunday (which is already a busy time), or because they are viewed as "tutorials" (and the very people who would most benefit don't think that they need a tutorial on these subjects) - having the tone (and title) be much more of "here are some new and interesting things happening in Area X, Working Group Y or Technology Z", and carefully avoiding the word "tutorial" seems like it might be a reasonable idea. Spencer also mentioned that the IEEE used to have something along the lines of Late Night Deep Dives (or something), where there would be an after dinner meeting / discussion where people not deeply involved in a specific technology / PAR / project could come along and learn more... 
> 
> This might be a nice model to try, but there are all sorts of logistical issues, like rooms, getting people to talk, avoiding the sales pitch, etc
> We already have some topics above, but some other ones which I / we think would be interesting include:
> Especially problematic network paths (satellite, asymmetric paths, mobile networks, mesh networks ...)
> 
> 
> I still believe that "Modern Router Design" would make a good plenary discussion (but I'm biased!) -- it is broad enough that it covers a wide range of participants, has implications for many WGs / areas / participants, and covers fascinating things from low level considerations like ASIC design / DRAM & SRAM bandwidth, fabrics, power and cooling, though parallel architectures, NPE, fast-path vs slow path, data vs control plane, MPLS, RIB vs FIB, routing protocols, etc. One of the potential issues with organizing a plenary like this (other than setting the appropriate technical level) is getting someone competent and willing to speak - as an example, Juniper markets the PTX10016 as being able to do up to 48 Tbps -- and it can, but only under certain conditions - the whole point of this sort of discussion is to talk about the limitations and where the devices have a hard time. 
> Do other IAB folk also think that this might be worthy of plenary time? Brian had mentioned longer session possibly during the week? Might someone who works for a large router vendor (cough, Alvaro, Alissa) think they might be able to find someone to talk? (I have a todo item to poke John Scudder and see if he might be willing to repeat his IEPG presentation somewhere else).
> 
> Anyway, I'm excited that people seem interested / willing, and want to continue this conversation, but don't want to step on any toes...
> 
> So, more thoughts? 
> W
> 
> 
>  
>