Subject: [Detnet] nits to draft-ietf-detnet-use-cases-14

From: Yaakov Stein <[email-masked]>
Date: Fri, 23 Mar 2018 17:51:03 +0000

During the meeting this morning I perused the use case document,
and found several issues that are worth fixing.

In section 6.2:
There are also existing solutions for TDM over IP such as [RFC5087]
and [RFC4553], as well as TDM over Ethernet transports such as
[RFC5086].
this should state
There are also existing solutions for TDM over IP such as [RFC4553], [RFC5086],
and [RFC5087], as well as TDM over Ethernet transports such as
[MEF8].
since SAToP, CESoPSN, and TDMoIP all specify MPLS and UDP/IP encaps,
but the IETF documents do not specify Ethernet transport.

In 6.1.2 the problem with delay in 5G is attributed solely to the low-delay slice,
and in 6.3 we have discussion of xHaul networks where x=front, mid, back.
This misses a fundamental feature of the 5G RAN, namely functional split options
(1 through 8). Split 1 is conventional backhaul and split 8 is conventional fronthaul
(downmixed and sampled RF). Splits between 2 and 7 are not "midhaul",
but rather transport between different blocks of the decomposed gNb.
The different splits have differing delay requirement, with higher numbered splits
being very delay sensitive even when the user traffic is not (due to constraints related to HARQ and ARQ).
I should note that there are proposals for IP encapsulations for these intermediate splits.

(minor nits in this section scheduling pf fronthaul -> scheduling of fronthaul, xHhaul -> xHaul)

Another issue not completely explained is the difference between ITU-T G.8271 time requirements
(Table 1 from 100 micro down to about 1.5 micro) and relative time requirements (Table 2 from 260 ns down to 65 ns).
G.8271.1 also has relevant information. The relative time requirement is similar to 3GPP's time alignment error.

Y(J)S

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Sat, 24 Mar 2018 02:11:10 +0000

Thanks Yaakov. Would you be willing to propose replacement text for the section? I am not an expert in this domain. Jouni, any comments or suggestions for replacement text?
Thanks,
Ethan.

From: detnet [mailto:[email-masked]] On Behalf Of Yaakov Stein
Sent: Friday, March 23, 2018 10:51 AM
To: [email-masked]
Subject: [Detnet] nits to draft-ietf-detnet-use-cases-14

In section 6.2:

Y(J)S

---

From: Jouni <[email-masked]>
Date: Wed, 28 Mar 2018 00:04:20 +0300

Hi,

Agree with the comment to Section 6.2. The proposed text is good.

Regarding Sections 6.1.2 and 6.3 comments for different splits now worked on in 3GPP, the text originates from late 2015 / early 2016 and obviously that time the scope (the authors) were more interested in the three discussed in the draft (as they also reflected the planned operator deployments). Even the architecture in Figure 10 is not very 5Gish anymore. Now that 5G numerology is better understood a lot of refinements could be done. However, I would be slightly reluctant to rework these Sections except for correcting errors.

- Jouni

> On 24 Mar 2018, at 04:11, Grossman, Ethan A. <[email-masked]> wrote:
> 
> (downmixed and sampled RF). Splits between 2 and 7 are not “midhaul”,
> G.8271.1 also has relevant information. The relative time requirement is similar to 3GPP’s time alignment error.
>  
> Y(J)S
>  
> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Tue, 27 Mar 2018 23:12:31 +0000

OK so my current plan is to incorporate Xuesong's new Slicing text and Yaakov's section 6.2 text below, and the typo's identified here (plus a few others) this week, then submit the draft. If anyone has anything else to add, please let me know by this Friday 30Mar18. 
Thanks,
Ethan.

-----Original Message-----
From: Jouni [mailto:[email-masked]] 
Sent: Tuesday, March 27, 2018 2:04 PM
To: Grossman, Ethan A. <[email-masked]>
Cc: Yaakov Stein <[email-masked]>; [email-masked]
Subject: Re: [Detnet] nits to draft-ietf-detnet-use-cases-14

Hi,

- Jouni

> During the meeting this morning I perused the use case document, and 
> found several issues that are worth fixing.
>  
> In section 6.2:
> There are also existing solutions for TDM over IP such as [RFC4553], 
> [RFC5086], and [RFC5087], as well as TDM over Ethernet transports such 
> as [MEF8].
> In 6.1.2 the problem with delay in 5G is attributed solely to the 
> low-delay slice, and in 6.3 we have discussion of xHaul networks where x=front, mid, back.
> (1 through 8). Split 1 is conventional backhaul and split 8 is 
> conventional fronthaul (downmixed and sampled RF). Splits between 2 
> and 7 are not “midhaul”, but rather transport between different blocks of the decomposed gNb.
> The different splits have differing delay requirement, with higher 
> numbered splits being very delay sensitive even when the user traffic is not (due to constraints related to HARQ and ARQ).
> Another issue not completely explained is the difference between ITU-T 
> G.8271 time requirements (Table 1 from 100 micro down to about 1.5 micro) and relative time requirements (Table 2 from 260 ns down to 65 ns).