Subject: Re: [Detnet] WG Last Call: draft-ietf-detnet-use-cases-16

From: "Grossman, Ethan A." <[email-masked]>
Date: Tue, 19 Jun 2018 02:32:53 +0000

Hi David, WG,
Here is my understanding of the answers to your questions - others please chime in if I miss something here. If I don't hear any comment on this by the end of this week I will add some statement in the use cases drafts to clarify each of these points based on the explanations below. Obviously if there is comment I will integrate that instead. 

1) David> What about media (e.g., CRC) errors?

DetNet does not have a mechanism to affect the presence or absence of media errors, nor does TSN. Such errors are one reason why both TSN and DetNet have so much focus on redundant paths as a means to provide a given level of reliability of packet delivery. 

2) David> Is this just about bandwidth, or a more general notion of network
resources including capacity for queueing/buffering, even though bandwidth may be the most user-visible resource?

The user notion of a specific amount of bandwidth is what is being provided by a DetNet network; any underlying network resources are implied to be "sufficient" but are otherwise opaque at the DetNet interface. 

Best,
Ethan.
P.S. These are the only LC comments on the Use Cases draft that I know of (apart from Lou's Shepherd Review comments) - if you sent some other comments and are waiting for a reply, please re-send them.

-----------------------------------------------------------------------
-----Original Message-----
From: Black, David [mailto:[email-masked]] 
Sent: Friday, May 25, 2018 2:36 PM
To: Lou Berger <[email-masked]>; DetNet WG <[email-masked]>
Cc: DetNet Chairs <[email-masked]>
Subject: RE: [Detnet] WG Last Call: draft-ietf-detnet-use-cases-16

Looking at Section 11 (which is starting to tease out common requirements) from a Transport (Area) viewpoint, I have a couple of questions:

11.1.6.  Guaranteed End-to-End Delivery

   Packets sent over DetNet are guaranteed not to be dropped by the
   network due to congestion.  (Packets may however be dropped for
   intended reasons, e.g.  per security measures).

David> What about media (e.g., CRC) errors?

11.1.9.  Unused Reserved BW to be Available to Best Effort Traffic

   If bandwidth reservations are made for a stream but the associated
   bandwidth is not used at any point in time, that bandwidth is made
   available on the network for best-effort traffic.  If the owner of
   the reserved stream then starts transmitting again, the bandwidth is
   no longer available for best-effort traffic, on a moment-to-moment
   basis.  Note that such "temporarily available" bandwidth is not
   available for time-sensitive traffic, which must have its own
   reservation.

David> Is this just about bandwidth, or a more general notion of network
resources including capacity for queueing/buffering, even though bandwidth may be the most user-visible resource?

Thanks, --David

> -----Original Message-----
> From: detnet [mailto:[email-masked]] On Behalf Of Lou Berger
> Sent: Wednesday, May 16, 2018 8:31 AM
> To: DetNet WG
> Cc: DetNet Chairs
> Subject: [Detnet] WG Last Call: draft-ietf-detnet-use-cases-16
> 
> All,
> 
> This starts a two-week working group last call for
> draft-ietf-detnet-use-cases-16
> 
> The working group last call ends on May 30.
> Please send your comments to the detnet mailing list.
> 
> Positive comments, e.g., "I've reviewed this document and believe it 
> is ready for publication", are welcome!
> This is useful and important, even from authors.
> 
> Thank you,
> DetNet Chairs
> 
> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet

---

From: "Black, David" <[email-masked]>
Date: Tue, 19 Jun 2018 13:58:31 +0000

Hi Ethan,

> DetNet does not have a mechanism to affect the presence or absence of
> media errors, nor does TSN. Such errors are one reason why both TSN and
> DetNet have so much focus on redundant paths as a means to provide a
> given level of reliability of packet delivery.

Please add a mention of errors to this text to avoid any implication that delivery is assured/guaranteed in the absence of security restrictions:

e.g., per security measures -> e.g., due to checksum errors or security measures

> The user notion of a specific amount of bandwidth is what is being provided
> by a DetNet network; any underlying network resources are implied to be
> "sufficient" but are otherwise opaque at the DetNet interface.

I think this is ok - no text change needed.

Thanks, --David

> From: Grossman, Ethan A. [mailto:[email-masked]]
> Sent: Monday, June 18, 2018 10:33 PM
> To: Black, David; DetNet WG
> Cc: DetNet Chairs
> Here is my understanding of the answers to your questions - others please
> chime in if I miss something here. If I don't hear any comment on this by the
> end of this week I will add some statement in the use cases drafts to clarify
> each of these points based on the explanations below. Obviously if there is
> comment I will integrate that instead.
> 
> DetNet does not have a mechanism to affect the presence or absence of
> media errors, nor does TSN. Such errors are one reason why both TSN and
> DetNet have so much focus on redundant paths as a means to provide a
> given level of reliability of packet delivery.
> 
> The user notion of a specific amount of bandwidth is what is being provided
> by a DetNet network; any underlying network resources are implied to be
> "sufficient" but are otherwise opaque at the DetNet interface.
> 
> Best,
> Ethan.
> P.S. These are the only LC comments on the Use Cases draft that I know of
> (apart from Lou's Shepherd Review comments) - if you sent some other
> comments and are waiting for a reply, please re-send them.
> 
> Looking at Section 11 (which is starting to tease out common requirements)
> from a Transport (Area) viewpoint, I have a couple of questions:
>

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Tue, 19 Jun 2018 17:37:05 +0000

Thanks David. Here is what I plan for item #1 below: 

Was:   Packets sent over DetNet are guaranteed not to be dropped by the network due to congestion.  (Packets may however be dropped for intended reasons, e.g.  per security measures).

Is:  Packets sent over DetNet are guaranteed not to be dropped by the network due to congestion.  However, the network may drop packets for intended reasons, e.g.  per security measures. Also note that this guarantee applies to the actions of DetNet protocol software, and does not provide any guarantee against lower level errors such as media errors or checksum errors. 

Regarding item #2, I understand your comment to mean that the text as currently published in use cases draft 16 is acceptable as is, i.e. I am not adding the text from my reply below. 

Ethan. 

-----Original Message-----
From: Black, David [mailto:[email-masked]] 
Sent: Tuesday, June 19, 2018 6:59 AM
To: Grossman, Ethan A. <[email-masked]>; DetNet WG <[email-masked]>
Cc: DetNet Chairs <[email-masked]>; Black, David <[email-masked]>
Subject: RE: [Detnet] WG Last Call: draft-ietf-detnet-use-cases-16

Hi Ethan,

> media errors, nor does TSN. Such errors are one reason why both TSN 
> and DetNet have so much focus on redundant paths as a means to provide 
> a given level of reliability of packet delivery.

> 2) David> Is this just about bandwidth, or a more general notion of 
> network resources including capacity for queueing/buffering, even 
> though bandwidth may be the most user-visible resource?
> 
> The user notion of a specific amount of bandwidth is what is being 
> provided by a DetNet network; any underlying network resources are 
> implied to be "sufficient" but are otherwise opaque at the DetNet interface.

Thanks, --David

> Here is my understanding of the answers to your questions - others 
> please chime in if I miss something here. If I don't hear any comment 
> on this by the end of this week I will add some statement in the use 
> cases drafts to clarify each of these points based on the explanations 
> below. Obviously if there is comment I will integrate that instead.
> 
> media errors, nor does TSN. Such errors are one reason why both TSN 
> and DetNet have so much focus on redundant paths as a means to provide 
> a given level of reliability of packet delivery.
> 
> 2) David> Is this just about bandwidth, or a more general notion of 
> network resources including capacity for queueing/buffering, even 
> though bandwidth may be the most user-visible resource?
> 
> The user notion of a specific amount of bandwidth is what is being 
> provided by a DetNet network; any underlying network resources are 
> implied to be "sufficient" but are otherwise opaque at the DetNet interface.
> 
> Best,
> Ethan.
> P.S. These are the only LC comments on the Use Cases draft that I know 
> of (apart from Lou's Shepherd Review comments) - if you sent some 
> other comments and are waiting for a reply, please re-send them.
> 
> Looking at Section 11 (which is starting to tease out common 
> requirements) from a Transport (Area) viewpoint, I have a couple of questions:
> 
> David> Is this just about bandwidth, or a more general notion of 
> David> network
> resources including capacity for queueing/buffering, even though 
> bandwidth may be the most user-visible resource?
> 
> Thanks, --David
>

---

From: "Black, David" <[email-masked]>
Date: Tue, 19 Jun 2018 18:38:11 +0000

Looks good to me, Thanks, --David

> Sent: Tuesday, June 19, 2018 1:37 PM
> Was:   Packets sent over DetNet are guaranteed not to be dropped by the
> network due to congestion.  (Packets may however be dropped for intended
> reasons, e.g.  per security measures).
> 
> Is:  Packets sent over DetNet are guaranteed not to be dropped by the
> network due to congestion.  However, the network may drop packets for
> intended reasons, e.g.  per security measures. Also note that this guarantee
> applies to the actions of DetNet protocol software, and does not provide any
> guarantee against lower level errors such as media errors or checksum
> errors.
> 
> Regarding item #2, I understand your comment to mean that the text as
> currently published in use cases draft 16 is acceptable as is, i.e. I am not
> adding the text from my reply below.
> 
> Ethan.
> 
> Please add a mention of errors to this text to avoid any implication that
> delivery is assured/guaranteed in the absence of security restrictions:
>