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

Hi Ethan,

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

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

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).

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

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

I think this is ok - no text change needed.

Thanks, --David

> -----Original Message-----
> From: Grossman, Ethan A. [mailto:eagros@dolby.com]
> Sent: Monday, June 18, 2018 10:33 PM
> To: Black, David; DetNet WG
> Cc: DetNet Chairs
> Subject: RE: [Detnet] WG Last Call: draft-ietf-detnet-use-cases-16
> 
> 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:David.Black@dell.com]
> Sent: Friday, May 25, 2018 2:36 PM
> To: Lou Berger <lberger@labn.net>; DetNet WG <detnet@ietf.org>
> Cc: DetNet Chairs <detnet-chairs@ietf.org>
> 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:detnet-bounces@ietf.org] 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
> > detnet@ietf.org
> > https://www.ietf.org/mailman/listinfo/detnet