[e2e] A not-end-to-end question

[Fred Baker (fred)]

On Mar 27, 2014, at 3:32 PM, Bob Braden <braden at ISI.EDU> wrote:

> Friends,
> 
> I am pondering a question that is sort of anti-end-to-end. But since I set up this list in the first instance, I figure I have the right to abuse it ;-)
> 
> There is a community of electrical power engineers who are reworking the power transmission system, starting by instrumenting it with measurement devices called Phasor Measureent Units or PMUs.  A PMU samples the electrical state at a particular point ("bus") at O(100) times a second , encapsulates the sample in a frame of ~100 bytes, and sends it (in general) towards one or more control cemters Each frame carries an absolute timestamp, currently using GPS clocks at each PMU.  The frames are passed downstream to a data sink, an application program running usually in a control center computer.
> 
> This PMU data transmission problem requires high availability and controlled latency. Just throwing away packets as we commonly do in the Internet does not work here.
> 
> There are several proposals, eg MPLS, to solve this problem. However, I have been pondering the question: isn't this a nearly perfect application for Integrated Services and RSVP? Didn't we solve this problem more than 15 ears ago?

Yes, sort of. It could also be deployed using diffserv; you use a code point for a PHB comparable to EF.

You might also find http://www.ieee802.org/802_tutorials/2012-11/8021-tutorial-final-v4.pdf interesting.

> Is there any difference in principle between streaming audio/video data and streaming PMU data?

Yes and no. It has to do with tolerances. 

Between generators driving the same power line, a protocol called GOOSE is used to ensure synchronicity. If two generators become more than 1/4 Hz out of phase, a relay is thrown to remove on until the issue has been corrected. This generally, as I understand it, runs directly on Ethernet, and anyone messing with the tolerances has utility engineers shivering. By comparison to Voice and Video on IP, which have realistic tolerances on the order of the size of a jitter buffer (50-100 ms), GOOSE’s 4 ms tolerance would likely not survive anything that can experience frequent variations in delay of as much as 10 ms (http://www.ieee-infocom.org/2004/papers/37_4.pdf).

Reading through the information available online (I’d have to pay for the actual spec), C37.118-2-2011 doesn’t appear target that fine a tolerance in its communications, or the concept of turning something off in real time. The JAIST article on the technology makes rather a point of mentioning TCP and SQL servers, which says to me that it benevolently contemplates both an occasional dropped-and-retransmitted packet and SQL-style database manipulation. That leads me to believe that they would like communication to be as predictable as is reasonable, but while the *measurements* are on exact 10 ms intervals, the *analysis* of the data is in retrospect, and a packet that is delayed a TCP RTO isn’t going to result in spitzensparken.

The NASPI folks are welcome to correct me. 

> The major argument against Intserv and RSVP has always been with scaling up to Internet sizes. However, the network delivering PMU data will not suffer from a scaling problem. The population of PMUs is expected to grow, but unlikely to exceed O(10,000), so we can put quite reasonable bounds on state in each router. Furthermore, at lest one well known router vendor implements RSVP and Integrated Service, I believe, although I do not know the details.

I know of one…

> One remaining obstacle might be the lack of down-sampling (if you don't know what this means, never mind). but I suspect this will be more a theoretical than a practical problem in the real world. I guess another issue is whether a token bucket is adequate and appropriate
> for modeling PMU data streams, but I suspect that it is OK.
> 
> I hope that other refugees from the IntServ development will comment on this.  What have I overlooked?

To my mind, diffserv EF would work equally well. The difference between the two is that in a network that uses RSVP, we don’t know who’s going to request what in an other-than-statistical fashion, and we presume that it’s OK for the N+1st session to be told to try again later. A network that has PMUs on it is likely to run that traffic 24X7, and to get pretty excited if someone tells them that a given PMU concentrator isn’t allowed to communicate. If the network is engineered (or contracted) for the bandwidth the service requires, you may as well simply mark the traffic EF (or EF-ADMIT) and put it into a priority queue. 

https://tools.ietf.org/html/rfc3246
3246 An Expedited Forwarding PHB (Per-Hop Behavior). B. Davie, A.
     Charny, J.C.R. Bennet, K. Benson, J.Y. Le Boudec, W. Courtney, S.
     Davari, V. Firoiu, D. Stiliadis. March 2002. (Format: TXT=33896
     bytes) (Obsoletes RFC2598) (Status: PROPOSED STANDARD)

https://tools.ietf.org/html/rfc3247
3247 Supplemental Information for the New Definition of the EF PHB
     (Expedited Forwarding Per-Hop Behavior). A. Charny, J. Bennet, K.
     Benson, J. Boudec, A. Chiu, W. Courtney, S. Davari, V. Firoiu, C.
     Kalmanek, K. Ramakrishnan. March 2002. (Format: TXT=53786 bytes)
     (Status: INFORMATIONAL)

https://tools.ietf.org/html/rfc4594
4594 Configuration Guidelines for DiffServ Service Classes. J.
     Babiarz, K. Chan, F. Baker. August 2006. (Format: TXT=144044 bytes)
     (Updated by RFC5865) (Status: INFORMATIONAL)