Subject: [5gangip] FW: ETSI has opened a new Industry Specification Group on so-called Next Generation Protocols

From: <[email-masked]>
Date: Mon, 1 Feb 2016 16:24:08 +0100

Dear all,
some news which may apply to this list ...

'ETSI creates new standardization group to pave the way for Next Generation Protocols ... forward leaps in the technology of the local access networks will not deliver their full potential unless, in parallel, the underlying protocol stacks used in core and access networks evolve. The development of future 5G systems presents a unique opportunity to address this issue, as a sub-optimal protocol architecture can negate the huge performance and capacity improvements planned for the radio access network'
Quoted from
http://www.etsi.org/news-events/news/1058-2016-01-news-etsi-creates-new-standardization-group-to-pave-the-way-for-next-generation-protocols

BTW their ToR at https://portal.etsi.org/Portals/0/TBpages/NGP/Docs/NGP_ISG_ToR.pdf talks about planned liaisons also with IETF.

Best Regards
Dirk

---

From: Ca By <[email-masked]>
Date: Mon, 1 Feb 2016 07:55:38 -0800

On Mon, Feb 1, 2016 at 7:24 AM, <[email-masked]> wrote:

> Dear all,
> some news which may apply to this list …
> ‘ETSI creates new standardization group to pave the way for Next
> Generation Protocols … forward leaps in the technology of the local access
> networks will not deliver their full potential unless, in parallel, the
> underlying protocol stacks used in core and access networks evolve. The
> development of future 5G systems presents a unique opportunity to address
> this issue, as a sub-optimal protocol architecture can negate the huge
> performance and capacity improvements planned for the radio access network’
> Quoted from
>
> *http://www.etsi.org/news-events/news/1058-2016-01-news-etsi-creates-new-standardization-group-to-pave-the-way-for-next-generation-protocols*
> <http://www.etsi.org/news-events/news/1058-2016-01-news-etsi-creates-new-standardization-group-to-pave-the-way-for-next-generation-protocols>
>
> BTW their ToR at
> *https://portal.etsi.org/Portals/0/TBpages/NGP/Docs/NGP_ISG_ToR.pdf*
> <https://portal.etsi.org/Portals/0/TBpages/NGP/Docs/NGP_ISG_ToR.pdf>
> talks about planned liaisons also with IETF.
> Best Regards
> Dirk
>
>
>

I am sure great things will come from this, but i do remain concerned they
are going to re-invent WAP or something similar to decouple their telco
service from the "free and open internet"

>
> _______________________________________________
> 5gangip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/5gangip
>
>

---

From: <[email-masked]>
Date: Mon, 22 Feb 2016 10:59:22 +0000

Hi all,

I tend to discuss next generation protocol topics within IETF or IRTF the organizations with a lot of protocol expertise.
Nevertheless, maybe some initial ideas and requirements come from this group.

Br, Rüdiger

Von: 5gangip [mailto:[email-masked]] Im Auftrag von Ca By
Gesendet: Montag, 1. Februar 2016 16:56
An: von Hugo, Dirk
Cc: [email-masked]
Betreff: Re: [5gangip] FW: ETSI has opened a new Industry Specification Group on so-called Next Generation Protocols

On Mon, Feb 1, 2016 at 7:24 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Dear all,
some news which may apply to this list …
‘ETSI creates new standardization group to pave the way for Next Generation Protocols … forward leaps in the technology of the local access networks will not deliver their full potential unless, in parallel, the underlying protocol stacks used in core and access networks evolve. The development of future 5G systems presents a unique opportunity to address this issue, as a sub-optimal protocol architecture can negate the huge performance and capacity improvements planned for the radio access network’
Quoted from
http://www.etsi.org/news-events/news/1058-2016-01-news-etsi-creates-new-standardization-group-to-pave-the-way-for-next-generation-protocols

I am sure great things will come from this, but i do remain concerned they are going to re-invent WAP or something similar to decouple their telco service from the "free and open internet"

_______________________________________________
5gangip mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/5gangip

---

From: Richard Li <[email-masked]>
Date: Mon, 22 Feb 2016 15:51:57 +0000

Definitely! This group could and should be a nice forum to conduct research on some issues to be addressed in NGP ISG of ETSI.

Right now, NGP is in its beginning of defining, designing or optimizing protocols for a “more efficient” internet to provide mobility, scale, security and ease of deployment required for a connected society beyond the year 2020.

For example, 5G is coming in the next few years. But the industry seems to be divided by what should qualify as a true 5G. I have attended some 5G meetings myself, and I found that most are working on something like this:

5G radio + 4G Core (with improvements)

They are still taking 4G/LTE core as 5G core. But what is in demand should be

5G radio + 5G Core

As a truly 5G, the real distinguisher lies in

1)      Ultra-low latency like 1ms

2)      Ultra-high BW/throughput like 1Gps-10Gps

It is not easy to design a new core to meet the above two requirements.

The current IP is connectivity-centric. Additional features such as mobility and security are added as optional patches and fix-ups. Moreover, protocols have been designed in a segmented way instead of an architectural way.

To stir up discussions, I am starting from two items:

1.      Data plane

Suppose that a “thing” is connected to the internet through a 5G network. If you look at the user/data plane protocol stack, you will find that there is 6-plus layers in a packet header. If you consider the MPLS-based IP RAN, you will easily run into 8 or even 10+ layers in a packet header. Some layers have their own checksums. However, a Thing packet may have only 1 byte payload. In this case, we would not call it efficient, since it is efficiency rate is less than 1% if we define the efficiency as (payload length)/(packet size).

As an engineer, I would ask if we should really keep using 4G core for 5G applications? I doubt it. A work item could be “data plane protocol stack reduction”:

1)      Which layers could be reduced?

2)      What would happen if we take away GTP?

3)      How can we deal with multiple checksums, since it is very expensive to compute checksums, remembering we only have 1ms latency budget.

4)      Should we design a new type of protocol that does not reuse the existing ones to make the network more efficient? This could be a big thing.

2.      Control plane

If you are interested in the control plane, there are even much more we need to consider. For example, the current internet is operated by routing protocols and their extensions. And these protocols are usually driven by CLIs on the first hand. If you configure

interface ethernet 0/0/0
ip ospf cost 100
ip ospf hello-interval 1
ip ospf dead-interval 1
…

Then ospf will work as instructed by these commands.

However, in a connected society, there will be many moving “things”, perhaps with low-power so that at one instant they are “up” and at the next instant they are “down”. The traditional operation model won’t work any more, since we can’t easily configure them and we don’t want their mobility and status change affects RIB frequently.

In this case, the control plane automation will arise. There have been some efforts in IETF such as auto-config. But they are far from enough.

It will be nice if a network can be self-configured, self-organized, self-diagnosed, self-healed.

There is another IRTF list on network machine learning, that I believe relates to control plane automation.

3.      Mobility

In IETF, there have been many efforts and RFCs on mobility. But none of them has been officially accepted by 3GPP and implemented in 4G/LTE core. But why? There’ve got to be something that is not all right. A cell phone moves, but its ID doesn’t change. Can we re-think about ID related protocols such as LISP? Can we re-scope it to just mobility. There is a USA NSF project, called MobilityFirst, where ID plays a central role in mobility. Any hint can we draw from MobilityFirst? Some other efforts include HIP, LINA, GSE, HIMALIS, and so on. Can we take all of them into consideration to design a new protocol, say ID-Oriented Networking Protocol. In future, more and more mobile things are connected to the internet: connected cars, connected drones, connected elderly persons, etc.

Just some quick thoughts to stir up this list.

Regards,

Richard

From: 5gangip [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, February 22, 2016 10:59 AM
To: [email-masked]
Subject: Re: [5gangip] FW: ETSI has opened a new Industry Specification Group on so-called Next Generation Protocols

Hi all,

Br, Rüdiger

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 22 Feb 2016 11:03:47 -0600

Hi Richard,

Thanks for  your proposal to structure our discussions.
Let's open up each of these three items and understand them better and
then see if we can come up with a presentation in IETF 95.

I have some clarification questions below:

On Mon, Feb 22, 2016 at 9:51 AM, Richard Li <[email-masked]> wrote:
> Definitely! This group could and should be a nice forum to conduct research
> on some issues to be addressed in NGP ISG of ETSI.
>
>
>
> Right now, NGP is in its beginning of defining, designing or optimizing
> protocols for a “more efficient” internet to provide mobility, scale,
> security and ease of deployment required for a connected society beyond the
> year 2020.
>
>
>
> For example, 5G is coming in the next few years. But the industry seems to
> be divided by what should qualify as a true 5G. I have attended some 5G
> meetings myself, and I found that most are working on something like this:
>
>
>
> The current IP is connectivity-centric. Additional features such as mobility
> and security are added as optional patches and fix-ups. Moreover, protocols
> have been designed in a segmented way instead of an architectural way.
>
>
>
> Suppose that a “thing” is connected to the internet through a 5G network. If
> you look at the user/data plane protocol stack, you will find that there is
> 6-plus layers in a packet header. If you consider the MPLS-based IP RAN, you
> will easily run into 8 or even 10+ layers in a packet header. Some layers
> have their own checksums. However, a Thing packet may have only 1 byte
> payload. In this case, we would not call it efficient, since it is
> efficiency rate is less than 1% if we define the efficiency as (payload
> length)/(packet size).
>

Don't have any idea on what these layers are? Are you talking about IP
layers, like v4/v6 header, UDP/TCP header?
I can think of only tunneling which would increase the number of packet headers?

>
>
> As an engineer, I would ask if we should really keep using 4G core for 5G
> applications? I doubt it. A work item could be “data plane protocol stack
> reduction”:
>

This is UDP.

>
> 3)      How can we deal with multiple checksums, since it is very expensive
> to compute checksums, remembering we only have 1ms latency budget.
>
> 4)      Should we design a new type of protocol that does not reuse the
> existing ones to make the network more efficient? This could be a big thing.
>
>
>
> 2.      Control plane
>
>
>
> If you are interested in the control plane, there are even much more we need
> to consider. For example, the current internet is operated by routing
> protocols and their extensions. And these protocols are usually driven by
> CLIs on the first hand. If you configure
>
>
>
> interface ethernet 0/0/0
>
> ip ospf cost 100
>
> ip ospf hello-interval 1
>
> ip ospf dead-interval 1
>
> …
>
>
>
> However, in a connected society, there will be many moving “things”, perhaps
> with low-power so that at one instant they are “up” and at the next instant
> they are “down”. The traditional operation model won’t work any more, since
> we can’t easily configure them and we don’t want their mobility and status
> change affects RIB frequently.
>
>
>
> In this case, the control plane automation will arise. There have been some
> efforts in IETF such as auto-config. But they are far from enough.
>
>
>

I thought these are the data plane protocols not control plane.

> In IETF, there have been many efforts and RFCs on mobility. But none of them
> has been officially accepted by 3GPP and implemented in 4G/LTE core. But
> why?

Because of Mobile IP.

> There’ve got to be something that is not all right. A cell phone moves,
> but its ID doesn’t change. Can we re-think about ID related protocols such
> as LISP? Can we re-scope it to just mobility. There is a USA NSF project,
> called MobilityFirst, where ID plays a central role in mobility. Any hint
> can we draw from MobilityFirst? Some other efforts include HIP, LINA, GSE,
> HIMALIS, and so on. Can we take all of them into consideration to design a
> new protocol, say ID-Oriented Networking Protocol. In future, more and more
> mobile things are connected to the internet: connected cars, connected
> drones, connected elderly persons, etc.
>
>

More thought on this and a presentation would be welcome.

> Subject: Re: [5gangip] FW: ETSI has opened a new Industry Specification
> Group on so-called Next Generation Protocols
>
>
>
> Hi all,
>
>
>
> I tend to discuss next generation protocol topics within IETF or IRTF the
> organizations with a lot of protocol expertise.
>
> Betreff: Re: [5gangip] FW: ETSI has opened a new Industry Specification
> Group on so-called Next Generation Protocols
>
>
>
>
>
>
>
> ‘ETSI creates new standardization group to pave the way for Next Generation
> Protocols … forward leaps in the technology of the local access networks
> will not deliver their full potential unless, in parallel, the underlying
> protocol stacks used in core and access networks evolve. The development of
> future 5G systems presents a unique opportunity to address this issue, as a
> sub-optimal protocol architecture can negate the huge performance and
> capacity improvements planned for the radio access network’
>
> Quoted from
>
> https://portal.etsi.org/Portals/0/TBpages/NGP/Docs/NGP_ISG_ToR.pdf talks
> about planned liaisons also with IETF.
>
> Best Regards
> Dirk
>
>
>
>
>
>
>

---

From: Rex Buddenberg <[email-masked]>
Date: Mon, 22 Feb 2016 10:21:11 -0800

Richard,

On Mon, 2016-02-22 at 15:51 +0000, Richard Li wrote:
> 3.     Mobility
> 
>  
> 
> In IETF, there have been many efforts and RFCs on mobility. But none
> of them has been officially accepted by 3GPP and implemented in 4G/LTE
> core. But why?
> 

Why?  because you have a collision between two engineering
cultures.  ... a recurrence of the Bellhead-Nethead collision that we
had in the wired world in the late '90s.

>From an IETF/IRTF point of view there are only two generations of
cellphone -- circuit switch and packet switch.  The first three
generations of cellphone were all circuit-switch -- the generational
changes were only in transmission, not switching.  LTE has been sold on
a lot of criteria, but the important (and usually missed by the
marketers) one is that it is a packet-switched protocol.  

The term 4G only makes sense in the context of cellphone development.
Which makes '5G' even more evanescent.  

A discussion at the IETF head-shed level needs to get off hobbyhorses
and think broader perspective.  The economy of layers is a (small) start
in the right direction.  Suggest that we should have three issues that
form the foundation of such a discussion:

Radio.  The wired internet is made up predominantly of point-to-point
physical connectivity (e.g. fiber).  Radio is fundamentally a shared
medium.  Impacts at about every layer in the protocol stack:
  - need a MAC where we didn't in wired connectivity -- layer 2 is
essentially vacuous in, say, DWDM.  
  - bandwidth limitations.  We can routinely provision fiber at 10s of
Gbits/sec per fiber.  And we can pick up a second fiber pair alongside
the first if we want more bandwidth.  Can't do this with radio.  And the
limitations are physics, not engineering.
  - multicast payoffs.  Multicast has had a poor uptake in the wired
internet because we could always get more bandwidth.  But multicast,
especially over the radio-WAN portion of the internetwork, has payoff.  

You're right, tinygrams are not handled efficiently by many existing
internet protocols (TCP among them).  These inefficiencies were
tolerated in the wired internet because they weren't very expensive.
But focusing on tinygrams by themselves paints you into a conceptual
corner.  Many of these tinygrams must go over an internetwork that
includes radio-WAN segments.  And many of the tinygrams are multicast in
nature.  

Discuss?

---

From: Richard Li <[email-masked]>
Date: Tue, 23 Feb 2016 17:41:45 +0000

Indeed, I kind of agree to many points.

Speaking about tinygrams, it was quoted as an example to show that the current 4G/EPC/LTE core is not efficient. When many IoT things are connected to the internet through 5G, there will be many such tinygrams. Actually There are more pains behind it. For example, if we trust that the most external checksum can protect the whole packet, we will not need the internal checksums. Because of 6-10 layers in the protocol stack in the 4G/LTE core, the checksum is computed multiple times. 

Speaking about TCP, I can easily show that TCP is not applicable to transporting ultra-high-definition VR streams. When 5G is deployed, new applications such as AR/VR will need new types of transport otherwise the users would not be able to experience what they could experience with pervasive bandwidth of 5G.

Richard

-----Original Message-----
From: Rex Buddenberg [mailto:[email-masked]] 
Sent: Monday, February 22, 2016 6:21 PM
To: Richard Li
Cc: [email-masked]; [email-masked]
Subject: Re: [5gangip] FW: ETSI has opened a new Industry Specification Group on so-called Next Generation Protocols

Richard,

Discuss?

---

From: Rex Buddenberg <[email-masked]>
Date: Tue, 23 Feb 2016 12:47:39 -0800

Bandwidth, or rather the far smaller sizes in radio, is really a
secondary issue with TCP.  The more critical problem is interactivity.

A TCP session has three parts -- open, transfer, close.  Each requires
interactivity: for example the open segment requires a Syn, Syn+ack and
Ack.  In an all-terrestrial, all-wired internetwork this is not a big
deal -- the plumbing itself (strings and routers) can handle it.  

But if you have a radio-WAN in your internetwork, and the radio-WAN has
a satellite in it, then the interactivity overhead gets worse.  The
caricature of how bad it is is with single-datagram messages.  Tot up
for yourself how many grams have to pass back and forth to open the
connection, send the single byte of data, assure it, and then close the
connection.     
     Now pencil out how long this takes if you have 300msec of
propagation time over the satcom link.  
     Some of the problem is TCP's design and some of it is in default
configurations:
     - TCP runs the Syn three-way handshake to completion before a
single byte of payload can be transmitted.  'Early open' algorithms
piggy back payload on the Syn frame (and can piggy back a Fin command as
well).  Implementations have been around, but the dominance of TCP has
made uptake rather slow.
     - normal configurations of TCP repeat the Syn command a half second
after the first, followed by a third Syn a second after that if nothing
heard.  What this means is that you are likely to have 2-3 Syns in the
air -- over the most constricted, expensive, segment of the internetwork
-- at one time when everything is working perfectly.  The default
implementation is a congestion-generator in satcom situations.  

This myopia is often repeated in applications.  Several years ago my
students showed me an implementation in US Navy using WWW browsers for
message composition.  Every byte typed by a shipboard message drafter
was sent to a server ashore.  Then the entire message had to be sent
back so it could be presented to the message releaser.  ... all to
satisfy the need to implement Fortezza-based infrastructure protection
security. 
     Applications that require lots of interactivity between end systems
are not going to work as well over radio-WAN-included internetworks as
they do in all-terrestrial ones.   But we shouldn't run around and make
the problem worse by application design.  

Definition (minor quibble).  The term tinygram relates back to the early
Terminal Access Controllers on the ARPANET where one typed in
character-by-character.  Tinygrams were one-byte datagrams.  
     The more productive discussion is around single-gram messages (with
a byte count up to the smallest MTA allowed in the segments of the
internetwork).  The overhead difference between a one-byte payload and a
100-byte one is negligible until you hit an MTA threshold where
fragmentation (in IPv4) occurs.  

On Tue, 2016-02-23 at 17:41 +0000, Richard Li wrote:
> Speaking about tinygrams, it was quoted as an example to show that the
> current 4G/EPC/LTE core is not efficient. When many IoT things are
> connected to the internet through 5G, there will be many such
> tinygrams. Actually There are more pains behind it. For example, if we
> trust that the most external checksum can protect the whole packet, we
> will not need the internal checksums. Because of 6-10 layers in the
> protocol stack in the 4G/LTE core, the checksum is computed multiple
> times. 
> 
> Speaking about TCP, I can easily show that TCP is not applicable to
> transporting ultra-high-definition VR streams. When 5G is deployed,
> new applications such as AR/VR will need new types of transport
> otherwise the users would not be able to experience what they could
> experience with pervasive bandwidth of 5G.
> 
> 
> 
> Richard
> 
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 24 Feb 2016 07:45:51 +0100 (CET)

> It is not easy to design a new core to meet the above two requirements.

I'd say it's impossible. The traditional "3GPP core" as it's been done 
needs to go away. There shouldn't be any central nodes involved in 
forwarding for most of the traffic.

I come from this viewpoint:

Customer has a thing in their home, potentially in their hand. They want 
it to "just work", wherever they are.

Traditionally today, for cost-to-the-consumer resons, people bother with 
fixed Internet+wifi and mobile subscriptions to solve this issue. Wifi 
because people are typically at home or at work, and they're billed 
per-byte for the "mobile network", and wifi is usually unmetered. Customer 
doesn't care if it's wifi or mobile, apart from the fact that one usually 
cost more money than the other. They just want "the internets" to work. 
Mobile handset manufacturers spend a lot of time making this transition 
work as seamless as they can, but it's still not seamless. If I walk out 
of my house with an ongoing VoIP call, transitioning from home wifi to the 
macro cell, my IP connectivity breaks.

So if we conflate this, the distinction that most people in the business 
make between "wifi" and "mobile" goes away. It's all "wireless access to 
the interwebs" to the customer, and an added complication they would 
rather avoid. I'd imagine 95% or more of the traffic towards end consumers 
today, traverse at least one wireless radio hop of some kind.

Bringing all of this together means that in order to be able to do billing 
etc for the wide area network (I still think this is going to be needed 
for macro cells), what we need is AAA coupled to a subscription for access 
control, and sometimes, for some traffic, mobility enabling tunneling. For 
most of the traffic, there is no need to run it via some mobility-enabling 
core, because the device never moves. It might be a video streaming 
application built into a TV. There is no need to do GTP tunneling for this 
traffic to enable mobility. Some traffic, for instance video streaming, 
it'd work well to just have hand-over by means of spatial overlap between 
cells and start downloading the data from a new IP address on the new 
cell.

I guess an analogy would be the Voice-over-wifi that some providers do, 
this is tunneled over any kind of Internet access, but if the same device 
does something else over the wifi (video streaming), then they don't 
tunnel the traffic. In my vision, both local radio and macro radio 
networks would work the same, where traffic that needs mobility would be 
tunneled to a "core" network, but traffic that does not need mobility 
(which is the bulk of the traffic if we can have a couple of seconds of IP 
connectivity overlap in the handover), would not be tunneled.

Things like MPTCP/SHIM6 style protocols could also help, and 5G could 
drive this kind of IP address independence, and hopefully further down the 
line, we wouldn't need core nodes involved in traffic at all.

This in my mind would be the most technically effective model, but then 
there are constraints like in some countries there are laws that require 
Legal Intercept. That's a tough one. So in some countries, there might be 
the requirement to tunnel all traffic, but I still think the 5G concept 
should allow for networks to not have to work in this mode if the local 
regulatory environment allows it.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Wed, 24 Feb 2016 09:14:40 +0000

The TCPM list might be a good venue to discuss potential "issues" with TCP, and to learn about existing solutions.

For what it is worth, quite a bit of what is written below is actually about Internet congestion control and thus not specific to TCP as transport protocol.

Michael

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of EXT Rex Buddenberg
Sent: Tuesday, February 23, 2016 9:48 PM
To: Richard Li
Cc: [email-masked]; [email-masked]
Subject: Re: [5gangip] FW: ETSI has opened a new Industry Specification Group on so-called Next Generation Protocols

Bandwidth, or rather the far smaller sizes in radio, is really a secondary issue with TCP.  The more critical problem is interactivity.

A TCP session has three parts -- open, transfer, close.  Each requires
interactivity: for example the open segment requires a Syn, Syn+ack and Ack.  In an all-terrestrial, all-wired internetwork this is not a big deal -- the plumbing itself (strings and routers) can handle it.  

But if you have a radio-WAN in your internetwork, and the radio-WAN has a satellite in it, then the interactivity overhead gets worse.  The caricature of how bad it is is with single-datagram messages.  Tot up for yourself how many grams have to pass back and forth to open the connection, send the single byte of data, assure it, and then close the
connection.     
     Now pencil out how long this takes if you have 300msec of propagation time over the satcom link.  
     Some of the problem is TCP's design and some of it is in default
configurations:
     - TCP runs the Syn three-way handshake to completion before a single byte of payload can be transmitted.  'Early open' algorithms piggy back payload on the Syn frame (and can piggy back a Fin command as well).  Implementations have been around, but the dominance of TCP has made uptake rather slow.
     - normal configurations of TCP repeat the Syn command a half second after the first, followed by a third Syn a second after that if nothing heard.  What this means is that you are likely to have 2-3 Syns in the air -- over the most constricted, expensive, segment of the internetwork
-- at one time when everything is working perfectly.  The default implementation is a congestion-generator in satcom situations.  

This myopia is often repeated in applications.  Several years ago my students showed me an implementation in US Navy using WWW browsers for message composition.  Every byte typed by a shipboard message drafter was sent to a server ashore.  Then the entire message had to be sent back so it could be presented to the message releaser.  ... all to satisfy the need to implement Fortezza-based infrastructure protection security. 
     Applications that require lots of interactivity between end systems are not going to work as well over radio-WAN-included internetworks as
they do in all-terrestrial ones.   But we shouldn't run around and make
the problem worse by application design.  

Definition (minor quibble).  The term tinygram relates back to the early Terminal Access Controllers on the ARPANET where one typed in character-by-character.  Tinygrams were one-byte datagrams.  
     The more productive discussion is around single-gram messages (with a byte count up to the smallest MTA allowed in the segments of the internetwork).  The overhead difference between a one-byte payload and a 100-byte one is negligible until you hit an MTA threshold where fragmentation (in IPv4) occurs.  

On Tue, 2016-02-23 at 17:41 +0000, Richard Li wrote:
> Subject: Re: [5gangip] FW: ETSI has opened a new Industry 
> Specification Group on so-called Next Generation Protocols
> 
> Richard,
> 
> > of them has been officially accepted by 3GPP and implemented in 
> > 4G/LTE core. But why?
> > 
> 
> Why?  because you have a collision between two engineering cultures.  
> ... a recurrence of the Bellhead-Nethead collision that we had in the 
> wired world in the late '90s.
> 
> changes were only in transmission, not switching.  LTE has been sold 
> on a lot of criteria, but the important (and usually missed by the
> and think broader perspective.  The economy of layers is a (small) 
> start in the right direction.  Suggest that we should have three 
> issues that form the foundation of such a discussion:
> 
> the first if we want more bandwidth.  Can't do this with radio.  And 
> the limitations are physics, not engineering.
> includes radio-WAN segments.  And many of the tinygrams are multicast 
> in nature.
> 
> Discuss?
> 
> 
>