Subject: Re: [Detnet] DetNet Use Case Draft 05 (comments on chapter-6 and chapter-7)

From: Balázs Varga A <[email-masked]>
Date: Mon, 29 Feb 2016 17:17:34 +0000

Hi,

great work on the use-case document to make it converged.

I have several comments on chapter 6 (Cellular Radio Use Cases) and
chapter 7 (Cellular Coordinated Multipoint Processing (CoMP)).

My major comment would be that the group should consider to merge these chapters:
(i) both of them are dealing with cellular networks and (ii) COMP is a particular scenario for
Midhaul. So from use-case perspective they are highly related and the motivation
for DetNet is the same.

@Ethan: I would be happy to provide an initial merged text if that is the
direction and You would find it helpful.

Further comments/clarifications/proposals are below.

Cheers Bala’zs

Ps: detailed comments are:
Comment1,            6.1.1. Network Architecture
Text below Figure 7. deals with transport delay requirements and should have a new sub-chapter.

Proposed change in the text would result as:
"6.1.2. Delay Requirements"

Comment2,            6.1.1. Network Architecture
Text below Figure 7. contains example numbers that are not inline
with CPRI Cooperation recommendations. The widely used requirement
for transport of CPRI signal is 100 usec one-way-delay.
Therefore text should reflect a more realistic networking scenario.

Proposed change in the text would result as:
"The available processing time for Fronthaul networking overhead is
limited to the available time after the baseband processing of the
radio frame has completed. For example in Long Term Evolution (LTE)
radio, processing of a radio frame is allocated 3ms, but typically
the processing use most of it and allows only a small fraction
to be used by the Fronthaul network (100usec one way delay for CPRI). This
ultimately determines the distance the remote radio heads can be
located from the base stations (100us equals roughly 20 km of optical
fiber-based transport).

Considering packet based transport this transport allocated time
(i.e. 100 usec) is consumed by all nodes and buffering between the
remote radio head and the baseband processing unit, plus the
distance-incurred delay."

Comment3,            6.1.2. Time Synchronization Requirements
As today's Fronthaul networks are not packet based it is misleading
to write here about Packet Delay Variation. Packetization is for
future transport solution of Fronthaul. Therefore PDV reference is
proposed to be eliminated in this chapter.

Proposed change in the text would result as:
"Timing Alignment Error:
Timing Alignment Error (TEA) is problematic to Fronthaul
networks and must be minimized. If the transport network cannot
guarantee low enough TEA then additional buffering has to be
introduced at the edges of the network to buffer out the jitter.
Buffering is not desirable as it reduces the total available delay
budget."

Comment4,            6.1.3. Time-Sensitive Stream Requirements
Text deals with loss requirements, so rename chapter:
"6.1.3. Loss Requirements"

Comment5,            6.1.3. Time-Sensitive Stream Requirements
There are multiple reasons why a packet gets lost during transport.
BER is just one of the reasons. Others are e.g. buffer overflow,
network failure, rerouting. Text also mixes requirements and possible
solutions, therefore some cleaning would be proposed.

Proposed change in the text would result as:
"Fronthaul (and Midhaul) networks assume almost error-free
transport. Errors may result in reset of radio interfaces, what may
cause broken radio connectivity for mobile customers or decremented
throughput.

For packetized Fronthaul and Midhaul connections packet loss may be
caused by BER, congestion and network failure scenarios.
Current tool-kits to elminate packet losses have serious challenges
in case of Fronthaul and Midhaul networks. Retransmitting lost
packets and/or using forward error correction (FEC) to circumvent bit
errors is practically impossible due to the additional delay
incurred. Using redundant streams for better guarantees for delivery
is also practically impossible in many cases due to high bandwidth
requirements of Fronthaul and Midhaul networks. Protection switching
is also a candidate but current technologies for the path switch are
too slow to avoid reset of mobile interfaces."

Comment6,            6.2. Cellular Radio Networks Today
So far text deals only with Fronthaul and Midhaul networks. Backhaul
was not considered to require DetNet functionalities.
Statement in this chapter should refer for which type of the Haul
networks they are valid. Creating sub-chapters could make it more
clear (i.e. Fronthaul needs optical transport, Mid/Backhaul can be done
over packet networks).

Proposed change in the text would result as:
"6.2.1 Fronthauls
Today’s Fronthaul networks typically consist of:
o Dedicated point-to-point fiber connection is common
o Proprietary protocols and framings
o Custom equipment and no real networking
Current solutions for Fronthaul are direct optical cables or WDM
connections.

6.2.2 Midhauls and Backhauls
!!! All further statements are valid for Mid- and Backhaul networks
used todays. That should be made clear by changing "cellular domain"
to Mid- and Backhaul" in the remaining text of this chapter. !!!
"

Comment7,            6.3. Cellular Radio Networks Future
This sub-chapter is somewhat unstructured. Two key messages should be
named more explicitly as it is done in current text:
- Not all "cellular radio network" traffic will be IP, some of them
will remain at lower layer (e.g. Ethernet based). DetNet solutions
must address all of them with the same tool-kit and allow of their
transport simultaneously.
- All form of xHaul networks will need some form of DetNet solutions.
In addition to Fronthaul and Midhaul connections with the advent of
5G some traffic of the Backhaul will also have DetNet requirements
(e.g. traffic belonging to time critical 5G applications).

Proposed additional text at the beginning of the sub-chapter:
" Future Cellular Radio Networks will be based on a mix of different xHaul networks
(xHaul = front-, mid- and backhaul). Therefore transport networks should be able to
support all of them simultaneously. It is already envisioned today, that:
o Not all "cellular radio network" traffic will be IP, some of them
will remain at lower layer (e.g. Ethernet based). DetNet solutions
must address all  traffic types (L2, L3) with the same tool-kit and
allow of their transport simultaneously.
o All form of  xHaul networks  will need some form of DetNet solutions.
In addition to Fronthaul and Midhaul connections with the advent of
5G some traffic of the Backhaul will as well have DetNet requirements
(e.g. traffic belonging to time critical 5G applications).
"

Comment8,            6.4. Cellular Radio Networks Ask
General statements are fine, but Fronthaul related bullet points are for further discussion.
Therefore proposed to be deleted.
Proposal: delete text starting with "Mapping the Fronthaul requirements to IETF DetNet ..."

-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of Grossman, Ethan A.
Sent: Tuesday, February 23, 2016 11:02 PM
To: [email-masked]
Subject: [Detnet] DetNet Use Case Draft 05

Hi Folks,

This version updates the Wireless for Industrial section to match the accepted format.

Note that this use case is different than the others in that its intent is not only to present "another application for DetNet" but also to point out places where the needs for protocol development for DetNet and the 6TiSCH wireless standard overlap. Thus this section highlights these potential overlaps such that we can eventually determine which are "in scope" for DetNet.

Ethan.

-----Original Message-----

From: detnet [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>

Sent: Tuesday, February 23, 2016 1:42 PM

To: [email-masked]<mailto:[email-masked]>

Cc: [email-masked]<mailto:[email-masked]>

Subject: [Detnet] I-D Action: draft-ietf-detnet-use-cases-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

This draft is a work item of the Deterministic Networking of the IETF.

        Title           : Deterministic Networking Use Cases

        Authors         : Ethan Grossman

                          Craig Gunther

                          Pascal Thubert

                          Patrick Wetterwald

                          Jean Raymond

                          Jouni Korhonen

                          Yu Kaneko

                          Subir Das

                          Yiyong Zha

                          Balázs Varga

                          János Farkas

                          Franz-Josef Goetz

                          Juergen Schmitt

                Filename        : draft-ietf-detnet-use-cases-05.txt

                Pages           : 76

                Date            : 2016-02-23

Abstract:

   This draft documents requirements in several diverse industries to

   establish multi-hop paths for characterized flows with deterministic

   properties.  In this context deterministic implies that streams can

   be established which provide guaranteed bandwidth and latency which

   can be established from either a Layer 2 or Layer 3 (IP) interface,

   and which can co-exist on an IP network with best-effort traffic.

   Additional requirements include optional redundant paths, very high

   reliability paths, time synchronization, and clock distribution.

   Industries considered include wireless for industrial applications,

   professional audio, electrical utilities, building automation

   systems, radio/mobile access networks, automotive, and gaming.

   For each case, this document will identify the application, identify

   representative solutions used today, and what new uses an IETF DetNet

   solution may enable.

The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-detnet-use-cases/

There's also a htmlized version available at:

https://tools.ietf.org/html/draft-ietf-detnet-use-cases-05

A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-use-cases-05

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/

_______________________________________________

detnet mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/detnet

_______________________________________________

detnet mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/detnet

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 29 Feb 2016 12:46:03 -0800

Hi,

I'll respond to some points here since I think large junks of text in 
some form under Section 6. originally came from me.

2/29/2016, 9:17 AM, Balázs Varga A kirjoitti:
> *@Ethan: I would be happy to provide an initial merged text if that is 
> the*
>
> *direction and You would find it helpful. *
>
> *Comment1,            6.1.1. Network Architecture*
>
> //
> /Proposed change in the text would result as: /
>
> /"6.1.2. Delay Requirements"/
>

This is OK.

> //
>
> *Comment2,            6.1.1. Network Architecture*
>

The text does not have to be in line with CPRI cooperation requirements. 
And intentionally does not state that here.
>
> /Proposed change in the text would result as: /
>
> /"The available processing time for Fronthaul networking overhead is/
>
> /limited to the available time after the baseband processing of the/
>
> /radio frame has completed. For example in Long Term Evolution (LTE)/
>
> /radio, processing of a radio frame is allocated 3ms, but typically/
>
> /the processing use most of it and allows only a small fraction /
>
> /to be used by the Fronthaul network (100usec one way delay for CPRI). 
> This /
>
> /ultimately determines the distance the remote radio heads can be /
>
> /located from the base stations (100us equals roughly 20 km of optical /
>
> /fiber-based transport). /
>
> //
>
> /Considering packet based transport this transport allocated time /
>
> /(i.e. 100 usec) is consumed by all nodes and buffering between the /
>
> /remote radio head and the baseband processing unit, plus the /
>
> /distance-incurred delay."/
>
I don't think this change is appropriate here. It can be, though, in the 
part of text that actually refers to CPRI.

> //
>
> *Comment3,            6.1.2. Time Synchronization Requirements *
>
Well.. OBSAI is packet based and deployed.
> proposed to be eliminated in this chapter.
Since the text is not only about CPRI I don't think removing this is OK. 
Clarifying that there are fronthauls where the text does not apply is fine.
>
> /Proposed change in the text would result as: /
>
> /"Timing Alignment Error:/
>
> /Timing Alignment Error (TEA) is problematic to Fronthaul /
>
> /networks and must be minimized. If the transport network cannot /
>
> /guarantee low enough TEA then additional buffering has to be /
>
> /introduced at the edges of the network to buffer out the jitter. /
>
> /Buffering is not desirable as it reduces the total available delay /
>
> /budget."/
>
> *Comment4,            6.1.3. Time-Sensitive Stream Requirements*
>
> /"6.1.3. Loss Requirements"/
>
> *Comment5,            6.1.3. Time-Sensitive Stream Requirements*
>
Cleaning the text here is good. However, I think buffer overflow as a 
reason for packet loss in fronthaul is non-starter. That means there is 
something really wrong in the deployment.
>
> /Proposed change in the text would result as: /
>
> /"Fronthaul (and Midhaul) networks assume almost error-free /
>
> /transport. Errors may result in reset of radio interfaces, what may /
>
> /cause broken radio connectivity for mobile customers or decremented /
>
> /throughput. /
>
> //
>
> /For packetized Fronthaul and Midhaul connections packet loss may be /
>
> /caused by BER, congestion and network failure scenarios./
>
Congestion in a case of midhaul yes but not really in fronthaul. If your 
fronthaul network is dimentsioned to face congestion with fronthaul 
connections you are in a trouble.
>
> //
>
> /Current tool-kits to elminate packet losses have serious challenges /
>
> /in case of Fronthaul and Midhaul networks. Retransmitting lost /
>
> /packets and/or using forward error correction (FEC) to circumvent bit /
>
> /errors is practically impossible due to the additional delay /
>
> /incurred. Using redundant streams for better guarantees for delivery /
>
> /is also practically impossible in many cases due to high bandwidth /
>
> /requirements of Fronthaul and Midhaul networks. Protection switching /
>
> /is also a candidate but current technologies for the path switch are /
>
> /too slow to avoid reset of mobile interfaces."/
>
This cleanup except for the congestion is fine.
>
> //
>
> *Comment6,            6.2. Cellular Radio Networks Today*
>
Good point. Should be corrected.
>
> /Proposed change in the text would result as:/
>
> /"6.2.1 Fronthauls/
>
> /Today’s Fronthaul networks typically consist of:/
>
> /o Dedicated point-to-point fiber connection is common/
>
> /o Proprietary protocols and framings/
>
> /o Custom equipment and no real networking/
>
> /Current solutions for Fronthaul are direct optical cables or WDM /
>
> /connections./
>
Ok.
>
> //
>
> //
>
> /6.2.2 Midhauls and Backhauls/
>
> /!!! All further statements are valid for Mid- and Backhaul networks /
>
> /used todays. That should be made clear by changing "cellular domain" /
>
> /to Mid- and Backhaul" in the remaining text of this chapter. !!!/
>
> /"/
>
Ok.
>
> //
>
> *Comment7,            6.3. Cellular Radio Networks Future*
>
> /Proposed additional text at the beginning of the sub-chapter: /
>
> /" Future Cellular Radio Networks will be based on a mix of different 
> xHaul networks*
> *(xHaul = front-, mid- and backhaul). Therefore transport networks 
> should be able to /
>
> /support all of them simultaneously. It is already envisioned today, 
> that:/
>
> /o Not all "cellular radio network" traffic will be IP, some of them /
>
> /will remain at lower layer (e.g. Ethernet based). DetNet solutions /
>
> /must address all **traffic types (L2, L3) with the same tool-kit and /
>
> /allow of their transport simultaneously./
>
> /o All form of **xHaul networks will need some form of DetNet solutions. /
>
> /In addition to Fronthaul and Midhaul connections with the advent of /
>
> /5G some traffic of the Backhaul will as well have DetNet requirements /
>
> /(e.g. traffic belonging to time critical 5G applications). /
>
> /"/
>
This is a good piece of text to add.
>
> //
>
> *Comment8,            6.4. Cellular Radio Networks Ask*
>
> /Proposal: delete text starting with "Mapping the Fronthaul 
> requirements to IETF DetNet ..."/
>
Ok.

Thanks for a very good review,
     Jouni
> //
> Note that this use case is different than the others in that its 
> intent is not only to present "another application for DetNet" but 
> also to point out places where the needs for protocol development for 
> DetNet and the 6TiSCH wireless standard overlap. Thus this section 
> highlights these potential overlaps such that we can eventually 
> determine which are "in scope" for DetNet.
>
> Ethan.
>
> From: detnet [mailto:[email-masked]] On Behalf Of 
> [email-masked] <mailto:[email-masked]>
>
> To: [email-masked] <mailto:[email-masked]>
>
> Cc: [email-masked] <mailto:[email-masked]>
>
> 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.
>
> [email-masked] <mailto:[email-masked]>
>
> [email-masked] <mailto:[email-masked]>
>
> [email-masked]