Subject: Re: [Detnet] draft-finn-detnet-architecture-03 comments??

From: "Norman Finn (nfinn)" <[email-masked]>
Date: Thu, 10 Mar 2016 18:37:40 +0000

See in-line

-----Original Message-----
From: detnet <[email-masked]> on behalf of "Schmitt, Juergen"
<[email-masked]>
Date: Thursday, March 10, 2016 at 07:14 AM
To: "[email-masked]" <[email-masked]>
Subject: Re: [Detnet] draft-finn-detnet-architecture-03 comments??

>Hi Norm,
>
>First of all thank you for the great work in this document.
>I have just collected some notes which may be interesting to talk about.
>
>In the following I copied parts of the clause in question with may
>proposal for change:
>
>
>Snippet: 
>==========================================================================
>========
>2.  Terminology
>...
>
>   reservation
>           A trail of configuration from source to destination(s)
>           through relay systems associated with a DetNet flow, required
>           to deliver the benefits of DetNet.
>
>END-Snippet: 
>==========================================================================
>=====
>
>I don’t see that the flow of configuration is just from source to
>destination. I would argue in some of  today’s RSVP-Models the opposite
>is true.
>Many models are imaginable.  So I wouldn’t mention any direction here.

Maybe, “… Configuration between source and destination(s) …”

>Snippet: 
>==========================================================================
>========
>3. Providing the DetNet Quality of Service
>
>DetNet Quality of Service is expressed in terms of:
>
>o Minimum and maximum end-to-end latency from source to destination;
>
>o Probability of loss of a packet, assuming the normal operation of
>the relay systems and links;
>
>o Probability of loss of a packet in the event of the failure of a
>relay system or link.
>
>o Delay variation <-- NEW
>
>END-Snippet: 
>==========================================================================
>=====
>
>Delay variation is in my opinion also a very important criteria for
>Quality of Service.
>There are use-cases where it is more important, that the Packet arrives
>Just-In-Time, than the raw
>End-to-end latency.

Delay variation is critical, of course.  But isn’t that covered by minimum
and maximum latency?  “Delay variation” is often used in a probabilistic
sense around a mean, and probability has no place in DetNet.  In IEEE 802,
we have been speaking in terms of an absolute must-deliver-before (max
latency) and an absolute must-deliver-after (min latency).  It’s just a
matter of how you juggle the numbers; you could talk about worst-case max
latency and delay variation, instead of max latency and min latency, but
you don’t want all three terms, and IMO, “delay variation” carries
unwanted plus-or-minus baggage that confuses the issue.

>Just a comment to clause 6.4. Peer-to-peer reservation protocol:
>
>I think this is a interesting model. It is surely debatable within the
>network. But as an Interface for endstations (Talkers and Listeners) this
>can be very useful.
>Not to forget about small customer networks which need also a simple to
>administer network with end-to-end QoS and Ad-Hoc reservation.

Thank you for the helpful comments.

— Norm

>Best regards,
>Jürgen
>
>
>-----Ursprüngliche Nachricht-----
>Von: detnet [mailto:[email-masked]] Im Auftrag von Norman Finn
>(nfinn)
>Gesendet: Donnerstag, 10. März 2016 00:29
>An: [email-masked]
>Betreff: [Detnet] draft-finn-detnet-architecture-03 comments??
>
>In our plan from November, we talked about adopting an architecture draft.
>There is a draft for one, and time comment and revise it before the
>deadline for April.  Is it so good there is nothing more to say?  :)  :)
>
>https://www.ietf.org/internet-drafts/draft-finn-detnet-architecture-03.txt
>
>
>— Norm
>
>_______________________________________________
>detnet mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/detnet
>_______________________________________________
>detnet mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/detnet

---

From: "Schmitt, Juergen" <[email-masked]>
Date: Mon, 14 Mar 2016 08:26:31 +0000

See in-line

Regards
Jürgen

>Von: detnet [mailto:[email-masked]] Im Auftrag von Norman Finn (nfinn)
>Gesendet: Donnerstag, 10. März 2016 19:38
>An: Schmitt, Juergen; [email-masked]
>Betreff: Re: [Detnet] draft-finn-detnet-architecture-03 comments??
>
>See in-line
>

Ok.

>>o Probability of loss of a packet, assuming the normal operation of the 
>>relay systems and links;
>>
>>Just-In-Time, than the raw End-to-end latency.
>
>Delay variation is critical, of course.  But isn’t that covered by minimum and maximum latency?  “Delay variation” is often used in a probabilistic sense around a mean, and probability has no place in DetNet.  In IEEE 802, we have been speaking in terms of an absolute must-deliver-before (max
>latency) and an absolute must-deliver-after (min latency).  It’s just a matter of how you juggle the numbers; you could talk about worst-case max latency and delay variation, instead of max latency and min latency, but you don’t want all three terms, and IMO, “delay variation” carries unwanted plus-or->minus baggage that confuses the issue.
>

Thank you for the clarification. It wasn't clear to me, that the term "delay variation" is already biased within the IETF. So I'm fine to define this just in an implicit way as it is in this document. 

>>network. But as an Interface for endstations (Talkers and Listeners) 
>>this can be very useful.

---

From: Simon Barber <[email-masked]>
Date: Tue, 15 Mar 2016 15:26:40 -0700

In 802.11 networks it is not possible to guarantee delay (fundamentally due
to use of unlicensed part 15 spectrum), yet it is possible to control it to
acceptable limits in most practical situations. Does the terminology in use
here allow for use cases where an 802.11 link is involved?

---

From: "Norman Finn (nfinn)" <[email-masked]>
Date: Thu, 17 Mar 2016 03:34:37 +0000

I agree completely with your comments about 802.11.  The terminology in the architecture draft certainly doesn’t prohibit the use of 802.11 links.  The adopted use cases draft draft-ietf-detnet-use-cases-08 talks about wireless industrial applications.  There are a number of references in the architecture draft to wireless technologies in the “Informative References” section.

On the other hand, there isn’t anything specific about wireless or 802.11 in the main text.  I’d say that’s something that needs to be corrected.  Unless someone has a better suggestion, I’ll put in a placeholder, and mention your points about latency, retries, and reliability before Monday.

Thanks!!

— Norm

From: "Simon Barber (sibarber)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 16, 2016 at 06:26 AM
To: Norman Finn <[email-masked]<mailto:[email-masked]>>
Cc: "Schmitt, Juergen" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Detnet] draft-finn-detnet-architecture-03 comments??

In 802.11 networks it is not possible to guarantee delay (fundamentally due to use of unlicensed part 15 spectrum), yet it is possible to control it to acceptable limits in most practical situations. Does the terminology in use here allow for use cases where an 802.11 link is involved?

On Thu, Mar 10, 2016 at 10:37 AM, Norman Finn (nfinn) <[email-masked]<mailto:[email-masked]>> wrote:
See in-line

-----Original Message-----
From: detnet <[email-masked]<mailto:[email-masked]>> on behalf of "Schmitt, Juergen"
<[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 10, 2016 at 07:14 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Detnet] draft-finn-detnet-architecture-03 comments??

— Norm

>Von: detnet [mailto:[email-masked]<mailto:[email-masked]>] Im Auftrag von Norman Finn
>(nfinn)
>An: [email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>

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

---

From: Simon Barber <[email-masked]>
Date: Thu, 17 Mar 2016 06:40:00 -0700

Thanks!

The main point is that in an unlicensed band the FCC part 15 says that 'you
will accept all interference' - thus it is impossible to provide any
guarantee of service. In reality you never know when the neighbor is going
to start to occupy the medium. In practice, in almost all situations by
using the appropriate priority mechanisms correctly you can get the traffic
you need delivered with decent latency bounds. It is a shared medium
though, so guarantees are not possible.

Simon

On Wed, Mar 16, 2016 at 8:34 PM, Norman Finn (nfinn) <[email-masked]>
wrote:

> I agree completely with your comments about 802.11.  The terminology in
> the architecture draft certainly doesn’t prohibit the use of 802.11 links.
> The adopted use cases draft draft-ietf-detnet-use-cases-08 talks about
> wireless industrial applications.  There are a number of references in the
> architecture draft to wireless technologies in the “Informative References”
> section.
>
> On the other hand, there isn’t anything specific about wireless or 802.11
> in the main text.  I’d say that’s something that needs to be corrected.
> Unless someone has a better suggestion, I’ll put in a placeholder, and
> mention your points about latency, retries, and reliability before Monday.
>
> Thanks!!
>
> — Norm
>
> From: "Simon Barber (sibarber)" <[email-masked]>
> To: Norman Finn <[email-masked]>
> Cc: "Schmitt, Juergen" <[email-masked]>, "
> [email-masked]" <[email-masked]>
>
> In 802.11 networks it is not possible to guarantee delay (fundamentally
> due to use of unlicensed part 15 spectrum), yet it is possible to control
> it to acceptable limits in most practical situations. Does the terminology
> in use here allow for use cases where an 802.11 link is involved?
>