Re: A not-end-to-end question

--Apple-Mail=_FC4640D7-02A9-4A29-A31E-DAC6C613A4BC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Mar 27, 2014, at 3:32 PM, Bob Braden <[email protected]> wrote:

> Friends,
>=20
> 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 ;-)
>=20
> 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.
>=20
> 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.
>=20
> 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.=20

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=92s 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=92d have to pay for =
the actual spec), C37.118-2-2011 doesn=92t 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=92t =
going to result in spitzensparken.

The NASPI folks are welcome to correct me.=20

> 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=85

> 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.
>=20
> 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=92t know who=92s =
going to request what in an other-than-statistical fashion, and we =
presume that it=92s 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=92t 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.=20

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=3D33896
     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=3D53786 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=3D144044 =
bytes)
     (Updated by RFC5865) (Status: INFORMATIONAL)


--Apple-Mail=_FC4640D7-02A9-4A29-A31E-DAC6C613A4BC--