From detlef.bosau at web.de Sun Mar 2 05:52:28 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Sun, 02 Mar 2014 14:52:28 +0100 Subject: [e2e] Just as an idea. Why can't we use hop by hop flow control for TCP? In-Reply-To: <5307DD86.6020503@web.de> References: <52D04B36.9010005@web.de> <52FE4ED0.3050601@web.de> <52FE726D.7080703@web.de> <5302C22E.9070905@web.de> <53036B5A.8050703@web.de> <1392735042.09327130@apps.rackspace.com> <53038237.4050702@web.de> <1392746427.24473918@apps.rackspace.com> <5303B700.4020609@web.de> <1392762531.99455268@apps.rackspace.com> <53046D0E.1040401@web.de> <530471BB.3020601@web.de> <5304C5DB.3030700@web.de> <530743CA.4020309@web.de> <5307C39A.30503@web.de> <5307DD86.6020503@web.de> Message-ID: <5313379C.3040306@web.de> I'm curious why I did not yet see a hop by hop flow control flavour for TCP. Do I miss something? For ATM Networks, such approaches have been conducted. I think of a classical window based flow control for TCP. This would be an alternative to the end to end "congestion control". I'm curious, whether such a approach has ever been conducted to a certain degree. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Sun Mar 2 12:53:09 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Sun, 02 Mar 2014 21:53:09 +0100 Subject: [e2e] Just as an idea. Why can't we use hop by hop flow control for TCP? In-Reply-To: <5313379C.3040306@web.de> References: <52D04B36.9010005@web.de> <52FE4ED0.3050601@web.de> <52FE726D.7080703@web.de> <5302C22E.9070905@web.de> <53036B5A.8050703@web.de> <1392735042.09327130@apps.rackspace.com> <53038237.4050702@web.de> <1392746427.24473918@apps.rackspace.com> <5303B700.4020609@web.de> <1392762531.99455268@apps.rackspace.com> <53046D0E.1040401@web.de> <530471BB.3020601@web.de> <5304C5DB.3030700@web.de> <530743CA.4020309@web.de> <5307C39A.30503@web.de> <5307DD86.6020503@web.de> <5313379C.3040306@web.de> Message-ID: <53139A35.8010103@web.de> To me, a hop by hop flow control approach seems to me as the intuitive way to go in a packet switched network. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Thu Mar 6 08:58:08 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 06 Mar 2014 17:58:08 +0100 Subject: [e2e] Just as an idea. Why can't we use hop by hop flow control for TCP? In-Reply-To: <53187074.4030309@kit.edu> References: <52D04B36.9010005@web.de> <52FE4ED0.3050601@web.de> <52FE726D.7080703@web.de> <5302C22E.9070905@web.de> <53036B5A.8050703@web.de> <1392735042.09327130@apps.rackspace.com> <53038237.4050702@web.de> <1392746427.24473918@apps.rackspace.com> <5303B700.4020609@web.de> <1392762531.99455268@apps.rackspace.com> <53046D0E.1040401@web.de> <530471BB.3020601@web.de> <5304C5DB.3030700@web.de> <530743CA.4020309@web.de> <5307C39A.30503@web.de> <5307DD86.6020503@web.de> <5313379C.3040306@web.de> <53187074.4030309@kit.edu> Message-ID: <5318A920.5000706@web.de> Am 06.03.2014 13:56, schrieb Roland Bless: > Hi, > > On 02.03.2014 14:52, Detlef Bosau wrote: >> I'm curious why I did not yet see a hop by hop flow control flavour for >> TCP. Do I miss something? For ATM Networks, such approaches have been >> conducted. I think of a classical window based flow control for TCP. > Because TCP is only running at the edges and you better avoid > per flow state in the network. I would like to add a question mark here. TCP is no way "only running at the end points" - of course, links and switching nodes along the path are involved and affected. Vice versa, these nodes affect a TCP flow. (I talked too much about wireless networks, btw., what wireless networks are concerned, there is a general wisdom: You cannot make a silk purse from a sows ear. And we cannot solve technological problems by protocols, neither do protocols overcome technological limitations. Nevertheless, we must ensure, that things are not worsened by protocols. But we should be extremely careful, not to run into category errors here.) >> This would be an alternative to the end to end "congestion control". > Flow control and congestion control have different objectives: > flow control tries to prevent overloading the receiver, whereas > congestion control tries to prevent overloading the network. > So you better consider them separately. The more I think about it, this appears artificial to me. I wrote this sometimes before: When you think so, your model is: Sender -------------------------Line---------------------- Receiver. In that scenario, end to end flow control makes sense. However, my concern is that this model is, though appealing, oversimplified. Just one example: In the sketch above, I don't see any cross traffic. The only active elements in the sketch are "Sender" and "Receiver". And they have to care for anything. No matter what this will be. Traffic bursts, varying throughtput on a link, link outages, varying offered network load, whatever. >From a historical perspective, this model intuitive and justified. In the days of the ARPAnet and the early Internet, the "Line" was one "black box". Where, of course, quite some - recovery, - flow control, - resource management was done under the hood - and still is. However, we prefer the bird's eye view, and so TCP flows appear a bit like tin can telephone. I further think that this is a misinterpretation of Salzer's paper. Following Salzer, we should solve local problems locally and global problems globally. Actually, we solve problems at the end points. (If at all.) No matter whether they are local problems or global problems. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Fri Mar 7 17:48:47 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Sat, 08 Mar 2014 02:48:47 +0100 Subject: [e2e] To make my thought more clear. In-Reply-To: <5318A920.5000706@web.de> References: <52D04B36.9010005@web.de> <52FE726D.7080703@web.de> <5302C22E.9070905@web.de> <53036B5A.8050703@web.de> <1392735042.09327130@apps.rackspace.com> <53038237.4050702@web.de> <1392746427.24473918@apps.rackspace.com> <5303B700.4020609@web.de> <1392762531.99455268@apps.rackspace.com> <53046D0E.1040401@web.de> <530471BB.3020601@web.de> <5304C5DB.3030700@web.de> <530743CA.4020309@web.de> <5307C39A.30503@web.de> <5307DD86.6020503@web.de> <5313379C.3040306@web.de> <53187074.4030309@kit.edu> <5318A920.5000706@web.de> Message-ID: <531A76FF.40906@web.de> In the traditional way of VJCC, we often think packets were distributed along the path quite equally. Now, imagine sender --------------- Internet cloud --- GPRS link --------- Receiver and a 1 MByte CWMD. What happens when the GPRS link suffers from a "bandwidth shortage"? The whole 1 MByte CWND piles up at the router before the GPRS link. So, while the "Latency Bandwidth Product" may well be 1 MByte, when this amount of data is in transit and equally distributed along the path, exactly this amount of data may cause severe congestion when gathering at one interface. This could not even be alleviated by adding buffer: Our probing schemes will have this buffer fully utilized, which offers two advantages: 1. The end to end latency increases. 2. CWND increases as well - and the next congestion problem is to be expected ;-) In Reiner Ludwig's PhD thesis, he talked about "hiccups" (spelling by Reiner Ludwig). These and perhaps extreme throughput steps from, say, 10 GBit/s down to 100 kBit/s may cause data to gather at individual interfaces along the path which renders our "Little's Law model" (this is exactly the idea behind our abstraction) somewhat questionable. (If you prefer a wireline example: A "transient bandwidth shortage" may be caused e.g. by cross traffices along the path. Detlef -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From jwu_res at yahoo.com Mon Mar 10 00:43:13 2014 From: jwu_res at yahoo.com (Jinsong Wu) Date: Mon, 10 Mar 2014 00:43:13 -0700 (PDT) Subject: [e2e] =?utf-8?q?Deadline_April_1_CFP_=E2=80=93_2014_IEEE_Globecom?= =?utf-8?q?_Green_Track?= Message-ID: <1394437393.92306.YahooMailNeo@web164005.mail.gq1.yahoo.com> Call for papers ? Track on Green Communication Systems and Networks - Selected Areas in Communications Symposium at IEEE Globecom 2014 Firm submission deadline: April 1, 2014.? (Unlike recent ICC's and Globecom's, this is a hard deadline that will not be extended.) EDAS submission web link:?https://www.edas.info/newPaper.php?c=16641 Scope and Motivation: Track on Green Communication Systems and Networks in the Selected Areas in Communications Symposium will focus on green topics and issues relevant to green communications systems and networks. This track not only addresses energy relevant green topics but also discusses other non-energy relevant green topics. Green information communication technologies have been globally recognized as an important research? field,? discussing energy- and/or resource-efficient and/or environment-sustainable communications, computing, and relevant systems. Research projects to date have identified solutions in terms of algorithms and subsystems, as well as new ideas for system architectures. Research will further develop these solutions as well as showing how different concepts can be integrated to design different efficient systems from the ground up. This track solicits contributions describing cutting-edge research in communication systems and networks that incorporate "green" considerations in their design and operation. This covers a wide range of green topics, including not only greening communications and relevant systems, but also exploiting communications and relevant systems to achieve green objectives for the sustainable world. This track covers broader topics enabling various green topics, such as green technologies, smart homes and offices, intelligent transport and smart grid energy systems, green services, green business and economic concerns? Main Topics of Interest: To ensure complete coverage of the advances in this field, the Green Communication Systems and Networks Track of the Selected Areas in Communications Symposium solicits original contributions in, but not limited to, the following topical areas: * Theory, modeling, analysis, and/or optimization for green and sustainable green communication systems and networks * Architecture, strategies, algorithms, protocols, scheduling, and/or designs for green communications, networks, computing, and systems * Non-energy green topics * Green software, hardware, devices, and equipment * Green wireless and/or wireline communications * Green scheduling and allocations for communications * Green optical devices, signal processing, switching, and communications * Electromagnetic pollution mitigation * Green terminals? * Green data storage, data centers and cloud computing, contention distribution networks * Green communications under delay or quality of service constraints * Physical layer approaches for green communications and computing * Green Internet of Things * Energy harvesting, storage, and recycling * Applications, economics, social issues, and interdisciplinary topics * Novel network concepts and architectures lowering the overall network footprint? * Self-organizing wireless networks for energy efficiency? * Traffic shaping and policy implementation for energy saving? * Use of cognitive principles to achieve green objectives? in wireline or wireless networks * Signal processing for green communications and computing? * Low cost, energy-efficient antenna and radio frequency system designs? * Economy and pricing for green communication and services? * Environmental? monitoring? * Measurement and profiling of energy consumption? * Power consumption trends and reduction in communications? * Standardizations, policies and regulations for green communications and computing? * Mitigation of electromagnetic pollution? * Experimental test-beds and results for green communications and computing? * Optimum use of renewable energy in communication systems and networks? * Green technologies for intelligent transport systems? * Green technologies for industrial processes? * ICT technologies for green buildings and offices? * Green Approaches for Smart Grids? * Field trials and deployment experiences From touch at isi.edu Mon Mar 10 09:34:23 2014 From: touch at isi.edu (Joe Touch) Date: Mon, 10 Mar 2014 09:34:23 -0700 Subject: [e2e] a note about posts In-Reply-To: <531DE15B.80308@isi.edu> References: <1394437393.92306.YahooMailNeo@web164005.mail.gq1.yahoo.com> <531DE15B.80308@isi.edu> Message-ID: <531DE98F.4060806@isi.edu> As a reminder: All meeting announcements need to be approved in advance. (FYI, this one was not). When the primary call for paper or participation is permitted: - meeting reminders are NOT permitted - sub-meetings of a parent meeting must not post individually Joe (as list admin) From detlef.bosau at web.de Tue Mar 11 13:04:56 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 11 Mar 2014 21:04:56 +0100 Subject: [e2e] Just as an idea. Why can't we use hop by hop flow control for TCP? In-Reply-To: <531D7CE3.3030500@kit.edu> References: <52D04B36.9010005@web.de> <52FE726D.7080703@web.de> <5302C22E.9070905@web.de> <53036B5A.8050703@web.de> <1392735042.09327130@apps.rackspace.com> <53038237.4050702@web.de> <1392746427.24473918@apps.rackspace.com> <5303B700.4020609@web.de> <1392762531.99455268@apps.rackspace.com> <53046D0E.1040401@web.de> <530471BB.3020601@web.de> <5304C5DB.3030700@web.de> <530743CA.4020309@web.de> <5307C39A.30503@web.de> <5307DD86.6020503@web.de> <5313379C.3040306@web.de> <53187074.4030309@kit.edu> <5318A920.5000706@web.de> <531D7CE3.3030500@kit.edu> Message-ID: <531F6C68.5000309@web.de> Am 10.03.2014 09:50, schrieb Roland Bless: > Hi, > > On 06.03.2014 17:58, Detlef Bosau wrote: >> I would like to add a question mark here. >> >> TCP is no way "only running at the end points" - of course, links and >> switching nodes along the path are involved and affected. > They are usually not holding TCP state. And neither they do in my concept. They would hold flow control state - in a manner which would reasonably scale up to a huge number of flows. >> >> The more I think about it, this appears artificial to me. > No, look DCCP, for example, provides CC but now flow control, because > it is unreliable and you don't care whether the receiver must drop > packets - for real-time applications this is advantageous because > they can try to catch up. To my understanding, DCCP takes TCP congestion control and reimplements this for TCP flows. So, it basically suffers from the same weaknesses. > >> I wrote this sometimes before: When you think so, your model is: >> Sender -------------------------Line---------------------- Receiver. > No, it's not the model I have in mind...but it nevertheless depends > on the level of abstraction and layer(s) that you are looking into. It is the model used in the congavoid paper. > You can easily have models that take all such things into account, Hm. The very challenge is to take the right things into account and leave the others. >> I further think that this is a misinterpretation of Salzer's paper. >> >> Following Salzer, we should solve local problems locally and global >> problems globally. Actually, we solve problems at the end points. (If at >> all.) > Are you referring to the end-to-end argument paper? Of course. > IMHO one of the essential conclusions is that you often need > application knowledge in order to behave adequately in case > of failures I agree - however, the applications may well decide themselves - given the appropriate information. > and that you better avoid to put this knowledge > (or state) into the network infrastructure. In the e2e argument > paper there are no local/global scope aspects mentioned. So they are forbidden? Roland, when was the e2e argument paper written? Correct. 1984. When I went to supermarket this afternoon, the "Internet" constituted by the iPods there was greater than the whole Internet at the time of Saltzer's paper. Again you will tell me that sounds to harsh. Does it cause harm to anybody when I consider an alternate way? Detlef > > Roland > -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From Pan at UVic.CA Sun Mar 16 22:52:16 2014 From: Pan at UVic.CA (J. Pan) Date: Sun, 16 Mar 2014 22:52:16 -0700 (PDT) Subject: [e2e] [ACM IMC 2014] Call for Papers (Due: April 30, 2014) Message-ID: [please accept our apologies if you receive this message multiple times] Internet Measurement Conference November 5-7, 2014 Vancouver, BC http://conferences.sigcomm.org/imc/2014/ ***Important dates*** Paper registration (with abstract): Apr 30, 2014 (Noon US Pacific Time) Paper submission: May 7, 2014 (Noon US Pacific Time) Notification: Jul 25, 2014 Camera-ready due: Sep 5, 2014 ***Call for papers*** The Internet Measurement Conference is a highly selective venue for the presentation of measurement-based research in data communications. The focus of IMC 2014 will be on papers that either (1) improve the practice of measurement or (2) illuminate some facet of an operational network. IMC takes a broad view of what constitutes an operational network. This view includes (but is not limited to): ? the Internet backbone and edge networks (e.g., home networks, cellular networks, WLANs) ? data centers and cloud computing infrastructure ? peer-to-peer and content distribution networks ? infrastructure for online social networks ? experimental networks affiliated with the Internet (e.g. overlay networks, future internets or other prototype networks) Types of contributions that the program committee would enjoy receiving submissions regarding include (but are not limited to): ? collection and analysis of data that yield new insights about network structure and behavior (e.g., traffic, topology, routing, privacy, security, energy use, economics, application interaction with network protocols) ? methods and tools to monitor and visualize network-based phenomena ? systems and algorithmic techniques that leverage measurement-based findings in novel ways ? advances in data collection and handling (e.g., anonymization, querying, storage, facilitating sharing) ? modeling of network structure and behavior (e.g., workload, scalability), assessment of performance bottlenecks ? reappraisal of previous empirical findings Authors unsure whether their paper fits IMC are welcome to contact the program committee co-chairs at imc14chairs at cs.wisc.edu. ***Review process and criteria*** ? IMC 2014 invites two forms of submissions o Full papers (up to 14 pages) that describe original research, with succinctness appropriate to the topics and themes they discuss. o Short papers (up to 6 pages for text and figures + up to 1 page for references) that convey work that is less mature but shows promise, articulate a high-level vision, describe challenging future directions, critique current measurement wisdom, or offer results that do not merit a full submission. All submissions that are longer than what is allowed for a short paper will be evaluated as full papers. Authors should only submit original work that has not been published before and is not under submission to any other venue. We will consider full paper submissions that extend previously published short, preliminary papers (including IMC short papers) following the model of the ACM SIGCOMM policy (http://www.sigcomm.org/about/policies/frequently-asked-questions-faq). ? Ethical standards for measurement must be considered by all authors. In particular, authors must conform to acceptable use policies for domains that are probed or monitored, data privacy and anonymity for all personally identifiable information (PII) and etiquette for using shared measurement data. (See Allman and Paxson, IMC '07.) If applicable, authors are also urged to notify parties of security flaws in their products or services in advance of publication. Adherence to ethical standards for measurement will be a criterion for all submissions, and any violations---including ambiguous situations not well described---will be grounds for rejection. ? IMC 2014 will bestow two awards. One award will recognize the outstanding paper at the conference, and all accepted papers are eligible for it. The other award will recognize a paper that contributes a novel dataset to the community. To be eligible for this award, the authors must make their dataset publicly available (e.g., through CRAWDAD for wireless data) by the time of camera ready submission. A few accepted papers may be forwarded for fast-track submission to IEEE/ACM Transactions on Networking. ***Submission guidelines*** All submissions must satisfy the following requirements: ? up to 14 pages for full papers, or up to 6 pages (+1 for references) for short papers ? 10-point font for main text; font used in other places (e.g., figures) should be no smaller than 9 point ? two-column format, with the size of each column being at most 9.25 x 3.33 inches and the space between columns being at least 0.33 inches ? letter page size (11 x 8.5 inches) ? include names and affiliations of all authors on the title page (no anonymization) Submissions that do not comply with these requirements will be rejected without review. The sig-alternate-10pt.cls style file satisfies the formatting requirements. Compile your source with options that produce letter page size. ***Submission site*** Please visit https://imc2014.cs.wisc.edu/hotcrp/ for submissions. ***Organizing committee*** General chair Carey Williamson, University of Calgary Program chairs Aditya Akella, UW-Madison Nina Taft, Technicolor ***Program committee*** Mark Allman (ICSI) Michael Bailey (University of Michigan) Hitesh Ballani (MSR-Cambridge) Paul Barford (UW-Madison) Theophilus Benson (Duke University) David Choffnes (Northeastern University) Xenofontas Dimitropoulos (FORTH and ETH Zurich) Vijay Erramilli (Telefonica) Rodrigo Fonseca (Brown University) Phillipa Gill (Stony Brook University) Sharon Goldberg (Boston University) Saikat Guha (MSR-India) Andreas Haeberlen (University of Pennsylvania) Arnaud Legout (INRIA) Harsha Madhyastha (UC Riverside) Olaf Maennel (Loughborough University) Marco Mellia (Politecnico di Torino) Jelena Mirkovic (USC/ISI) Alan Mislove (Northeastern University) Osnat Mokryn (Haifa University) Thyaga Nandagopal (NSF) Vivek Pai (Princeton University) Michalis Polychronakis (Columbia University) Costin Raiciu (U. Politehnica Bucuresti) Anmol Sheth (Technicolor) Ramesh Sitaraman (U. Mass, Amherst) Georgios Smaragdakis (MIT/TU Berlin) Alex C. Snoeren (UC San Diego) Oliver Spatscheck (ATT) Darryl Veitch (University of Melbourne) Shobha Venkataraman (ATT) Zhi-Li Zhang (University of Minnesota) ***Steering committee*** Mark Allman, ICSI Chen-Nee Chuah, UC Davis Jim Kurose, University of Massachusetts, Amherst Ratul Mahajan, Microsoft Renata Teixiera, INRIA ***Important dates*** Paper registration (with abstract): Apr 30, 2014 (Noon US Pacific Time) Paper submission: May 7, 2014 (Noon US Pacific Time) Notification: Jul 25, 2014 Camera-ready due: Sep 5, 2014 Conference: Nov 5-7 2014, Vancouver, BC http://conferences.sigcomm.org/imc/2014/ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From braden at isi.edu Thu Mar 27 15:32:36 2014 From: braden at isi.edu (Bob Braden) Date: Thu, 27 Mar 2014 15:32:36 -0700 Subject: [e2e] A not-end-to-end question Message-ID: <5334A704.5020503@isi.edu> 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? Is there any difference in principle between streaming audio/video data and streaming PMU data? 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. 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? Bob Braden From fred at cisco.com Thu Mar 27 17:00:16 2014 From: fred at cisco.com (Fred Baker (fred)) Date: Fri, 28 Mar 2014 00:00:16 +0000 Subject: [e2e] A not-end-to-end question In-Reply-To: <5334A704.5020503@isi.edu> References: <5334A704.5020503@isi.edu> Message-ID: <70C1BD5D-07FA-4D7C-AA43-C0A49899593C@cisco.com> On Mar 27, 2014, at 3:32 PM, Bob Braden 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) From detlef.bosau at web.de Sat Mar 29 01:55:45 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Sat, 29 Mar 2014 09:55:45 +0100 Subject: [e2e] A not-end-to-end question In-Reply-To: <5334A704.5020503@isi.edu> References: <5334A704.5020503@isi.edu> Message-ID: <53368A91.2080002@web.de> Bob, please forgive me a very personal reaction, however, I really can't help it. Deterministic networking is no way "new". That doesn't mean it would be wrong, on the contrary: It is perfectly adequate for quite a number of scenarios. What leaves me completely lost is, that I put in question the end to end principle for scientific reasons - and get personal offences for doing so, while some commercial guys (I had a very first glance at your text and ended up in "Deterministic Ethernet" and "Mercedes Benz", now, I'm living in Stuttgart, the world's capital of Sp?tzle and motorcars) are perfectly welcome to do so. I have no problem with this discussion. However, I wonder whether dollars pay more in this context than scientific craft. I would be perfectly comfortable when we split up computer science in "computer science" and "Mercedes Benz commercial computer services", so it becomes clear which arguments pay and which don't. Although this place is admittedly not adequate for doing so and I have to apologize, but I'm personally hurt by this discussion. Detlef -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de