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

From: Balázs Varga A <[email-masked]>
Date: Tue, 1 Mar 2016 12:58:54 +0000

Hi Jouni,

Many thanks for the feedback. Just for clarification copied here the problematic points for easier follow:

- 6.1.1. Network Architecture: CPRI reference
I agree with You that "The text does not have to be in line with CPRI cooperation requirements.".
However I think referring to CPRI cooperation numbers would add value as it is representing
a widely accepted fronthaul design parameter. We could also refer to it: 
http://www.ieee802.org/1/files/public/docs2015/cm-CPRI-requirements-1115-v01.pdf

I like your example numbers also as it shows that there are many possible allocation options of the available 
time budget (e.g. 3ms in LTE) between processing and transport. There are many recent discussions 
around this in the industry, so other numbers are also floating around.

- 6.1.2. Time Synchronization Requirements: Removal of PDV
I agree that text here is not only about CPRI ("Since the text is not only about CPRI I don't think removing this is OK. ")
But all the bullet points with reference to numerical values from 3GPP specification are naming explicitly TAE.
If the fronthaul network is packet based, then PDV can be derived from those TAE values. Therefore I think
reference to TAE is more appropriate.

- 6.1.3. Time-Sensitive Stream Requirements: congestion
I agree that fronthaul streams have to have zero packet loss due to congestion. However network failures may cause
congestion situation even in a well-designed network. So I would list congestion as a possible cause of packet loss,
but fully agree that under normal circumstances congestion should not hit fronthaul streams.

Cheers
Bala'zs

-----Original Message-----
From: Jouni Korhonen [mailto:[email-masked]] 
Sent: Monday, February 29, 2016 9:46 PM
To: Balázs Varga A; Grossman, Ethan A.; [email-masked]
Subject: Re: [Detnet] DetNet Use Case Draft 05 (comments on chapter-6 and chapter-7)

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:
>
> 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"/
>

This is OK.

> //
>
> *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.
>

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 *
>
> As today's Fronthaul networks are not packet based it is misleading
>
Well.. OBSAI is packet based and deployed.
>
> 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.
>
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*
>
> 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.
>
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*
>
> 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).
>
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*
>
> 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). /
>
> /"/
>
This is a good piece of text to add.
>
> //
>
> *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 ..."/
>
Ok.

Thanks for a very good review,
     Jouni
>
> //
>
> -----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
>
>
>
> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 4 Mar 2016 07:45:02 -0800

Hi Balazs,

> around this in the industry, so other numbers are also floating around.

We have an explicit reference to CPRI specification and more 
"discussion" on CPRI in general later in the text in Section 6.2. That 
should be enough. Maybe rearranging the text order in places would be 
needed.

> reference to TAE is more appropriate.
Section 6.1.2. already talks and point out TAE. The text is still about 
general describtion so I am not entirely sure what you want to change 
here and why.

> but fully agree that under normal circumstances congestion should not hit fronthaul streams.

This is OK.  We can state there are other causes for packet loss than 
bit errors.

- Jouni