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

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Bala'zs,

I'd argue that UDP is pushing the problem to the application, but not solving it. I'd argue that we need a new rate-based (as opposed to window-based) transport. Like IBM's Rapid Transport Protocol / Adaptive Rate Base for those who played with it at some point.

In the early days of industrial control networks (and we are still there for the majority of real world deployments), the application was ultra light because the analog current modulation would transport the information at speed of light with neither latency nor jitter.
Digitazing and then Serializing the information over a serial P2P cable brought latency that applications had to cope with. Multi-drop serial links (buses) saved cabling but brought an additional latency, time to get to the TDM piece awarded to the particular device. These, application could often cope with quite easily.
Then came statistical multiplexing with such networks as frame relay, and with it came jitter; that's when applications had to start accommodating with jitter absorption buffers -and some did, when there was no choice (e.g. A/V streaming). But the majority of operational technology would not be bothered and that's one of the reasons why migration to off the shelf IP has been stalled in Operational Technology. And if you look at it, the rate adaptation (CIR, ECN) was still a network function, not an application function.

Now we are claiming that DetNet should enable OT. And indeed DetNet will provide a pipe that has a rate and a latency (and a virtual clock) that could indeed emulate the original serial wire. But for the lack of a rate based transport, we are pushing the rate adaptation back to the application. Will work for some, but I'm concerned that without a good ECN and a rate based flow control, we are leaving a portion of the potential applications aside.

Take care,

Pascal


From: detnet [mailto:[e-mail]] On Behalf Of Balázs Varga A
Sent: mardi 25 avril 2017 10:21
To: John Grant <[e-mail]>; DetNet WG <[e-mail]>
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:[e-mail]] On Behalf Of John Grant
Sent: 2017. április 21. 16:20
To: DetNet WG <[e-mail]<mailto:[e-mail]>>
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
[phone] and [phone]
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:

<image007.jpg>
1s observation interval, peak rate 450Mbps.

<image008.jpg>
100ms observation interval, peak rate 900Mbps.

<image009.jpg>
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:[e-mail]] 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
[phone] and [phone]
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