Subject: [Stackevo] Fwd: ETSI NGP ISG - whitepaper

From: Natasha Rooney <[email-masked]>
Date: Wed, 1 Jun 2016 13:47:45 +0000

Hi guys,

If you’re up for 39 pages of excruciating fun then may I suggest the ETSI Next Generation White Paper which was released this week?! Please find it attached. I assume this list is the best to discuss it also, so please post any thoughts you may have.

Thanks!

Natasha

Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | [email-masked]<mailto:[email-masked]> | +44 (0) 7730 219 765 | @thisNatasha | Skype: [email-masked]<mailto:[email-masked]>

Istvan Lajtos MCIM | Director, Web Working Group, Technology

GSM Association
Address: 2nd Floor, The Walbrook Building, 25 Walbrook, London, EC4N 8AF, United Kingdom
Email:  [email-masked]<mailto:[email-masked]> , Mobile: +44 773 196 0000

<https://infocentre2.gsma.com/gp/WG/WWG/Pages/Default.aspx>

This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 356 0600 and highlight the error.

---

From: Brian Trammell <[email-masked]>
Date: Mon, 6 Jun 2016 10:03:29 +0200

hi Natasha, all,

I'm on Page 16 and my dosimeter hasn't pinged yet, so at least there's that.

On this point, Mirja and I had a meeting with Yin Yue, one of the Huawei authors from the research side, on Friday, and he has a somewhat different perspective on where the ISG work fits than the initial ETSI press splash indicated. He sees the NGP ISG as a requirements-only group, with any work impacting the IP stack being brought back into the IETF.

So to the extent that correspondence from the program could help support that view within the NGP ISG, I believe it does make sense for the Program to send correspondence on specific technical points, primarily in terms of raising awareness of ongoing IETF work that may address certain requirements raised, or of the downsides of certain architectural patterns implied by them. At least, this is where most of my comments seem to go so far (other than the occasional "um what?" in the margins...)

Aside: It strikes me it would be really nice to have a "future vision of the IP stack" document out of the Program/IAB to point to for correspondence like this, but it does seem like a lot of work.

More later, cheers,

Brian

> On 01 Jun 2016, at 15:47, Natasha Rooney <[email-masked]> wrote:
> 
> Hi guys,
> 
> Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | [email-masked] | +44 (0) 7730 219 765 | @thisNatasha | Skype: [email-masked]
> 
> 
>> 
>> Email:  [email-masked] , Mobile: +44 773 196 0000
>> 
> <etsi_wp17_next_generation_protocols_v01_168271.pdf>
> 
> _______________________________________________
> Stackevo mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/stackevo

---

From: Brian Trammell <[email-masked]>
Date: Mon, 6 Jun 2016 15:27:43 +0200

hi Natasha, all,

I... made it all the way through. I am not sure whether this is a point of pride or shame.

Were this an academic paper, the first line of my review would read something like, "the authors have identified a set of interesting and important problems, but seem fundamentally confused about both the context in which the problems have arisen and the state of the art in the solution space." More fundamentally, it reads to me more like an industry-white-paper justification for a pre-made conclusion: "TCP/IP is the root of all evil in the 5G space and should be tipped into the bin", with evidence drawn from IPv4, TCP NewReno with a 3-packet IW, the worst case in 3GPP architecture deployment patterns, and wildly inappropriate (if ubiquitous) application-layer misuse of TCP, with a nebulous proposal to replace the hideously-inefficient, over-layered "stack" with a "holistic" "protocol architecture" with "flexible building blocks that can be used in heterogeneous network environments", i.e., as far as I can tell, a stack, to which we are meant to ease transition by widespread deployment of protocol-translating "NGP proxy device".

My optimism about how well *that* will work out is too drippingly sarcastic to get into e-mail, and in this community, that's saying something.

I don't think that any of the above would be a particularly productive reply here, though.

Some notes should we decide, as a program, to respond:

(0) I think the message is "most of what you want to do can actually be done with evolution of the present stack, either using technologies already widely deployed or currently in development." along with a dose of "the apparent simplicity of completely starting over is seductive, but the history of transition has shown that in a network such as the Internet, even revolutionary change is evolutionary, and transitions take decades." or similar...

(1) It seems that many of the challenges identified in addressing (page 10) could be easily solved using alternate host address  allocation schemes for IPv6. If we accept that an identifier-locator split with durable identification of an endpoint is a Good Idea, common operational practice of using the least-significant 64 bits in IPv6 could easily accommodate this (indeed, SLAAC without privacy addresses has done this forever, if you consider the MAC a useful durable identifier). But we should know that a durable "identifier" layer over the IP "locator" layer drawn on page 12 is anathema to privacy.

Side question: how is LISP deployed these days, anyway?

(2) The authors seem aware of MPTCP, but not of its applicability to mobility. Any response should probably point out that the transport layer must be involved in mobility management, and point to MPTCP as a protocol already under development in the IETF for this purpose. Indeed, the idea that network-layer mobility solutions can make handoff seamless in a multiple access environment (as required on page 15) completely ignores the fact that these multiple access networks may have wildly varying characteristics (as noted on page 19), so transport will *anyway* need to be involved in handoff. Given this, requiring mobility at layer 3 seems not particularly indicative of revolutionary thinking...

(3) We should point out efforts to merge transport and security protocols (QUIC + TLS1.3, TCPINC) within the IETF, as addressing the "security limitations in the TCP/IP protocol suite" raised on page 17.

(I'd have a lot more to say about the Security section on page 16 in general, but it's such a mess that I don't think we can say anything productive here...)

(4) On ultra low-latency and high throughput transport (page 18), we should point out work in the transport area on improving TCP CC performance (new algorithms, RMCAT, AQM, L4S if it happens) as well as the fact that treating TCP as if it's a suitable media transport is kind of a strawman.

(5) Depending on what happens with PLUS (or, maybe, as an invitation to the BoF), we should point out explicit cooperation as an architectural pattern in answer to "security/network optimization" (page 17).

That's about all I can see in terms of concrete suggestions.

Again, since the entire idea seems to be "TCP/IP is axiomatically bad, what should we replace it with" I'm not sure this is something that will be particularly well-heard; as Ted has pointed out, there might not be much we can do to help people who have decided to charge toward a catenet architecture with flags unfurled and muskets drawn.

Thoughts?

Cheers,

Brian

> On 06 Jun 2016, at 10:03, Brian Trammell <[email-masked]> wrote:
> 
> hi Natasha, all,
>

---

From: Michael Welzl <[email-masked]>
Date: Mon, 6 Jun 2016 15:52:36 +0200

> On 06 Jun 2016, at 15:27, Brian Trammell <[email-masked]> wrote:
> 
> hi Natasha, all,
> 

Well, I completely agree with the last point.

I deal a bit with one of the authors, whose views I noticed when browsing through the document, and now I find them reflected in some of Brian's comments above. This is only one author, but he's a man who simply "knows the truth" and won't be told. It's definitely a waste of time to try to discuss with him - to him, IETFers are by definition a bunch of Internet idiots and that's that.

Answering back with these points would let the other side identify (like me) some text that originated from that person, and then, god forbid, we may end up having a discussion with him.
As if I'm not seeing enough of this already. It's not constructive, it's just wasting time.

My 2 cents... from the narrow perspective I have on this.

Cheers,
Michael

---

From: Aaron Falk <[email-masked]>
Date: Mon, 06 Jun 2016 13:59:07 +0000

Brian-

Thanks the awesome and entertaining analysis.  A great way to start the
week.  I haven't read the report and was about to but you've convinced me
that it would not b a productive use of time.  With only a few small
changes to the (more recent) specifics, your review applies to every
"Future Internet" SDO-grab of the past 20 years, starting with ATM.  And we
all know how well those turned out.  Good luck to 'em.

--aaron

On Mon, Jun 6, 2016 at 9:28 AM Brian Trammell <[email-masked]> wrote:

> Were this an academic paper, the first line of my review would read
> something like, "the authors have identified a set of interesting and
> important problems, but seem fundamentally confused about both the context
> in which the problems have arisen and the state of the art in the solution
> space." More fundamentally, it reads to me more like an
> industry-white-paper justification for a pre-made conclusion: "TCP/IP is
> the root of all evil in the 5G space and should be tipped into the bin",
> with evidence drawn from IPv4, TCP NewReno with a 3-packet IW, the worst
> case in 3GPP architecture deployment patterns, and wildly inappropriate (if
> ubiquitous) application-layer misuse of TCP, with a nebulous proposal to
> replace the hideously-inefficient, over-layered "stack" with a "holistic"
> "protocol architecture" with "flexible building blocks that can be used in
> heterogeneous network environments", i.e., as far as I can tell, a stack,
> to which we are meant to ease transition by widespread deployment of
> protocol-translating "NGP proxy device".
>
> My optimism about how well *that* will work out is too drippingly
> sarcastic to get into e-mail, and in this community, that's saying
> something.
>
> (0) I think the message is "most of what you want to do can actually be
> done with evolution of the present stack, either using technologies already
> widely deployed or currently in development." along with a dose of "the
> apparent simplicity of completely starting over is seductive, but the
> history of transition has shown that in a network such as the Internet,
> even revolutionary change is evolutionary, and transitions take decades."
> or similar...
>
> (1) It seems that many of the challenges identified in addressing (page
> 10) could be easily solved using alternate host address  allocation schemes
> for IPv6. If we accept that an identifier-locator split with durable
> identification of an endpoint is a Good Idea, common operational practice
> of using the least-significant 64 bits in IPv6 could easily accommodate
> this (indeed, SLAAC without privacy addresses has done this forever, if you
> consider the MAC a useful durable identifier). But we should know that a
> durable "identifier" layer over the IP "locator" layer drawn on page 12 is
> anathema to privacy.
>
> (2) The authors seem aware of MPTCP, but not of its applicability to
> mobility. Any response should probably point out that the transport layer
> must be involved in mobility management, and point to MPTCP as a protocol
> already under development in the IETF for this purpose. Indeed, the idea
> that network-layer mobility solutions can make handoff seamless in a
> multiple access environment (as required on page 15) completely ignores the
> fact that these multiple access networks may have wildly varying
> characteristics (as noted on page 19), so transport will *anyway* need to
> be involved in handoff. Given this, requiring mobility at layer 3 seems not
> particularly indicative of revolutionary thinking...
>
> (3) We should point out efforts to merge transport and security protocols
> (QUIC + TLS1.3, TCPINC) within the IETF, as addressing the "security
> limitations in the TCP/IP protocol suite" raised on page 17.
>
> (I'd have a lot more to say about the Security section on page 16 in
> general, but it's such a mess that I don't think we can say anything
> productive here...)
>
> (4) On ultra low-latency and high throughput transport (page 18), we
> should point out work in the transport area on improving TCP CC performance
> (new algorithms, RMCAT, AQM, L4S if it happens) as well as the fact that
> treating TCP as if it's a suitable media transport is kind of a strawman.
>
> (5) Depending on what happens with PLUS (or, maybe, as an invitation to
> the BoF), we should point out explicit cooperation as an architectural
> pattern in answer to "security/network optimization" (page 17).
>
> Again, since the entire idea seems to be "TCP/IP is axiomatically bad,
> what should we replace it with" I'm not sure this is something that will be
> particularly well-heard; as Ted has pointed out, there might not be much we
> can do to help people who have decided to charge toward a catenet
> architecture with flags unfurled and muskets drawn.
>
> Thoughts?
>
> Cheers,
>
> Brian
>
>
> > On this point, Mirja and I had a meeting with Yin Yue, one of the Huawei
> authors from the research side, on Friday, and he has a somewhat different
> perspective on where the ISG work fits than the initial ETSI press splash
> indicated. He sees the NGP ISG as a requirements-only group, with any work
> impacting the IP stack being brought back into the IETF.
> >
> > So to the extent that correspondence from the program could help support
> that view within the NGP ISG, I believe it does make sense for the Program
> to send correspondence on specific technical points, primarily in terms of
> raising awareness of ongoing IETF work that may address certain
> requirements raised, or of the downsides of certain architectural patterns
> implied by them. At least, this is where most of my comments seem to go so
> far (other than the occasional "um what?" in the margins...)
> >
> > Aside: It strikes me it would be really nice to have a "future vision of
> the IP stack" document out of the Program/IAB to point to for
> correspondence like this, but it does seem like a lot of work.
> >
> > More later, cheers,
> >
> > Brian
> >
> >
> >
> >> If you’re up for 39 pages of excruciating fun then may I suggest the
> ETSI Next Generation White Paper which was released this week?! Please find
> it attached. I assume this list is the best to discuss it also, so please
> post any thoughts you may have.
> >>
> >> Thanks!
> >>
> >> Natasha
> >>
> >>
> >> Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA |
> [email-masked] | +44 (0) 7730 219 765 | @thisNatasha | Skype:
> [email-masked]
> >>
> >>
> >>>
> >> This email and its attachments are intended for the above named only
> and may be confidential. If they have come to you in error you must take no
> action based on them, nor must you copy or show them to anyone; please
> reply to this email or call +44 207 356 0600 and highlight the error.
> >>
> >>>
> >>> This email and its attachments are intended for the above named only
> and may be confidential. If they have come to you in error you must take no
> action based on them, nor must you copy or show them to anyone; please
> reply to this email or call +44 207 356 0600 and highlight the error.
> >>>
-- 
--aaron

=====Short message from my phone=====

---

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 20 Jun 2016 12:13:24 +0200

Quick question: Do we know have something like a liaison to them? I wondering if it still makes sense to send a sign basically saying, we are aware of what you are doing…?

Mirja

> Am 06.06.2016 um 15:59 schrieb Aaron Falk <[email-masked]>:
> 
> Brian-
> 
> Thanks the awesome and entertaining analysis.  A great way to start the week.  I haven't read the report and was about to but you've convinced me that it would not b a productive use of time.  With only a few small changes to the (more recent) specifics, your review applies to every "Future Internet" SDO-grab of the past 20 years, starting with ATM.  And we all know how well those turned out.  Good luck to 'em.
> 
> --aaron
>

---

From: Brian Trammell <[email-masked]>
Date: Tue, 21 Jun 2016 11:37:18 +0200

hi Mirja,

IIRC Ralph was going to try to join the group without joining the group, but I don't recall what happened here. Ralph?

Jari was also invited to give a talk at an NGP event somewhere, where he would largely have made the points we might want to about much of this already being a topic of active work in the IETF; I don't know whether he accepted or not.

A question I'd like to try to answer today is whether we want to respond to this with a program communication, and IAB communication, or nothing at all...

Cheers,

Brian

> On 20 Jun 2016, at 12:13, Mirja Kühlewind <[email-masked]> wrote:
>

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Tue, 21 Jun 2016 13:17:28 +0000

I just had a quick chat with David Lake (Cisco rep to NGP ISG).  Our tentative plan, to be discussed with the IAB Wed AM, is for David to cause the ISG to send a liaison statement to the IAB requesting input on the white paper, to be returned to the ISG in a liaison statement in time for the next ISG meeting at the end of July.

Later in the ISG process, when the ISG begins to liaise with SDOs to actually publish standards, David will ensure that the IAB/IETF is included in the organizations asked for input into the specifications under development in the ISG.

- Ralph

> On Jun 20, 2016, at 6:13 AM 6/20/16, Mirja Kühlewind <[email-masked]> wrote:
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Jun 2016 06:24:09 -0700

Obviously, it's up to the IAB to determine how it wants to spend its time,
but is it really productive to enter into an exchange of liaison statements
in this case?

My experience has been that when dealing with an organization that is
basically hostile to our values we tehd try to spend a lot of time
negotiating when what we really should be doing is ignoring them and
continuing to advance our own agenda.

-Ekr

On Tue, Jun 21, 2016 at 6:17 AM, Ralph Droms (rdroms) <[email-masked]>
wrote:

> I just had a quick chat with David Lake (Cisco rep to NGP ISG).  Our
> tentative plan, to be discussed with the IAB Wed AM, is for David to cause
> the ISG to send a liaison statement to the IAB requesting input on the
> white paper, to be returned to the ISG in a liaison statement in time for
> the next ISG meeting at the end of July.
>
> Later in the ISG process, when the ISG begins to liaise with SDOs to
> actually publish standards, David will ensure that the IAB/IETF is included
> in the organizations asked for input into the specifications under
> development in the ISG.
>
> - Ralph
>
>
> > Quick question: Do we know have something like a liaison to them? I
> wondering if it still makes sense to send a sign basically saying, we are
> aware of what you are doing…?
> >
> > Mirja
> >
> >
> >> (3) We should point out efforts to merge transport and security
> protocols (QUIC + TLS1.3, TCPINC) within the IETF, as addressing the
> "security limitations in the TCP/IP protocol suite" raised on page 17.
> >>
> >>> On this point, Mirja and I had a meeting with Yin Yue, one of the
> Huawei authors from the research side, on Friday, and he has a somewhat
> different perspective on where the ISG work fits than the initial ETSI
> press splash indicated. He sees the NGP ISG as a requirements-only group,
> with any work impacting the IP stack being brought back into the IETF.
> >>>
> >>> So to the extent that correspondence from the program could help
> support that view within the NGP ISG, I believe it does make sense for the
> Program to send correspondence on specific technical points, primarily in
> terms of raising awareness of ongoing IETF work that may address certain
> >>> Aside: It strikes me it would be really nice to have a "future vision
> of the IP stack" document out of the Program/IAB to point to for

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Tue, 21 Jun 2016 13:30:08 +0000

> Quick question: Do we know have something like a liaison to them? I wondering if it still makes sense to send a sign basically saying, we are aware of what you are doing…?

We do not have a liaison arrangement in place.  While I was investigating the possibility of joining the group mailing list, Cisco actually joined the ISG and a good friend of mine from Cisco is representing us in the group.  David has agreed to keep me informed of work in the ISG.

I don't know about using David to pass IAB input back to the ISG.  I'm going to call him in a few minutes so I should have a better picture of what's going on later this AM.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Tue, 21 Jun 2016 09:31:18 -0400

- Ralph

---

From: Jari Arkko <[email-masked]>
Date: Tue, 21 Jun 2016 10:17:26 -0500

I agreed to talk. The event is:

> We are honored to invite to you to the Next Generation Protocols (NGP) - IP2020 Symposium for a keynote speech on the any topic you’d like, which is relevant to IP/IETF evolution, even just promoting IETF awareness. The event will be held in October 2016, along with SDN & OpenFlow World Congress (http://www.layer123.com/sdn) at Hague, Netherlands.
> 
> This NGP Symposium would foresee future network evolutions, including topics on issues of current Internet, new network design principles, new mobility management protocols, cross-silos IoT communications based on unified identifier, Self-X networks, new transport layer, network security and so forth.
…
> The IP2020 Symposium would be a
> heavyweight meeting. Vint Cerf, Lars Eggert, David Meyer, Richard Li, Dino
> Farinacci, Andy Sutton, Alex Galis and several more speakers from carriers are
> all in our plan. Since these NGP technical evolution requirements would enrich
> the future IETF standardization work, your attendance would be very
> important. And I believe this would benefit for IETF promotion.
> 
> More information for ETSI NGP ISG:
> 
> ETSI NGP White page,
> http://www.etsi.org/technologies-clusters/white-papers-and-brochures/etsi-
> white-papers
> 
> ETSI NGP portal, https://portal.etsi.org/tb.aspx?tbid=844&SubTB=844

When we are a bit nearer the time, I’d love to get some feedback on the kinds of messages to send. Lars’ name also appears above...

Jari

---

From: Aaron Falk <[email-masked]>
Date: Tue, 21 Jun 2016 11:55:38 -0400

+lars who, FWIW, says he has not agreed to be on the NGP IP2020 agenda.  

> On Jun 21, 2016, at 11:17 AM, Jari Arkko <[email-masked]> wrote:
> 
>

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 21 Jun 2016 15:55:14 +0000

+1 to ekr

On 2016-06-21, at 15:24, Eric Rescorla <[email-masked]> wrote:
> 
> Obviously, it's up to the IAB to determine how it wants to spend its time, but is it really productive to enter into an exchange of liaison statements in this case?
> 
> My experience has been that when dealing with an organization that is basically hostile to our values we tehd try to spend a lot of time negotiating when what we really should be doing is ignoring them and continuing to advance our own agenda.
> 
> -Ekr
> 
> 
> On Tue, Jun 21, 2016 at 6:17 AM, Ralph Droms (rdroms) <[email-masked] <mailto:[email-masked]>> wrote:
> > On Jun 20, 2016, at 6:13 AM 6/20/16, Mirja Kühlewind <[email-masked] <mailto:[email-masked]>> wrote:
> >
> >> Am 06.06.2016 um 15:59 schrieb Aaron Falk <[email-masked] <mailto:[email-masked]>>:
> >>
> >> Brian-
> >>
> >> On Mon, Jun 6, 2016 at 9:28 AM Brian Trammell <[email-masked] <mailto:[email-masked]>> wrote:
> >> hi Natasha, all,
> >>
> >>> On 06 Jun 2016, at 10:03, Brian Trammell <[email-masked] <mailto:[email-masked]>> wrote:
> >>>
> >>> hi Natasha, all,
> >>>
> >>>> On 01 Jun 2016, at 15:47, Natasha Rooney <[email-masked] <mailto:[email-masked]>> wrote:
> >>>>
> >>>> Hi guys,
> >>>>
> >>>> Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | [email-masked] <mailto:[email-masked]> | +44 (0) 7730 219 765 <tel:%2B44%20%280%29%207730%20219%20765> | @thisNatasha | Skype: [email-masked] <mailto:[email-masked]>
> >>>>
> >>>>
> >>>>>
> >>>>> Email:  [email-masked] <mailto:[email-masked]> , Mobile: +44 773 196 0000 <tel:%2B44%20773%20196%200000>
> >>>>>
> >>>> This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 356 0600 <tel:%2B44%20207%20356%200600> and highlight the error.
> >>>>
> >>>>>
> >>>>> This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 356 0600 <tel:%2B44%20207%20356%200600> and highlight the error.
> >>>>>
> >>>> [email-masked] <mailto:[email-masked]>
> >>>> https://www.iab.org/mailman/listinfo/stackevo <https://www.iab.org/mailman/listinfo/stackevo>
> >>>
> >>> [email-masked] <mailto:[email-masked]>
> >>> https://www.iab.org/mailman/listinfo/stackevo <https://www.iab.org/mailman/listinfo/stackevo>
> >>
> >> [email-masked] <mailto:[email-masked]>
> >> https://www.iab.org/mailman/listinfo/stackevo <https://www.iab.org/mailman/listinfo/stackevo>
> >> --
> >> --aaron
> >>
> >> [email-masked] <mailto:[email-masked]>
> >> https://www.iab.org/mailman/listinfo/stackevo <https://www.iab.org/mailman/listinfo/stackevo>
> >
> > [email-masked] <mailto:[email-masked]>
> > https://www.iab.org/mailman/listinfo/stackevo <https://www.iab.org/mailman/listinfo/stackevo>
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.iab.org/mailman/listinfo/stackevo <https://www.iab.org/mailman/listinfo/stackevo>
> 
>

---

From: Lars Eggert <[email-masked]>
Date: Tue, 21 Jun 2016 17:57:31 +0200

> +lars who, FWIW, says he has not agreed to be on the NGP IP2020 agenda.

Right! Do they have my name listed somewhere as a speaker?

(I think the topic they want me to speak on makes no sense at all, so I'm too keen on doing this. Plus, it looks like this is a Huawei company thing rather than something from ETSI.)

Lars