Subject: [5gangip] FW: I-D Action: draft-johansson-cc-for-4g-5g-00.txt

From: "Miaofuyou (Miao Fuyou)" <[email-masked]>
Date: Thu, 15 Oct 2015 01:57:05 +0000

> -----Original Message-----
> From: I-D-Announce [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Thursday, October 15, 2015 2:17 AM
> To: [email-masked]
> Subject: I-D Action: draft-johansson-cc-for-4g-5g-00.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
>         Title           : Congestion control for 4G and 5G access
>         Author          : Ingemar Johansson
> 	Filename        : draft-johansson-cc-for-4g-5g-00.txt
> 	Pages           : 14
> 	Date            : 2015-10-14
> 
> Abstract:
>    This memo outlines the challenge that 4G and 5G access brings for
>    transport protocol congestion control and also outlines a few simple
>    examples that can improve transport protocol congestion control
>    performance in 4G and 5G access.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-johansson-cc-for-4g-5g/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-johansson-cc-for-4g-5g-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: <[email-masked]>
Date: Thu, 15 Oct 2015 15:44:41 +0200

Dear Fuyou, all,
Thank you for posting the announcement to the list. I think this draft is useful describing some performance issues due to wireless characteristics occurring and impacting upcoming systems (e.g. jitter due to as well as without congestion) and which have to be mitigated by correspondingly improved access and transport control mechanisms in future (5G) networks.
BTW other aspects which could be discussed here may also be related to SFC/SDN/NFV/... issues such as described in draft 
"Service Function Chaining Dataplane Elements in Mobile Networks" http://www.ietf.org/internet-drafts/draft-aranda-sf-dp-mobile-00
 ... but also in various others listed rather exhaustively in http://tools.ietf.org/googleresults?cx=011177064926444307064%3Arsqif7nmmi0&q=5G&cof=FORID%3A9 
;-)

Thanks for joining the discussion!
Best Regards
Dirk 
-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Miaofuyou (Miao Fuyou)
Sent: Donnerstag, 15. Oktober 2015 03:57
To: [email-masked]
Subject: [5gangip] FW: I-D Action: draft-johansson-cc-for-4g-5g-00.txt

> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
> 

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

---

From: Rex Buddenberg <[email-masked]>
Date: Thu, 15 Oct 2015 11:52:34 -0700

Dirk,

I just read the i-d and found it to be like viewing 4G through a WiFi
prism.  This gets some points, but it misses a lot.

Try this (I've no idea how to fit this stuff into the datatracker....;):

- topology.  WiFi is a LAN technology -- reach from last router to end
system.  So it's always at the fringe of the internet.  It's not used
for router-router interconect.  
     But the 4G protocols provide a contention-free MAC that is stable
under overload (it's also spectrum-efficient and manageable, qualities
that WiFi signally lacks).  The contention-free MAC makes the protocols
suitable for extending the internet to _routers_ on mobile platforms
(e.g. ships, aircraft, ambulances, fire trucks, to state a few rather
important ones).  This upsets a few norms that we've had in the (mostly
wired) internet over the past couple decades.

- capacity.  The terrestrial internet is composed of mostly fiber optic
links provisioned in the 10s of G territory. Further we can routinely
react to congestion by picking up a dark fiber pair and provisioning it.
We've solved the congestion control in the terrestrial WAN by
overprovisioning (actually since 1968).  
     But the radio-WAN is spectrum-limited, not technology limited.
Most 4G stuff yields 1-2 M of capacity (four orders of magnitude, or
10000x, less than the terrestrial-WAN).  And that capacity is shared
across all the subscriber stations in the segment.  So we do know
_where_ the congestion will occur -- at the routers bordering the
radio-WAN.  (Hint: there's a role for diff-serv, imho).

- shared medium.  The terrestrial WAN is overwhelmingly made up of fiber
optic cabling.  (So there's no MAC at all in those layer 2 protocols).
But the radio-WAN is, er, radio.  Shared medium.  This presents a
requirement and an opportunity:
  o the requirement is for some means of sharing the medium -- a MAC.
And you have two choices -- contention and contention-free.  By embrace
of 4G/5G in the discussion group, you've opted for the latter (only
correct choice for radio-WAN).  
  o the opportunity is the there is all-sudden an enormous payoff to
multicast.  Because it provides bandwidth efficiency at exactly the
place you need it most -- the inelastic capacity radio-WAN.       

I'd hope that this discussion would lead to maturing things like
multicast IP, multicast transport protocols and multicast applications
that actually use multicast.  
    The corollary is that we need end-to-end (layer 6/7) security in
these applications, along with management agents.  

I can (vaguely) see a host of problems, looming out there.  A taste:
  - multicast groups would be highly dynamic.  
  - PKI management for true end-end security is much more involved than
we've gotten so far.
  - management (to meet the third principle of high availability
engineering) has to be much better than it is now (involved discussion
of what 'better' means herein).  
  - congestion control.  There are beaucoup knobs in the 4G protocols
but not much idea how to control them or link them to higher layer
protocols.  For example, what should the linkage between diff-serv and
tyhe 802.16 MAC be?  And how should an emergency phone call be able to
differentiate itself fron a non-urgent phone chat?  Set the DSCP?  How
many apps do that these days?

Hoping this starts a productive discussion ....

b

---

From: Bill Gage <[email-masked]>
Date: Thu, 15 Oct 2015 20:38:32 +0000

I just have a couple of comments, marked by [wg>]  ...

Bill Gage 

Huawei Canada Research Centre
Wireless Technology & Research
Ottawa, Canada

mailto: [email-masked]
tz:     Eastern Time, Canada (UTC-05:00 + 01:00 DST)

> From: Rex Buddenberg [mailto:[email-masked]]
> Sent: Thursday, October 15, 2015 2:53 PM
> 
> Dirk,
> 
[wg>] I think this is a bit of an over-simplification -- there is no contention-based uplink channel (yet) in LTE but there is certainly contention for resources; that's what the scheduler manages. One can avoid all contention in LTE by, for example, assigning a semi-persistent schedule to a UE, but that typically wastes radio resources and/or impacts latency.

As for 5G (and maybe 4.5G), I believe we will see one or more forms of contention-based uplink channels for small packet bursts to overcome the signalling overheads and latencies associated with current LTE procedures.

> overprovisioning (actually since 1968).
[wg>] This is a generalisation that may not be applicable in all deployments. Many operators lease their backhaul/fronthaul facilities with a cost related to (distance*bandwidth)/(max_latency). So for these operators, adding wireline capacity significantly increases their OPEX.

[wg>] In other instances, a base station may not be served by fibre. Ploughing fibre into the ground is expensive and requires, amongst other things, that one obtain a right-of-way from the nearest fibre attachment point to the base station site. This is especially true for many small cell deployments. In many cases, wireless backhaul is the preferred solution ... and you are back to square one -- limited spectrum for backhaul. However, the use of highly directional antennas helps a lot with this.

> radio-WAN.  (Hint: there's a role for diff-serv, imho).
[wg>] What do you mean by "routers bordering the radio-WAN"? Are you talking about (routers associated with) the base stations or do you mean a network node between a base station and a border gateway? Perhaps we should start with a network model ;-)

[wg>] BTW, I don't expect the 4G model to survive into 5G. NGMN (amongst others) have indicated that things like PGW, SGW, PCRF, etc have outlived their usefulness and that a new, leaner network architecture is required.

[wg>] And you are right, we do know where the congestion will occur (Hint: it's always the radio link ;-).

> correct choice for radio-WAN).
[wg>] As I noted above, (current) 4G/LTE only provides a contention-free option. 5G will likely provide both contention-based and contention-free modes of operation, some of which may be back-ported to 4.5G/LTE.

> place you need it most -- the inelastic capacity radio-WAN.
[wg>] Multicast assumes that multiple devices are simultaneously ready to receive the same content. In an era of on-demand media, this doesn't happen very often so the gains for multicast are almost non-existent. Broadcasting of live events (news, sports) is the only case where this makes sense ... and you don't need the overhead of multicast group management to make this feasible. 
> many apps do that these days?
[wg>] The most significant congestion will occur on the radio link. DiffServ won't help you here. What is required is a transport protocol that is more forgiving than TCP to sudden fluctuations in throughput, error rate, round trip delay, etc and a means to couple conditions at the (radio) link layer to decisions at the transport (and application) layer. In other words, a better end-to-end, cross-layer protocol stack design.

[wg>] As for security, I see the big challenge is in the area of massive deployments of low cost MTC devices. we need authentication and, perhaps, privacy solutions that match the simplicity and cost of MTC devices, the hands-off deployment of those devices, and the sporadic nature of machine-type communications.

[wg>] The current mobility solutions don't work well in a network model of dense small cells where a change in attachment point can occur suddenly due to movement of the device or due to changes in the radio link environment (e.g. interference, shadowing). They also don't work well for devices that sporadically transmit small packet bursts (e.g. background traffic for applications on a smartphone, or most machine-type communications).
> Hoping this starts a productive discussion ....
[wg>] Me too :-)   Cheers ...
> > Thank you for posting the announcement to the list. I think this draft
> is useful describing some performance issues due to wireless
> characteristics occurring and impacting upcoming systems (e.g. jitter due
> to as well as without congestion) and which have to be mitigated by
> correspondingly improved access and transport control mechanisms in future
> (5G) networks.
> > BTW other aspects which could be discussed here may also be related to
> SFC/SDN/NFV/... issues such as described in draft
> > "Service Function Chaining Dataplane Elements in Mobile Networks"
> http://www.ietf.org/internet-drafts/draft-aranda-sf-dp-mobile-00
> >  ... but also in various others listed rather exhaustively in
> http://tools.ietf.org/googleresults?cx=011177064926444307064%3Arsqif7nmmi0
> &q=5G&cof=FORID%3A9
> > ;-)
> >

---

From: Rex Buddenberg <[email-masked]>
Date: Thu, 15 Oct 2015 15:08:27 -0700

On Thu, 2015-10-15 at 20:38 +0000, Bill Gage wrote:
> And that capacity is shared
> [wg>] What do you mean by "routers bordering the radio-WAN"? Are you
> talking about (routers associated with) the base stations or do you
> mean a network node between a base station and a border gateway?
> Perhaps we should start with a network model ;-)

See the attached cartoons.  

I misspoke slightly (you caught me typing too fast).  To the internet,
the congestion will be manifest at the routers bordering the radio-WAN.
You're right -- the actual congestion will be over the radio-WAN
itself.  

We have a good deal of the radio-WAN infrastructure out there, but it's
often used as the backhaul (and therefore invisible to the user) with a
WiFi hotspot at the LAN end of things.

---

From: Bill Gage <[email-masked]>
Date: Thu, 15 Oct 2015 23:27:30 +0000

Oh good, let's trade cartoons ;-)

I see that you are defining the "radio-WAN" as a network segment connecting something at the edge of the network to something at an aggregation/dissemination site (I hesitate to call it a "router" because it may be something simpler -- or more complex -- than that).

In my cartoon, the "radio-WAN" could be employed either on the fronthaul or the midhaul (and may encompass the sidehaul). Aggregation/dissemination can be performed within the radio access cluster and at any of the backhaul UNI points.

The backhaul segment is likely an optical-based transport in most networks of interest. Midhaul (and sidehaul) is where one can expect a mix of physical layer technologies (fibre, radio, ... copper?) depending on the economics of a given deployment.

So, where are the routers? In most cellular systems, the real routers are deployed at a metro or regional level in the thing I have labelled "mobile control and services centre (MCSC)" (i.e. a "central office"). In many deployments we have a (leased) pseudo-wire connecting a cluster to the MCSC -- i.e. all traffic to and from the cluster goes over the pseudo-wire so there really aren't any routing decisions to make in the cluster.

The ability to perform local breakout from the cluster to a "local" Internet access point may change that somewhat, but the complexity of the routing decisions may be minimal (e.g. equivalent to those of a home router).

Since this an IETF discussion, I assume that we will *not* be focussing on the fronthaul where the transport may be customised to address the bandwidth/latency problems of that segment.

Sidehaul might be an interesting area, topologically speaking. In small cell deployments, it may be connecting femtocells scattered along a street or over an open area using something like wireless mesh technologies; in this case, the femtocells may require routing (or switching) intelligence.

Congestion can obviously occur in any of these segments and at any of the aggregation points. It becomes important to be able to signal congestion detected by any of these below-IP layer technologies up through the protocol stack to the IP, transport and application layers. <draft-ietf-tsvwg-ecn-encap-guidelines> is one activity that appears to be starting to address this issue.

Hope that helps. Cheers ...

> Sent: Thursday, October 15, 2015 6:08 PM
> To: Bill Gage
> Cc: [email-masked]; [email-masked]; [email-masked];
> Miaofuyou (Miao Fuyou)
> Subject: Re: Problem areas for 5G
>