Subject: [Detnet] Resolving the remaining Use Cases Draft Comments - Cellular Radio and Industrial M2M

From: "Grossman, Ethan A." <[email-masked]>
Date: Sun, 16 Dec 2018 05:03:17 +0000

Hi Jouni, Maik, Balazs, Janos (as DetNet Use Cases draft section authors),

Please help me out here - I have three remaining IESG review comments that are domain specific and I couldn't deduce answers for, as follows. Please send me some text.

Thanks,
Ethan (as DetNet Use Cases draft editor).

Jouni, Maik:
* Section 6.1.5

3GPP networks have some form of admission control to get access to these time sensitive streams. I think that it is important to mention that here

* Section 6.2.1.

How does CPRI fit the narrative here for the fronthaul? Do you think it falls under the proprietary protocol and framing category?

Balazs, Janos:
* Section 7.4

What does burstless mean (especially in the context of low packet loss)?

----------------------------------------------

---

From: Jouni <[email-masked]>
Date: Sun, 16 Dec 2018 12:09:56 +0200

Hi Ethan,

See my comments inline:

> On 16 Dec 2018, at 7.03, Grossman, Ethan A. <[email-masked]> wrote:
> 
> Please help me out here – I have three remaining IESG review comments that are domain specific and I couldn’t deduce answers for, as follows. Please send me some text.  
>  
> Thanks,

I think 3GPP bearer level admission control is not that trivial. Transport connections for fronthauls are established and managed separately from what happens at the bearer level i.e., they are more or less managed due their static nature. 

For the mid/backhaul to my recollection(!) the (standardized) admission control was based radio resources per se, not the transport network level. That means there is a possibility the admission control check could succeed at the 3GPP bearer level but then fail or resource availability assumptions fail at the transport network level. My data might be outdated what has happened past 6 months in 3GPP regarding this (ref e.g., slicing and up/cp separation but that is IMHO more for later sections under 6.x to discuss). I would not add any further text here.

> How does CPRI fit the narrative here for the fronthaul? Do you think it falls under the proprietary protocol and framing category?

Definitely. CPRI does not aim for inter-vendor interoperability in its own specifications. IMHO no need to mention CPRI here.

- Jouni

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

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Sun, 16 Dec 2018 19:50:19 +0000

Thanks Jouni, conclusion is no changes for those two items.
Ethan.

________________________________
From: Jouni <[email-masked]>
Sent: Sunday, December 16, 2018 2:10 AM
To: Grossman, Ethan A.
Cc: [email-masked]; Maik Seewald (maseewal); Balázs Varga A; János Farkas; Suresh Krishnan; [email-masked]
Subject: Re: [Detnet] Resolving the remaining Use Cases Draft Comments - Cellular Radio and Industrial M2M

Hi Ethan,

- Jouni

---

From: János Farkas <[email-masked]>
Date: Tue, 18 Dec 2018 17:21:03 +0100

Hi Ethan,

Maybe it is not a god phrase, but the intention with the phrase that the 
loss should be burstless was that consecutive packets should not be lost.
Perhaps the maximum consecutive loss tolerance parameter describes it 
better in 
https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model-02. 
It is the "maximum    number of consecutive packets whose loss can be 
tolerated"

Maybe updating the bullet in the use cases draft to:

"Low packet loss (0.1-1 %, limited number of consecutive packets)"

?

Regards,
Janos

On 12/16/2018 6:03 AM, Grossman, Ethan A. wrote:
> *_Balazs, Janos: _*

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Tue, 18 Dec 2018 19:31:34 +0000

Thanks Janos,
Doesn't 0.1-1% sound like an awful lot of packet loss?
Do I understand correctly that you mean:
"Low packet loss (0.1-1 % of packets can be lost, but only a bounded number of consecutive packets can be lost)"

I guess I still don't exactly understand the intent, can you please clarify?
Thanks, and sorry for being dense here.
Ethan.

From: János Farkas <[email-masked]>
Sent: Tuesday, December 18, 2018 8:21 AM
To: Grossman, Ethan A. <[email-masked]>
Cc: [email-masked]; Maik Seewald (maseewal) <[email-masked]>; Balázs Varga A <[email-masked]>; [email-masked]; Suresh Krishnan <[email-masked]>
Subject: Re: Resolving the remaining Use Cases Draft Comments - Cellular Radio and Industrial M2M

Hi Ethan,

Maybe it is not a god phrase, but the intention with the phrase that the loss should be burstless was that consecutive packets should not be lost.
Perhaps the maximum consecutive loss tolerance parameter describes it better in https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model-02<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Ddetnet-2Dflow-2Dinformation-2Dmodel-2D02&d=DwMD-g&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=0W0EQyafQ7HdKxGYDUDOn91m44yUJHQre2QdC0Pq5rI&s=xtlwetwJuYWGjTBmpNfLC8CvvhDk4x1YkRjNDTE0rws&e=>. It is the "maximum    number of consecutive packets whose loss can be tolerated"

?

Regards,
Janos

---

From: John Grant <[email-masked]>
Date: Wed, 19 Dec 2018 14:12:12 +0000

On 18/12/2018 19:31, Grossman, Ethan A. wrote:
>
> Thanks Janos,
>
> Doesn’t 0.1-1% sound like an awful lot of packet loss?
>
> "Low packet loss (0.1-1 % of packets can be lost, but only a bounded 
> number of consecutive packets can be lost)"
>
> I guess I still don’t exactly understand the intent, can you please 
> clarify?
>
It looks to me as if it's assumed that forward error correction will be 
needed. If you know you won't lose two consecutive packets, you can 
design the FEC around that assumption. On the other hand, if the network 
can reserve enough resource to ensure that level of service, you'd think 
it could manage to arrange that you don't lose any, except in very rare 
circumstances such as equipment malfunction. If the idea is to allow for 
interference on a radio link, I don't see how you can ensure that no 
burst of interference is long enough to affect two consecutive packets.

-- 
John Grant
Nine Tiles, Cambridge, England
+44 1223 862599 and +44 1223 511455
http://www.ninetiles.com

---

From: János Farkas <[email-masked]>
Date: Wed, 19 Dec 2018 17:12:30 +0100

I just tried to resolve the concern around burstless.

Actually, the numbers may not be right.

Checking IEC/IEEE 60802 contributions
https://1.ieee802.org/tsn/iec-ieee-60802-tsn-profile-for-industrial-automation/

Use Cases: 
http://www.ieee802.org/1/files/public/docs2018/60802-industrial-use-cases-0918-v13.pdf
and traffic type characterization: 
http://www.ieee802.org/1/files/public/docs2018/60802-ademaj-traffic-type-characterization-1118-v01.pdf
indicate that the most stringent requirement is zero loss.
The next one is how many consecutive packets may be lost
There are more relaxed cases.

This section is: 7.4.  Industrial M2M Asks

Maybe we should focus on the stringent cases.

What about updating the bullet to:

"Low packet loss (e.g., zero, limited number of consecutive packets)"

?

Regards,
Janos

On 12/18/2018 8:31 PM, Grossman, Ethan A. wrote:
> *From:*János Farkas <[email-masked]>
> *Sent:* Tuesday, December 18, 2018 8:21 AM
> *To:* Grossman, Ethan A. <[email-masked]>
> *Cc:* [email-masked]; Maik Seewald (maseewal) <[email-masked]>; 
> Balázs Varga A <[email-masked]>; [email-masked]; Suresh 
> Krishnan <[email-masked]>
> *Subject:* Re: Resolving the remaining Use Cases Draft Comments - 
> Cellular Radio and Industrial M2M
>
> Hi Ethan,
>
> Maybe it is not a god phrase, but the intention with the phrase that 
> the loss should be burstless was that consecutive packets should not 
> be lost.
> https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model-02 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Ddetnet-2Dflow-2Dinformation-2Dmodel-2D02&d=DwMD-g&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=0W0EQyafQ7HdKxGYDUDOn91m44yUJHQre2QdC0Pq5rI&s=xtlwetwJuYWGjTBmpNfLC8CvvhDk4x1YkRjNDTE0rws&e=>.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 19 Dec 2018 16:50:18 +0000

Hello  János

I agree to change the sentence. Zero is not reasonable in the real world, even in wired space : ) What about

"Low packet loss (e.g.,  one in a million, one in a billion, min time between losses, min packets between losses, strictly bounded number of consecutive losses)"
Maybe that's too many examples but when you look up the (old) art of "reliability " you end up with terms such as MTBF...
All the best

Pascal

From: detnet <[email-masked]> On Behalf Of János Farkas
Sent: mercredi 19 décembre 2018 17:13
To: Grossman, Ethan A. <[email-masked]>
Cc: [email-masked]; Suresh Krishnan <[email-masked]>; [email-masked]; Balázs Varga A <[email-masked]>; Maik Seewald (maseewal) <[email-masked]>
Subject: Re: [Detnet] Resolving the remaining Use Cases Draft Comments - Cellular Radio and Industrial M2M

Use Cases: http://www.ieee802.org/1/files/public/docs2018/60802-industrial-use-cases-0918-v13.pdf
and traffic type characterization: http://www.ieee802.org/1/files/public/docs2018/60802-ademaj-traffic-type-characterization-1118-v01.pdf
indicate that the most stringent requirement is zero loss.
The next one is how many consecutive packets may be lost
There are more relaxed cases.

?

Regards,
Janos

From: János Farkas <[email-masked]><mailto:[email-masked]>
Sent: Tuesday, December 18, 2018 8:21 AM
To: Grossman, Ethan A. <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Maik Seewald (maseewal) <[email-masked]><mailto:[email-masked]>; Balázs Varga A <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Suresh Krishnan <[email-masked]><mailto:[email-masked]>
Subject: Re: Resolving the remaining Use Cases Draft Comments - Cellular Radio and Industrial M2M

Hi Ethan,

?

Regards,
Janos

---

From: János Farkas <[email-masked]>
Date: Wed, 19 Dec 2018 17:57:58 +0100

Well, I'd not enter MTBF discussion at this stage.

It is just example in the brackets. What about skipping numbers to get:

"Low packet loss (e.g., limited number of consecutive packets)"

?

The special aspect brought in really is the aspect of consecutive packets.

Regards,
Janos

On 12/19/2018 5:50 PM, Pascal Thubert (pthubert) wrote:
>
> Hello János
>
> I agree to change the sentence. Zero is not reasonable in the real 
> world, even in wired space : ) What about
>
>
> "Low packet loss (e.g.,  one in a million, one in a billion, min time 
> between losses, min packets between losses, strictly bounded number of 
> consecutive losses)"
>
> Maybe that’s too many examples but when you look up the (old) art of 
> “reliability “ you end up with terms such as MTBF…
>
> All the best
>
> Pascal
>
> *From:*detnet <[email-masked]> *On Behalf Of *János Farkas
> *Sent:* mercredi 19 décembre 2018 17:13
> *Cc:* [email-masked]; Suresh Krishnan <[email-masked]>; 
> [email-masked]; Balázs Varga A <[email-masked]>; Maik 
> Seewald (maseewal) <[email-masked]>
> *Subject:* Re: [Detnet] Resolving the remaining Use Cases Draft 
> Comments - Cellular Radio and Industrial M2M
>
>     "Low packet loss (0.1-1 % of packets can be lost, but only a
>     bounded number of consecutive packets can be lost)"
>
>     I guess I still don’t exactly understand the intent, can you
>     please clarify?
>     <mailto:[email-masked]>
>     *To:* Grossman, Ethan A. <[email-masked]> <mailto:[email-masked]>
>     *Cc:* [email-masked] <mailto:[email-masked]>; Maik Seewald
>     (maseewal) <[email-masked]> <mailto:[email-masked]>;
>     Balázs Varga A <[email-masked]>
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>; Suresh Krishnan
>     <[email-masked]> <mailto:[email-masked]>
>     Maybe it is not a god phrase, but the intention with the phrase
>     that the loss should be burstless was that consecutive packets
>     should not be lost.
>     Perhaps the maximum consecutive loss tolerance parameter describes
>     it better in
>     It is the "maximum    number of consecutive packets whose loss can
>     be tolerated"
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 19 Dec 2018 17:00:58 +0000

Works for me, this is essential.

From: János Farkas <[email-masked]>
Sent: mercredi 19 décembre 2018 17:58
To: Pascal Thubert (pthubert) <[email-masked]>; Grossman, Ethan A. <[email-masked]>
Cc: [email-masked]; Suresh Krishnan <[email-masked]>; [email-masked]; Balázs Varga A <[email-masked]>; Maik Seewald (maseewal) <[email-masked]>
Subject: Re: [Detnet] Resolving the remaining Use Cases Draft Comments - Cellular Radio and Industrial M2M

?

Regards,
Janos

Pascal

From: detnet <[email-masked]><mailto:[email-masked]> On Behalf Of János Farkas
Sent: mercredi 19 décembre 2018 17:13
To: Grossman, Ethan A. <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Suresh Krishnan <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Balázs Varga A <[email-masked]><mailto:[email-masked]>; Maik Seewald (maseewal) <[email-masked]><mailto:[email-masked]>
Subject: Re: [Detnet] Resolving the remaining Use Cases Draft Comments - Cellular Radio and Industrial M2M

?

Regards,
Janos

Hi Ethan,

?

Regards,
Janos

---

From: "Maik Seewald (maseewal)" <[email-masked]>
Date: Wed, 19 Dec 2018 17:03:23 +0000

János,

There is the traffic type isochronous with no tolerance to packet loss.
The IIC contribution recently presented mandates this as well.

Cheers,
Maik

From: Janos Farkas <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 19. December 2018 at 17:12
To: "Grossman, Ethan A." <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Cisco Employee <[email-masked]<mailto:[email-masked]>>, Balázs Varga A <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Suresh Krishnan <[email-masked]<mailto:[email-masked]>>
Subject: Re: Resolving the remaining Use Cases Draft Comments - Cellular Radio and Industrial M2M

?

Regards,
Janos

Hi Ethan,

?

Regards,
Janos

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Wed, 19 Dec 2018 23:39:08 +0000

Thanks guys, based on the below, I'm writing:
Low packet loss (with bounded number of consecutive lost packets)
Ethan.

From: Pascal Thubert (pthubert) <[email-masked]>
Sent: Wednesday, December 19, 2018 9:01 AM
To: János Farkas <[email-masked]>; Grossman, Ethan A. <[email-masked]>
Cc: [email-masked]; Suresh Krishnan <[email-masked]>; [email-masked]; Balázs Varga A <[email-masked]>; Maik Seewald (maseewal) <[email-masked]>
Subject: RE: [Detnet] Resolving the remaining Use Cases Draft Comments - Cellular Radio and Industrial M2M

From: János Farkas <[email-masked]<mailto:[email-masked]>>
Sent: mercredi 19 décembre 2018 17:58
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>; Grossman, Ethan A. <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Suresh Krishnan <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Balázs Varga A <[email-masked]<mailto:[email-masked]>>; Maik Seewald (maseewal) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Detnet] Resolving the remaining Use Cases Draft Comments - Cellular Radio and Industrial M2M

?

Regards,
Janos

Pascal

Checking IEC/IEEE 60802 contributions
https://1.ieee802.org/tsn/iec-ieee-60802-tsn-profile-for-industrial-automation/<https://urldefense.proofpoint.com/v2/url?u=https-3A__1.ieee802.org_tsn_iec-2Dieee-2D60802-2Dtsn-2Dprofile-2Dfor-2Dindustrial-2Dautomation_&d=DwMFAw&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=qLsriWJHqceDZAep-8JipBEXaTAsQnbDCij4t4TnOWk&s=YVPeAe4TBdOg6T9hTqpMVFgZsRRka8WQV6Qe73keNSc&e=>

Use Cases: http://www.ieee802.org/1/files/public/docs2018/60802-industrial-use-cases-0918-v13.pdf<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ieee802.org_1_files_public_docs2018_60802-2Dindustrial-2Duse-2Dcases-2D0918-2Dv13.pdf&d=DwMFAw&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=qLsriWJHqceDZAep-8JipBEXaTAsQnbDCij4t4TnOWk&s=TJb3JOCGOrAdckcrIS6a_DiE9yfCk4fVDCx25jqwdBc&e=>
and traffic type characterization: http://www.ieee802.org/1/files/public/docs2018/60802-ademaj-traffic-type-characterization-1118-v01.pdf<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ieee802.org_1_files_public_docs2018_60802-2Dademaj-2Dtraffic-2Dtype-2Dcharacterization-2D1118-2Dv01.pdf&d=DwMFAw&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=qLsriWJHqceDZAep-8JipBEXaTAsQnbDCij4t4TnOWk&s=ohssmVbMlG6dchtLLaVKy-B5GyW7zH2J9IKMLKB1Kes&e=>
indicate that the most stringent requirement is zero loss.
The next one is how many consecutive packets may be lost
There are more relaxed cases.

?

Regards,
Janos

Hi Ethan,

?

Regards,
Janos