Subject: Re: [Detnet] Traffic description in DetNet flow info model

From: Norman Finn <[email-masked]>
Date: Wed, 12 Jul 2017 07:34:04 +0000

Certainlly UDP is typical for applications in the industrial space.

But, given that DetNet can defend itself against misbehaving transmitters (by dropping packets), one could certainly supply an application with a CBR-like service over which one runs TCP.

In one sense, you might be better off using some technique like WFQ, so that you can get more bandwidth if it's available.  But, if the cost parameters are favorable, you can certainly imagine an SP using DetNet to offer CBR-over-best-effort services, over which TCP can certainly be run.  The downside compared to the usual techniques for this is that oversubscription of reservations is not allowed.  The upside is that the user gets every last bit of his contracted bandwidth, without random variations due to other customers' activity.

-- Norm

________________________________
From: detnet [[email-masked]] on behalf of Balázs Varga A [[email-masked]]
Sent: Tuesday, April 25, 2017 1:20 AM
To: John Grant; DetNet WG
Subject: Re: [Detnet] Traffic description in DetNet flow info model

Hi,

Good discussion.

As a general comment I think applications requiring DetNet transport should be UDP
based and not TCP (as retransmission would violate the transport parameters the
DetNet flow requires).

I think what Yiyong is looking for whether we can make better resource reservation
for DetNet flow being VBR than reserving for peak rate? With CBR we are on the safe
side, no doubt. However for example not all TSN queuing method (e.g., time gated
queues, etc.) can ensure that unused resources can be used by non-DetNet traffic.

Additionally, would be good to have feedback on how much applications would “like”
the shaping of DetNet flows. Shaping could help for better resource utilization,
but is it a good idea for DetNet?

I would like to ask the authors of the use-cases to comment what type of traffic is
used in their use-cases (CBR, VBR, something else). Maybe that would help to sort
this out.

Cheers
Bala’zs

From: detnet [mailto:[email-masked]] On Behalf Of John Grant
Sent: 2017. április 21. 16:20
To: DetNet WG <[email-masked]>
Subject: Re: [Detnet] Traffic description in DetNet flow info model

TCP isn't really intended for use with the kind of flows that would use CBR or VBR.

The main facilities provided by TCP are rate control and retransmission of lost packets. When transferring a block of data (such as, say, an image or a pre-recorded video or a PDF) over a best-effort service, these allow the transfer to make best use of what the network provides. But if the network service guarantees a particular data rate you don't need the kind of rate control that TCP does, and if the network hardly ever loses a packet you don't need frequent acknowledgements.

For instance, if you are sending live audio with a sampling rate of 48k samples per second, and packing 12 samples in a packet, you need to send a packet every 250 microseconds, so you need CBR with a rate of 4000 packets (of a certain size) per second.

The VBR service that was defined for ATM was intended for sending compressed video at constant quality, so that "busy" content needs more bits per frame than content with less detail. The peak rate is the bit rate for the "busiest" content, and the average bit rate was also signalled. I think the idea was that you could "overbook" a link by routing flows whose peak rates add up to more than the link capacity, in the expectation that they wouldn't all be demanding the peak rate at the same time. I think something similar is done with digital television multiplexes.

Note that with CBR (and VBR) the rate is determined by the application's requirements, whereas with TCP it is determined by what the best-effort service delivers.

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

On 21 Apr 2017, at 08:37, zhayiyong wrote:

Hi John,

Thank you for the reply. I agree that make reservation on peak rate is a simple solution. But the “peak rate” here depends on the observation interval times max packets per interval, which means for same flow, different interval leads to different peak rate. Below is a little testbed we built to test the burstness feature of TCP flow.
For the same 25Mbps TCP flow with no shaping:

1s observation interval, peak rate 450Mbps.

100ms observation interval, peak rate 900Mbps.

10ms observation interval, peak rate 1Gbps, which is the link speed/physical port speed.

And further test shows that, 8 of these TCP flows to a 1Gbps port cause packet loss. So my question is how can we make reservation based on “peak rate”? E.g., for the same flow, if we take 1s observation interval, we can serve 2 flows. But for 10ms observation interval, only 1 flow, which does not make sense. And it is hard to say long observation interval can guarantee delay and loss, since buffer in router is only milliseconds level.

Another thing is how to guarantee the source with max packets within the interval. If shaping is necessary, what kind of parameters are needed.

Cheers,
Yiyong
From: detnet [mailto:[email-masked]] On Behalf Of John Grant
Sent: Thursday, April 20, 2017 5:27 PM
To: DetNet WG
Subject: Re: [Detnet] Traffic description in DetNet flow info model

As pointed out in 4.1.2, for a VBR flow you have to make a reservation for the peak rate, and there isn't any reason to do anything other than use the service that is already defined for CBR. With circuit-switched systems any part of the reservation that wasn't used was wasted, but in packet-based systems it can be used for best-effort traffic, as stated in 4.3.2.

Regarding synchronous flows, the first paragraph of 4.3.2 explains that if the reservations on incoming and outgoing links are time-aligned then the latency, and hence the amount of buffer space required, can be minimised. The details mechanism for achieving that would, I think, be out of scope for an architecture document.

For a description of a system that implements synchronous flows, see clause 5 of ETSI GR NGP 003, available from the "specifications" tab at http://www.etsi.org/technologies-clusters/technologies/next-generation-protocols

John Grant
Nine Tiles, Cambridge, England
+44 1223 862599 and +44 1223 511455
http://www.ninetiles.com<http://www.ninetiles.com/>
On 20 Apr 2017, at 08:38, zhayiyong wrote:

Hi All,

Recently we have some discussion among authors of the two flow info model draft. The DetNet flow info model should provide some common concepts and description of the flow. One part is traffic specification of the flow. Here is something not clear, is DetNet dealing with VBR flows and what attributes are needed? And how to deal with VBR flow, for source guarantee purpose, do we need to define shaping parameters?

In architecture draft, section 4.1.2, “The traffic characteristics of an App-flow can be CBR (constant bit rate) or VBR (variable bit rate)”. In section 4.3.2, mentions synchronous flow and asynchronous flow, but no details of that.
In use case draft, for some cases such as industrial and BAS, it can assumes that the traffic is periodic with constant rate. For cases such as Cellular Radio and M2M, there is usually no assumption on the traffic. E.g., CoMP traffic is between two eNBs, it is hard to say the flow is constant rate.

Cheers,
Yiyong

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Wed, 12 Jul 2017 18:25:35 +0000

1)      In the pro audio and video space it seems to me that constant bitrate is the norm; variable rate stream formats exist however they aren't used that much in pro. One indication of that is that the (pre-packet-based A/V) industry is accustomed to point-to-point per-stream connections (in both analog and digital forms) for both audio and video.

2)      To me the spirit of DetNet (and AVB/TSN) has been the notion of guaranteeing a fixed amount of bandwidth per flow, and I don't exactly see how VBR would fit into the core of DetNet. Norm's suggestion that a user could lease a fixed amount of DetNet-enabled bandwidth then use that to transmit multiple TCP streams (which are essentially VBR, and in aggregate might be advantageous for multi-stream VBR traffic) makes about as much sense as I can see right now. If I'm missing something please let me know.
Ethan.

From: detnet [mailto:[email-masked]] On Behalf Of Norman Finn
Sent: Wednesday, July 12, 2017 12:34 AM
To: Balázs Varga A <[email-masked]>; John Grant <[email-masked]>; DetNet WG <[email-masked]>
Subject: Re: [Detnet] Traffic description in DetNet flow info model

-- Norm

Good discussion.

Additionally, would be good to have feedback on how much applications would "like"
the shaping of DetNet flows. Shaping could help for better resource utilization,
but is it a good idea for DetNet?

Cheers
Bala'zs

From: detnet [mailto:[email-masked]] On Behalf Of John Grant
Sent: 2017. április 21. 16:20
To: DetNet WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Detnet] Traffic description in DetNet flow info model

John Grant
Nine Tiles, Cambridge, England
+44 1223 862599 and +44 1223 511455
http://www.ninetiles.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ninetiles.com&d=DwMF-g&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=tS5EY8SXaTQuzywNz5HT0Jrgxk9GSRF2WhaHXBOAl4k&s=RmSC6BBktJC1J2slxfA-haYqlf34eB0oLtUd-Z-oSHY&e=>

Hi John,

Thank you for the reply. I agree that make reservation on peak rate is a simple solution. But the "peak rate" here depends on the observation interval times max packets per interval, which means for same flow, different interval leads to different peak rate. Below is a little testbed we built to test the burstness feature of TCP flow.
For the same 25Mbps TCP flow with no shaping:

And further test shows that, 8 of these TCP flows to a 1Gbps port cause packet loss. So my question is how can we make reservation based on "peak rate"? E.g., for the same flow, if we take 1s observation interval, we can serve 2 flows. But for 10ms observation interval, only 1 flow, which does not make sense. And it is hard to say long observation interval can guarantee delay and loss, since buffer in router is only milliseconds level.

Cheers,
Yiyong

For a description of a system that implements synchronous flows, see clause 5 of ETSI GR NGP 003, available from the "specifications" tab at http://www.etsi.org/technologies-clusters/technologies/next-generation-protocols<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.etsi.org_technologies-2Dclusters_technologies_next-2Dgeneration-2Dprotocols&d=DwMF-g&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=tS5EY8SXaTQuzywNz5HT0Jrgxk9GSRF2WhaHXBOAl4k&s=ML38iAvI654emuUqPEQU1n8X7v3dy0G3x6FIlK2yFhA&e=>

John Grant
Nine Tiles, Cambridge, England
+44 1223 862599 and +44 1223 511455
http://www.ninetiles.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ninetiles.com_&d=DwMF-g&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=tS5EY8SXaTQuzywNz5HT0Jrgxk9GSRF2WhaHXBOAl4k&s=JAKBl0WO6WGg8P0NfwBx-dcUfmUZ9AvKKEwQKEIx_p4&e=>
On 20 Apr 2017, at 08:38, zhayiyong wrote:

Hi All,

In architecture draft, section 4.1.2, "The traffic characteristics of an App-flow can be CBR (constant bit rate) or VBR (variable bit rate)". In section 4.3.2, mentions synchronous flow and asynchronous flow, but no details of that.
In use case draft, for some cases such as industrial and BAS, it can assumes that the traffic is periodic with constant rate. For cases such as Cellular Radio and M2M, there is usually no assumption on the traffic. E.g., CoMP traffic is between two eNBs, it is hard to say the flow is constant rate.

Cheers,
Yiyong

---

From: Norman Finn <[email-masked]>
Date: Thu, 13 Jul 2017 08:08:17 +0000

Thanks for the clarification, Ethan.  Yes, I was absolutely talking about a "CBR tunnel" service, though which a customer would be running any mix of traffic of any kind.  Either the customer or the provider could operate the "tunnel entrance" that does most all of the packet dropping.  But, assuming that the dropping is done properly, there would be 0 congestion loss through the provider network.

I also think that this kind of service could be offered by an SP, offered by the IT department in an enterprise, or offered to the customers of a multi-tenant data center.  I agree with you, that this is the only use case I've seen for running TCP over DetNet.

Maybe I should offer some text for the use cases draft?

-- Norm

________________________________
From: Grossman, Ethan A. [[email-masked]]
Sent: Wednesday, July 12, 2017 11:25 AM
To: Norman Finn; Balázs Varga A; John Grant; DetNet WG
Subject: RE: [Detnet] Traffic description in DetNet flow info model

1)      In the pro audio and video space it seems to me that constant bitrate is the norm; variable rate stream formats exist however they aren’t used that much in pro. One indication of that is that the (pre-packet-based A/V) industry is accustomed to point-to-point per-stream connections (in both analog and digital forms) for both audio and video.

2)      To me the spirit of DetNet (and AVB/TSN) has been the notion of guaranteeing a fixed amount of bandwidth per flow, and I don’t exactly see how VBR would fit into the core of DetNet. Norm’s suggestion that a user could lease a fixed amount of DetNet-enabled bandwidth then use that to transmit multiple TCP streams (which are essentially VBR, and in aggregate might be advantageous for multi-stream VBR traffic) makes about as much sense as I can see right now. If I’m missing something please let me know.
Ethan.

-- Norm

Good discussion.

Cheers
Bala’zs

John Grant

Hi John,

Cheers,
Yiyong

John Grant

Hi All,

Cheers,
Yiyong

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Thu, 13 Jul 2017 18:05:15 +0000

Hi Norm,
Thanks for the offer :- ) The original question from Yiyong was:

The DetNet flow info model should provide some common concepts and description of the flow. One part is traffic specification of the flow. Here is something not clear, is DetNet dealing with VBR flows and what attributes are needed? And how to deal with VBR flow, for source guarantee purpose, do we need to define shaping parameters?
...
In architecture draft, section 4.1.2, "The traffic characteristics of an App-flow can be CBR (constant bit rate) or VBR (variable bit rate)". In section 4.3.2, mentions synchronous flow and asynchronous flow, but no details of that.

So it sounds to me like this should be addressed in that section of the Arch draft (e.g. some statement that DetNet itself does not explicitly support VBR flow, however this could be implemented e.g. using a CBR tunnel + TCP) and thence in the traffic spec (again, DetNet doesn't do VBR). AFAIK there isn't any specific request for VBR support in the existing Use Cases, so no harm no foul? Does that sound right?

Ethan.

From: Norman Finn [mailto:[email-masked]]
Sent: Thursday, July 13, 2017 1:08 AM
To: Grossman, Ethan A. <[email-masked]>; Balázs Varga A <[email-masked]>; John Grant <[email-masked]>; DetNet WG <[email-masked]>
Subject: RE: [Detnet] Traffic description in DetNet flow info model

-- Norm

From: detnet [mailto:[email-masked]] On Behalf Of Norman Finn
Sent: Wednesday, July 12, 2017 12:34 AM
To: Balázs Varga A <[email-masked]<mailto:[email-masked]>>; John Grant <[email-masked]<mailto:[email-masked]>>; DetNet WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Detnet] Traffic description in DetNet flow info model

-- Norm

Good discussion.

Cheers
Bala'zs

John Grant

Hi John,

Cheers,
Yiyong

John Grant

Hi All,

Cheers,
Yiyong

---

From: Norman Finn <[email-masked]>
Date: Sat, 15 Jul 2017 08:47:57 +0000

You got it, Ethan.  No support for VBR.  I think that's clear in the architecture, but let's look at it.

-- Norm

Sent: Thursday, July 13, 2017 11:05 AM

Hi Norm,

…

So it sounds to me like this should be addressed in that section of the Arch draft (e.g. some statement that DetNet itself does not explicitly support VBR flow, however this could be implemented e.g. using a CBR tunnel + TCP) and thence in the traffic spec (again, DetNet doesn’t do VBR). AFAIK there isn’t any specific request for VBR support in the existing Use Cases, so no harm no foul? Does that sound right?

Ethan.

-- Norm

-- Norm

Good discussion.

Cheers
Bala’zs

John Grant

Hi John,

Cheers,
Yiyong

John Grant

Hi All,

Cheers,
Yiyong

---

From: Lou Berger <[email-masked]>
Date: Sat, 15 Jul 2017 09:04:33 -0400

We certainly will need to coexist with existing IETF technologies.

(as contributor) I've been assuming that when using TE infrastructure,
that DetNet would co-exist with, and build on, existing service
definitions for LSPs (or equivalent).  This includes, for example,
DiffServ, controlled load (RFC 2211), Guaranteed Service (RFC2212) and,
perhaps, MEF10.1 (RFC6003).

Lou

On 07/15/2017 04:47 AM, Norman Finn wrote:
> ------------------------------------------------------------------------
> *From:* Grossman, Ethan A. [[email-masked]]
> *Sent:* Thursday, July 13, 2017 11:05 AM
> *To:* Norman Finn; Balázs Varga A; John Grant; DetNet WG
> *Subject:* RE: [Detnet] Traffic description in DetNet flow info model
> 
> Hi Norm,
> 
> The DetNet flow info model should provide some common concepts and
> description of the flow. One part is traffic specification of the flow.
> Here is something not clear, is DetNet dealing with VBR flows and what
> attributes are needed? And how to deal with VBR flow, for source
> guarantee purpose, do we need to define shaping parameters?
> 
> …
> 
> In architecture draft, section 4.1.2, “The traffic characteristics of an
> App-flow can be CBR (constant bit rate) or VBR (variable bit rate)”. In
> section 4.3.2, mentions synchronous flow and asynchronous flow, but no
> details of that.
> 
>  
> 
> So it sounds to me like this should be addressed in that section of the
> Arch draft (e.g. some statement that DetNet itself does not explicitly
> support VBR flow, however this could be implemented e.g. using a CBR
> tunnel + TCP) and thence in the traffic spec (again, DetNet doesn’t do
> VBR). AFAIK there isn’t any specific request for VBR support in the
> existing Use Cases, so no harm no foul? Does that sound right?
> 
>  
> 
> Ethan.
> 
>  
> 
> *From:*Norman Finn [mailto:[email-masked]]
> *Sent:* Thursday, July 13, 2017 1:08 AM
> *To:* Grossman, Ethan A. <[email-masked]>; Balázs Varga A
> <[email-masked]>; John Grant <[email-masked]>; DetNet WG
> <[email-masked]>
> *Subject:* RE: [Detnet] Traffic description in DetNet flow info model
> 
>  
> 
> Thanks for the clarification, Ethan.  Yes, I was absolutely talking
> about a "CBR tunnel" service, though which a customer would be running
> any mix of traffic of any kind.  Either the customer or the provider
> could operate the "tunnel entrance" that does most all of the packet
> dropping.  But, assuming that the dropping is done properly, there would
> be 0 congestion loss through the provider network.
> 
> I also think that this kind of service could be offered by an SP,
> offered by the IT department in an enterprise, or offered to the
> customers of a multi-tenant data center.  I agree with you, that this is
> the only use case I've seen for running TCP over DetNet.
> 
> ------------------------------------------------------------------------
> 
> *From:*Grossman, Ethan A. [[email-masked]]
> *Sent:* Wednesday, July 12, 2017 11:25 AM
> *To:* Norman Finn; Balázs Varga A; John Grant; DetNet WG
> *Subject:* RE: [Detnet] Traffic description in DetNet flow info model
> 
> 1)      In the pro audio and video space it seems to me that constant
> bitrate is the norm; variable rate stream formats exist however they
> aren’t used that much in pro. One indication of that is that the
> (pre-packet-based A/V) industry is accustomed to point-to-point
> per-stream connections (in both analog and digital forms) for both audio
> and video.
> 
> 2)      To me the spirit of DetNet (and AVB/TSN) has been the notion of
> guaranteeing a fixed amount of bandwidth per flow, and I don’t exactly
> see how VBR would fit into the core of DetNet. Norm’s suggestion that a
> user could lease a fixed amount of DetNet-enabled bandwidth then use
> that to transmit multiple TCP streams (which are essentially VBR, and in
> aggregate might be advantageous for multi-stream VBR traffic) makes
> about as much sense as I can see right now. If I’m missing something
> please let me know.
> 
> Ethan.
> 
>  
> 
> *From:*detnet [mailto:[email-masked]] *On Behalf Of *Norman Finn
> *Sent:* Wednesday, July 12, 2017 12:34 AM
> *To:* Balázs Varga A <[email-masked]
> <mailto:[email-masked]>>; John Grant <[email-masked]
> <mailto:[email-masked]>>; DetNet WG <[email-masked]
> <mailto:[email-masked]>>
> *Subject:* Re: [Detnet] Traffic description in DetNet flow info model
> 
>  
> 
> But, given that DetNet can defend itself against misbehaving
> transmitters (by dropping packets), one could certainly supply an
> application with a CBR-like service over which one runs TCP.
> 
> In one sense, you might be better off using some technique like WFQ, so
> that you can get more bandwidth if it's available.  But, if the cost
> parameters are favorable, you can certainly imagine an SP using DetNet
> to offer CBR-over-best-effort services, over which TCP can certainly be
> run.  The downside compared to the usual techniques for this is that
> oversubscription of reservations is not allowed.  The upside is that the
> user gets every last bit of his contracted bandwidth, without random
> variations due to other customers' activity.
> 
> -- Norm
> 
> ------------------------------------------------------------------------
> 
> *From:*detnet [[email-masked]] on behalf of Balázs Varga A
> [[email-masked]]
> *Sent:* Tuesday, April 25, 2017 1:20 AM
> *To:* John Grant; DetNet WG
> *Subject:* Re: [Detnet] Traffic description in DetNet flow info model
> 
> Hi,
> 
>  
> 
> Good discussion.
> 
>  
> 
> *From:*detnet [mailto:[email-masked]] *On Behalf Of *John Grant
> *Sent:* 2017. április 21. 16:20
> *To:* DetNet WG <[email-masked] <mailto:[email-masked]>>
> *Subject:* Re: [Detnet] Traffic description in DetNet flow info model
> 
>  
> 
> The main facilities provided by TCP are rate control and retransmission
> of lost packets. When transferring a block of data (such as, say, an
> image or a pre-recorded video or a PDF) over a best-effort service,
> these allow the transfer to make best use of what the network provides.
> But if the network service guarantees a particular data rate you don't
> need the kind of rate control that TCP does, and if the network hardly
> ever loses a packet you don't need frequent acknowledgements.
> 
>  
> 
> For instance, if you are sending live audio with a sampling rate of 48k
> samples per second, and packing 12 samples in a packet, you need to send
> a packet every 250 microseconds, so you need CBR with a rate of 4000
> packets (of a certain size) per second.
> 
>  
> 
> The VBR service that was defined for ATM was intended for sending
> compressed video at constant quality, so that "busy" content needs more
> bits per frame than content with less detail. The peak rate is the bit
> rate for the "busiest" content, and the average bit rate was also
> signalled. I think the idea was that you could "overbook" a link by
> routing flows whose peak rates add up to more than the link capacity, in
> the expectation that they wouldn't all be demanding the peak rate at the
> same time. I think something similar is done with digital television
> multiplexes.
> 
>  
> 
> Note that with CBR (and VBR) the rate is determined by the application's
> requirements, whereas with TCP it is determined by what the best-effort
> service delivers.
> 
>  
> 
> John Grant
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ninetiles.com&d=DwMF-g&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=tS5EY8SXaTQuzywNz5HT0Jrgxk9GSRF2WhaHXBOAl4k&s=RmSC6BBktJC1J2slxfA-haYqlf34eB0oLtUd-Z-oSHY&e=>
> 
>  
> 
>     Thank you for the reply. I agree that make reservation on peak rate
>     is a simple solution. But the “peak rate” here depends on the
>     observation interval times max packets per interval, which means for
>     same flow, different interval leads to different peak rate. Below is
>     a little testbed we built to test the burstness feature of TCP flow.
> 
>     And further test shows that, 8 of these TCP flows to a 1Gbps port
>     cause packet loss. So my question is how can we make reservation
>     based on “peak rate”? E.g., for the same flow, if we take 1s
>     observation interval, we can serve 2 flows. But for 10ms observation
>     interval, only 1 flow, which does not make sense. And it is hard to
>     say long observation interval can guarantee delay and loss, since
>     buffer in router is only milliseconds level.
> 
>      
> 
>     Another thing is how to guarantee the source with max packets within
>     the interval. If shaping is necessary, what kind of parameters are
>     needed.
> 
>      
> 
>     Cheers,
> 
>     Yiyong
> 
>     *From:* detnet [mailto:[email-masked]] *On Behalf Of *John
>     Grant
>     *Sent:* Thursday, April 20, 2017 5:27 PM
>     *To:* DetNet WG
>     *Subject:* Re: [Detnet] Traffic description in DetNet flow info model
> 
>      
> 
>     As pointed out in 4.1.2, for a VBR flow you have to make a
>     reservation for the peak rate, and there isn't any reason to do
>     anything other than use the service that is already defined for CBR.
>     With circuit-switched systems any part of the reservation that
>     wasn't used was wasted, but in packet-based systems it can be used
>     for best-effort traffic, as stated in 4.3.2.
> 
>      
> 
>     Regarding synchronous flows, the first paragraph of 4.3.2 explains
>     that if the reservations on incoming and outgoing links are
>     time-aligned then the latency, and hence the amount of buffer space
>     required, can be minimised. The details mechanism for achieving that
>     would, I think, be out of scope for an architecture document.
> 
>      
> 
>     For a description of a system that implements synchronous flows, see
>     clause 5 of ETSI GR NGP 003, available from the "specifications" tab
>     at http://www.etsi.org/technologies-clusters/technologies/next-generation-protocols
>     <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.etsi.org_technologies-2Dclusters_technologies_next-2Dgeneration-2Dprotocols&d=DwMF-g&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=tS5EY8SXaTQuzywNz5HT0Jrgxk9GSRF2WhaHXBOAl4k&s=ML38iAvI654emuUqPEQU1n8X7v3dy0G3x6FIlK2yFhA&e=>
> 
>      
> 
>     John Grant
>     <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ninetiles.com_&d=DwMF-g&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=tS5EY8SXaTQuzywNz5HT0Jrgxk9GSRF2WhaHXBOAl4k&s=JAKBl0WO6WGg8P0NfwBx-dcUfmUZ9AvKKEwQKEIx_p4&e=>
> 
>     Recently we have some discussion among authors of the two flow info
>     model draft. The DetNet flow info model should provide some common
>     concepts and description of the flow. One part is traffic
>     specification of the flow. Here is something not clear, is DetNet
>     dealing with VBR flows and what attributes are needed? And how to
>     deal with VBR flow, for source guarantee purpose, do we need to
>     define shaping parameters?
> 
>      
> 
>     In architecture draft, section 4.1.2, “The traffic characteristics
>     of an App-flow can be CBR (constant bit rate) or VBR (variable bit
>     rate)”. In section 4.3.2, mentions synchronous flow and asynchronous
>     flow, but no details of that.
> 
>     In use case draft, for some cases such as industrial and BAS, it can
>     assumes that the traffic is periodic with constant rate. For cases
>     such as Cellular Radio and M2M, there is usually no assumption on
>     the traffic. E.g., CoMP traffic is between two eNBs, it is hard to
>     say the flow is constant rate.
> 
>      
> 
>     Cheers,
> 
>     Yiyong
> 
>  
> 
>  
> 
> 
> 
> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet
>

---

From: Balázs Varga A <[email-masked]>
Date: Tue, 18 Jul 2017 09:10:10 +0000

Hi,

The recent version of the flow information model contains the mandatory 
"TrafficSpecification" attributes which are practically defining a "CBR tunnel". 
It also contains some thoughts on VBR specific attributes as a note:

"... Further optional attributes can be considered to achieve
more efficient resource allocation. Such optional attributes might
be worth for flows with soft requirements (i.e., the flow is only
loss sensitive or only delay sensitive, but not both delay-and-loss
sensitive)."

Three possible approaches are listed as examples (they are there for further discussions):
1, Average attributes: "AveragePacketsPerInterval"  and "AveragePayloadSize"
2, RFC6003 like extension: Bandwidth Profile concept, Committed / Excess Rate
3, Applications based model: like defined in 3GPP, periodic, approximately-periodic 
and event/triggered traffic type

Cheers
Bala'zs

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: 2017. július 15. 15:05
To: Norman Finn <[email-masked]>; Grossman, Ethan A. <[email-masked]>; Balázs Varga A <[email-masked]>; John Grant <[email-masked]>; DetNet WG <[email-masked]>
Subject: Re: [Detnet] Traffic description in DetNet flow info model

(as contributor) I've been assuming that when using TE infrastructure, that DetNet would co-exist with, and build on, existing service definitions for LSPs (or equivalent).  This includes, for example, DiffServ, controlled load (RFC 2211), Guaranteed Service (RFC2212) and, perhaps, MEF10.1 (RFC6003).

Lou

On 07/15/2017 04:47 AM, Norman Finn wrote:
> .
> In architecture draft, section 4.1.2, "The traffic characteristics of 
> an App-flow can be CBR (constant bit rate) or VBR (variable bit 
> rate)". In section 4.3.2, mentions synchronous flow and asynchronous 
> So it sounds to me like this should be addressed in that section of 
> the Arch draft (e.g. some statement that DetNet itself does not 
> explicitly support VBR flow, however this could be implemented e.g. 
> using a CBR tunnel + TCP) and thence in the traffic spec (again, 
> DetNet doesn't do VBR). AFAIK there isn't any specific request for VBR 
> support in the existing Use Cases, so no harm no foul? Does that sound right?
> 
>  
> 
> Ethan.
> 
>  
> 
> dropping.  But, assuming that the dropping is done properly, there 
> would be 0 congestion loss through the provider network.
> 
> customers of a multi-tenant data center.  I agree with you, that this 
> is the only use case I've seen for running TCP over DetNet.
> 
> aren't used that much in pro. One indication of that is that the 
> per-stream connections (in both analog and digital forms) for both 
> audio and video.
> 
> guaranteeing a fixed amount of bandwidth per flow, and I don't exactly 
> see how VBR would fit into the core of DetNet. Norm's suggestion that 
> a user could lease a fixed amount of DetNet-enabled bandwidth then use 
> that to transmit multiple TCP streams (which are essentially VBR, and 
> in aggregate might be advantageous for multi-stream VBR traffic) makes 
> about as much sense as I can see right now. If I'm missing something 
> please let me know.
> 
> Ethan.
> 
>  
> 
> In one sense, you might be better off using some technique like WFQ, 
> so that you can get more bandwidth if it's available.  But, if the 
> cost parameters are favorable, you can certainly imagine an SP using 
> DetNet to offer CBR-over-best-effort services, over which TCP can 
> certainly be run.  The downside compared to the usual techniques for 
> this is that oversubscription of reservations is not allowed.  The 
> upside is that the user gets every last bit of his contracted 
> bandwidth, without random variations due to other customers' activity.
> 
> -- Norm
> 
> The main facilities provided by TCP are rate control and 
> retransmission of lost packets. When transferring a block of data 
> (such as, say, an image or a pre-recorded video or a PDF) over a 
> best-effort service, these allow the transfer to make best use of what the network provides.
> For instance, if you are sending live audio with a sampling rate of 
> 48k samples per second, and packing 12 samples in a packet, you need 
> to send a packet every 250 microseconds, so you need CBR with a rate 
> of 4000 packets (of a certain size) per second.
> 
>  
> 
> compressed video at constant quality, so that "busy" content needs 
> more bits per frame than content with less detail. The peak rate is 
> the bit rate for the "busiest" content, and the average bit rate was 
> also signalled. I think the idea was that you could "overbook" a link 
> by routing flows whose peak rates add up to more than the link 
> capacity, in the expectation that they wouldn't all be demanding the 
> peak rate at the same time. I think something similar is done with 
> digital television multiplexes.
> 
>  
> 
> Note that with CBR (and VBR) the rate is determined by the 
> application's requirements, whereas with TCP it is determined by what 
> the best-effort service delivers.
> 
>  
> 
> John Grant
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ninetiles.com
> &d=DwMF-g&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=tS5EY8SX
> aTQuzywNz5HT0Jrgxk9GSRF2WhaHXBOAl4k&s=RmSC6BBktJC1J2slxfA-haYqlf34eB0o
> LtUd-Z-oSHY&e=>
> 
>  
> 
>     is a simple solution. But the "peak rate" here depends on the
>     based on "peak rate"? E.g., for the same flow, if we take 1s
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.etsi.org_tech
> nologies-2Dclusters_technologies_next-2Dgeneration-2Dprotocols&d=DwMF-
> g&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=tS5EY8SXaTQuzywN
> z5HT0Jrgxk9GSRF2WhaHXBOAl4k&s=ML38iAvI654emuUqPEQU1n8X7v3dy0G3x6FIlK2y
> FhA&e=>
> 
>      
> 
>     John Grant
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ninetiles.com
> _&d=DwMF-g&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=tS5EY8S
> XaTQuzywNz5HT0Jrgxk9GSRF2WhaHXBOAl4k&s=JAKBl0WO6WGg8P0NfwBx-dcUfmUZ9Av
> KKEwQKEIx_p4&e=>
> 
>     In architecture draft, section 4.1.2, "The traffic characteristics
>     rate)". In section 4.3.2, mentions synchronous flow and asynchronous