http://blog.gmane.org/gmane.network.end2end hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.network.end2end/7218 <pre>During the development of TCP during the 1977-1980 period, the original C&amp;K TCP layer was divided into a transport layer (TCP) and an internetwork layer (IP). One of the key decisions in this split was which layer should inherit the port numbers. At the time I simply accepted the group decision to put ports into the transport layer without taking time to think through the architectural implications. Has anyone ever thought through how the architecture would have been changed had ports ended up in the internetwork layer, i.e., in IP? Bob Braden </pre> Bob Braden 2013-04-23T19:24:46 http://comments.gmane.org/gmane.network.end2end/7201 <pre>[Apologies if you receive multiple copies of this message] ------ ========================================================== CALL FOR PAPERS ****************************************************************** Third International Conference on Selected Topics in Mobile &amp; Wireless Networking (MoWNet 2013) August 19-21, 2013, Montreal, Canada http://www.mownet.org/ </pre> Sameh R A Zakhary 2013-04-15T22:21:29 http://comments.gmane.org/gmane.network.end2end/7195 <pre>I'm curious, why the proposal by Keshav (his PhD thesis on Internet Congestion Control) was not widely adopted but VJCC instead. The main difference is that VJCC is purely end to end, while Keshav proposes schedulers on each node. Was this decision made for scalability reasons? </pre> Detlef Bosau 2013-04-16T12:38:39 http://comments.gmane.org/gmane.network.end2end/7169 <pre>This is a risky query. There have been previous threads about such things as the "start" of the Internet. Instead, I want to ask about the "architecture" of the Internet. Here's a comment that I sent earlier today, to a non-technical person who is aware of the overall Internet timeline, but I believe does not understand what is distinctive about Internet 'architecture'. I'm curious about reactions on this list, and any possible improvements -- including complete replacement -- but more importantly I'm interested in filling in the details: The original use of the term Internet was to describe a distinctive technical design for a distributed, scalable data exchange fabric. Its design characteristics differ dramatically from those of its predecessor, the Arpanet, and from other related efforts. That's what I sent. To prime the pump for the detail: By saying 'fabric' I meant to distinguish the mechanism for moving raw data from the applications that used it. What I'd class as distinctive were the TCP/IP separation, the remarkably modest functionality of IP, even to the point of moving it's control plane to the next level up with ICMP, and continuing with modest expectations the layer below (which made it possible to operate over any medium including birds.) This is usually characterized as moving robustness to the edges. Thoughts? d/ </pre> Dave Crocker 2013-04-12T03:59:42 http://comments.gmane.org/gmane.network.end2end/7163 <pre> Call For Papers *************** ACM CoNext 2013, Dec 9th to 12th, Santa Barbara, CA, USA ********************************************************* The 9th International Conference on emerging Networking EXperiments and Technologies (CoNEXT) will be held from December 9th to 12th in Santa Barbara, CA. CoNEXT 2013 will be a major forum for presentations and discussions of novel networking technologies that will shape the future of Internetworking. The conference is single track and features a high-quality technical program with significant opportunities for individual and small-group technical and social interactions among a diverse set of participants. This year the conference will feature two separate calls for papers. The first one will be targeted to mature, technical work, that has been the focus of the conference throughout the past 8 years (12 pages, 10 pt, 2 column). The second will be an explicit call for short papers (6 pages, 10pt, 2 column). With that call we would like to make CoNEXT a vehicle for the dissemination of new ideas, that may not have reached the level of maturity of full papers. Both types of papers will be reviewed by the same Technical Program Committee, but with separate processes. Relevant topics for the conference include, but are not limited to: ******************************************************************* Internet measurement and modeling Wireless networks Mobile and cellular networks Mesh, ad hoc and sensor networks Economic aspects of the Internet Network security Datacenter networks Peer-to-peer, overlay and content distribution networks Online social networks Routing and traffic engineering Network management, including energy issues Interface between networking, communications and information theory New networking protocols and architectures Applications of network science in communication networks Important Dates: **************** CoNEXT'13: Abstract submission June 8, 2013 CoNEXT'13: Full paper submission June 14, 2013 (hard deadline) CoNEXT'13: Short paper submission July 12, 2013 (hard deadline) CoNEXT'13: Acceptance notification September 23, 2013 CoNEXT'13: Camera ready November 1, 2013 CoNEXT'13: Conference December 9-12, 2013 General Chairs: **************** Kevin Almeroth, UC Santa Barbara, USA and Laurent Mathy, Universit de Lige, Belgium Technical Program Chairs: ************************ Dina Papagiannaki,Telefonica Research, spain and Vishal Misra, Columbia University, USA For More Details: ***************** Please see http://conferences.sigcomm.org/co-next/2013/ra, Columbia Uni</pre> Sanjay G Rao 2013-04-08T00:00:29 http://comments.gmane.org/gmane.network.end2end/7116 <pre>After some days of thinking, I think this question is a huge part of the buffer bloat discussion re-framed. I think it is one of the sacred cows in our community, that a connect() call will not fail with an "Insufficient Ressources Error" and a TCP flow once it is established will hardly be terminated for an actual resource shortage. So basically, many of us expect an infinite number of flows being possible on the Internet - though we (me) are not always aware of this fact, and then wonder about the consequences. Of course, I can fit 10^10 TCP flows on an 10 MBit/s Ethernet link. However, I should not expect too much throughput (or goodput respectively) for the individual flows. Among all strategies of congestion control, in VJCC I miss the real establishment of the two by far most obvious.: In case of congestion 1. reduce the rate of existing flows. (In VJCC and actually existing TCP Implementations we hardly can reduce a flow's rate beyond 1MSS/CWND. Exept perhaps by employing a pacing scheme, however I'm not quite clear yet about possible consequences.) 2. reduce the number of flows. "Soft" version: Block out new flows. "Hard" version: Terminate existing ones. (Just to make this clear: We don't want to deliver the Internet from individual packets. In case of overload, we want to deliver the Internet from sources of load. When your classroom is overcrowded, you first shut the door that nobody will come in any more - and if this does not suffice you will ask some persons to leave the room. In this picture, AQM appears to me as if we opened the window - and the persons in the room throw out their handkerchiefs.) The hard version rises the question, which flows should be terminated and - even more important: How do applications deal with flow termination / flow re-routing and of course, with respect to re-routing, how to we achieve a load sensitive routing in the Internet? Sometimes I think, one of our sacred cows is the "perpetual motion machine cow": "There is infinite capacity in the Internet and we all can use it each and every day." Actually, the Internet has limited, if huge, capacity and the issue is to share this in a reasonable manner. Detlef (asking for more capacity for his mailbox. It's interesting - and actually inspiring - to see how many people lurk on this list and hardly write anything here, but are often interested in interesting discussions off list.) </pre> Detlef Bosau 2013-03-30T14:29:15 http://comments.gmane.org/gmane.network.end2end/7111 <pre>Perhaps my question is a stupid one, however, can someone help me here? Detlef </pre> Detlef Bosau 2013-03-28T16:48:39 http://comments.gmane.org/gmane.network.end2end/7087 <pre>Hi, I am thinking of the congestion control problem for MORE-like traffic in Wireless Mesh networks, and get perplexed by some questions. I do apprecitate for your kind help. 1. MORE-like unicast traffic uses multipath routing with intra-session network coding, in which packets are randomly linearly encoded at both the source and the intermediates nodes. Specifically, Source s first divides the original message into batches, each containing K packets of the same length. It then generates and broadcasts random linearly combined packets within the current batch. Intermediates buffer the overheard packets, and then re-encode them before forwarding. Destination t recovers the original batch by collecting sufficient number of encoded packets, and then sends ACK to s so as to trigger the next batch until the whole message is delivered. 2. Packets belong to current batch should buffered at intermediate nodes, does the buffer here refer to the MAC queue or a cache at upper layer (e.g. socket buffer, or a cache in memory) . In my opinion, the received belong to a current batch will occupy the MAC queue for quite a long time before the whole batch is delivered to the destionation, which causes the MAC queue overflow very easily. So the better way is to buffer thesed packets at upper layer, right ? 3. If the packets are buffered at upper layer, the MORE traffic is less likely to be the reason of the congestion at routers, right? As the coded packets is generated and sent to MAC queue only when the MAC is able to transmit , at any time, there is at most one packet for each coded traffic in the MAC queue. 3. If the conjecture in item 2 is true, do we need any congestion control for MORE-like traffic? Regards, Kara </pre> shun cai 2013-03-13T03:42:30 http://comments.gmane.org/gmane.network.end2end/7076 <pre>Because of the recent discussion on congestion control, let me please refer to the following table, which is taken from "European Telecommunications Standards Institute. Digital cellular telecommunications system (phase 2+); General Packet Radio Service (GPRS); Service description; Stage 1. ETSI Standard EN 301 113 V6.1.1, 1998." and to my understanding describes the SDU delivery times via GPRS from the SGSN to the mobile. GPRS Delay Classes Hopefully, this table appears on the list, otherwise I would to have to write it down in ASCII characters. First, we can model this transport latency using the terms "serialization delay" and "propagation delay". In GPRS the maximum cell radius is about 32 kilometers, IIRC, so the propagation latency is certainly less than 0,1 milliseconds. Hence we can simply neglect the the propagation latency in this case. So let's talk about the "serialization delay". For 1024 octets, this may be up to 375 seconds, for 128 octets, it may be up to 250 seconds. In the first example, the resulting throughput is about 22.8 bit/second. The first question is, whether or not the RTT (the table above shows STT from the SGSN to the terminal) is stationary, so that we can derive some kind of RTO. BTW: Deriving an RTO from an observed RTT via Chebycheff/Cantelli/Edge is simply ridiculous here: The RTO is nothing but a, say, 0.95 quantile and would be 375 seconds here, which is far to long for any practical use. On the other hand, GPRS uses transport blocks / radio blocks for transmission and has a quite precise knowledge of the distance Antenna/Terminal (necessary for the GSM timing advance) and hence a much more realistic RTO for its own recovery layer. I strongly expect objections here because I didn't mention the appropriate reliability classes for the aforementioned delay classes. IIRC, the "QoS Profile" for delay class 3 ensures an SDU corruption probability less than 10^-9. So the recovery layer in that case is extremely strong. Particularly, any loss differentiation (corruption/congestion) is simply not necessary here. From TCP's point of view, corruption is negligible here. The second question is how we can explain the "serialization delay" and which consequences must be drawn from a "serialization delay" 375 seconds. I occasionally refered to "PERFORMANCE EVALUATION OF A TCP PROXY IN WCDMA NETWORKS" by Meyer, Holtzke, Sachs. IEEE Wireless Communications October 2003. Throughout this paper, the authors talk about a "latency bandwidth product" where "bandwidth" is the GPRS gross data rate 384 kBit/s. Even a WCDMA "bandwidth", i.e. 2 MBit/s is mentioned. So the reader is made to expect a "path capacity" 384 kbit/s * 375 seconds = 144.000 kbit. (750 Mbit respectively.) And of course, this huge path capacity should be utilized by an appropriate initial TCP window. Now, neither the air interface in GPRS or UMTS has a path capacity comparable to a 5 1/4" floppy disk nor the "serialization" of a 1024 octed SDU using a data rate 2 MBit/s lasts 375 seconds. So, the interpretation of the delay als "serialization time" is at least, say, strange, the so called "latency bandwidth" product in this case is simply an abuse of Little's formula. First of all, the "mean" value and the 0.95 quantiles in the table above indicate that the transport latency exhibits an extreme skew. So, the immediate question is, whether the expectations for service time, rate of arrival and jobs in the system exist at all and hence whether or not Little's law is applicable. Second, what are the jobs in the "system"? Packets sent via GPRS or UMTS are typically split up into a sequence of RLP blocks, so there are blocks for new transmissions, there are blocks for repeated transmissions, there are blocks for RLP control, hence the data to be transmitted (represented by the first transmission only) are only a part of the traffic in flight. And because GPRS offers only little adaptivity in its channel- and line-coding, but QoS profiles with an extremely low SDU corruption ratio, I strongly believe, that the payload interesting for higher layers is only a minor part of the traffic in flight. I did not yet get any sound explanation for the high transport times in GPRS. However, I think the major part is more or less queueing delay. And because the real air interface has hardly any "transient storage capacity" at all, I think, a sliding window approach for GPRS networks is completely inappropriate. We should use stop 'n wait here and that's it. Detlef </pre> Detlef Bosau 2013-03-11T12:19:39 http://comments.gmane.org/gmane.network.end2end/7074 <pre>Hi all, The CAIA MPTCP team is pleased to announce the initial release of our multipath TCP implementation for FreeBSD 10-CURRENT which is available from [1]. This release contains wire-related protocol code and a lot of core stack infrastructure. It is capable of running regular TCP flows and single or multi-subflow MPTCP flows (with some caveats as documented in the readme [2]). We consider this code to be of alpha quality and plan to release frequent updates going forward as we continue to flesh out additional features and fix the rough edges. That being said, we welcome everyone to start playing with the code and provide feedback, bug reports, fixes, praise and/or abuse ;) The "Multipath TCP for FreeBSD" project team consists of: Nigel Williams:lead R&amp;D engineer Lawrence Stewart:supporting R&amp;D engineer Grenville Armitage:principal investigator &amp; overall project lead Many thanks go to the Cisco University Research Program Fund at Community Foundation Silicon Valley for their support of this work. Have fun with it! Cheers, Lawrence, Nigel &amp; Grenville http://caia.swin.edu.au [1] http://caia.swin.edu.au/urp/newtcp/mptcp/tools.html [2] http://caia.swin.edu.au/urp/newtcp/mptcp/tools/mptcp-readme-v0.1.txt </pre> Lawrence Stewart 2013-03-10T16:58:17 http://comments.gmane.org/gmane.network.end2end/7040 <pre>Hi All, I believe I am posting to an appropriate list and target audience (if not, please point me to a more suitable mailing list or forum). I am conducting research for a Masters degree. I am studying the short comings, design oversites, or general unwanted behaviour of common networking protocols, that affects end users and applications that run over networks using these protocols (like Ethernet, MPLS, IP, UDP, TCP etc). An example of this would be that Ethernet has no TTL, so that is one good reason to have some form of spanning tree protocol on a network with redundant links (but spanning tree is also flawed). Another example; TCP has to ACK a lot, now we have Selective Acknowledgements which is useful for LFNs. Can anyone show or tell me where I might find some good research on common protocols? Or perhaps give me some pointers on what to look for my self? So far, the vast majority of research I pull up is about TCP congestion control, so I'd like to find something different if possible. Many thanks, James. </pre> James Bensley 2013-03-06T18:39:14 http://comments.gmane.org/gmane.network.end2end/7010 <pre>I hope that people of this E2E list are reading the current thread on the IETF list about choosing a new Transport Area director who is/is not an expert in congestion control. Some of you have been around long enough to recall the congestion collapse of the (NSF-sponsored) Internet, before Van J showed us how to not be stupid when he defined the basic TCP CC mechanism. They/we invented the concept of "TCP Friendly" to try to head off a race to the bottom while providing an easy-to-understand criterion for acceptable CC. It seems like an interesting question for research to determine whether widespread adoption of some future transport protocol with an ill-advised or inadequate CC mechanism could still cause congestion collapse of large areas of the Internet,or only local patches. Or has that been researched and I missed it? Congestion control seems a bit like riding a unicycle -- even after you learn how to do it, you have to pay attention every moment or you are in danger of falling off. Bob Braden </pre> Bob Braden 2013-03-04T17:45:25 http://comments.gmane.org/gmane.network.end2end/7004 <pre>After some recent off list discussions, I think we have some issue here. First of all: Where is the right place for loss recovery? Up to now, we discuss mainly two alternatives: End to End and local. When a packet cannot be successfully transmitted via some mobile link due to noise, it does neither make sense to repeat it over and over locally nor does it make sense to repeat it over and over end to end. Although the latter alternative is worse than the first because /absurd retransmissions end to end do harm to competing flows./ The same holds true when we replace retransmissions by some sophisticated FEC scheme, as it was by Van Jacobson in "A Rant on Queues" in 2006. Despite of all other difficulties, avoiding local ARQ by adding redundancy, e.g. like in the TETRYS work by Lochin et al., uses resources which are no longer available for competing flows. Now, in his talk, VJ proposes even to avoid local Reed Solomon Coding and the like and I completely disagree. I think we are in the well proven tradition of Salzers End to End paper, when we carefully consider were packet recovery is done best: As locally as possible. First, there is nothing like "the universal error free FEC", any kind of FEC will always be chosen adequate to the link. If a FEC scheme is chosen to strong, the resource consumption is to expensive and the throughput as seen by upper layers is to small. If a FEC scheme is chosen to weak, a flow (and hence competing flows as well) will suffer from lots of retransmissions. Second, when we want to find FEC schemes appropriate for a channel, we must a) have information about the noisy channel to find appropriate schemes and b) react timely. When we think of, e.g., HSDPA where the coding scheme is adapted every 2 milliseconds, it is obvious that we cannot timely adapt to a HSDPA link on a End to End basis. A basic insight, which seems not to be commonly accepted to me, is that a link's throughput, more precisely: the time needed to successfully transfer a packet on the link, does not mainly depend on the technology in use but on the channel's properties. I was a bit confused here by RFC 3819, where the authors write the following: First, such a link layer inevitably needs some local FEC/ARQ mechanism. Second: The loss probability does not depend on the link layer but on the channel. Of course, a link layer may abstract this to upper layers - to the cost of unbounded transmission times. Particularly for HSDPA, the typical selection schemes for coding schemes well include "out of range areas", i.e. when a channel is too bad it is simply not used. What makes me curious in the context of the aforementioned RFC is that the authors in the following text use well known TCP formulae, e.g. by Mathis or Padhye, to do throughput estimations and simply assume that parameters like "RTT" or "RTO" would be available in the context of mobile networks. Or when it comes to the dimensioning of queueing memory, it is assumed that we had something like a "bottleneck bandwidth" which is the least throughput along the path. What is the throughput of a mobile wireless interface? Particularly in the context of packet switching where we expect packets to be delivered correctly? /Simply spoken: In the general case, it is unknown./ *What are my conclusions?* 1. As soon as TCP paths include one or more mobile links, TCP RTT estimators, and hence derived confidence intervals like RTO, do not really hold. 2. The same holds true for formulae based upon those statistics. 3. Error recovery should be done as locally as possible. In that particular respect we should change our attitude from hat outlined in RFC 791 from to an attitude where we request a sufficiently small packet loss probability, e.g. 1 percent, and request an appropriate signalling mechanism when this cannot be achieved in order to look for a possibility to overcome the problem, e.g. by some route change, or to inform the application layer of the problem to enable appropriate actions. It may even be appropriate to define some technology specific maximum transmission time for a packet, hence we have a certain limit: "SDU transmission time &lt; 0.1 seconds, SDU loss probility &lt;= 0.01" - and when this cannot be achieved, upper layers are notified accordingly. 4. TCP is an asynchronous protocol. We should not expect TCP flows to run "smoothly" with "the same rate" from End to End throughout the whole path. TCP packets my clump together in parts of the path, they may be sparsely distributed in others. Hence, we should discuss whether it does make sense to do congestion control, resource management and scheduling on a strong End to End basis, as it is done today, or whether we should discuss possible alternatives. (This discussion is not only motivated by mobile networks, I could mention other reasons as well, however in this post I would like to restrict myself on mobile networks.) </pre> Detlef Bosau 2013-02-24T15:08:36 http://comments.gmane.org/gmane.network.end2end/7003 <pre>Hi, all, By popular request, I've restored the DNS calculator function as an operational service. See: http://www.isi.edu/touch/tools/dns-calc.html (this was designed for a Sigcomm OO session, but it's been used several places as a good example why the DNS should NOT be anything more than a mapping service) Joe PS - if you do happen to use it as an example, please do drop me a note; I'd be very glad to track that info. and/or include a pointer to the classes that use it. </pre> Joe Touch 2013-02-14T22:38:49 http://comments.gmane.org/gmane.network.end2end/6997 <pre>Hello, We just made publicly available to the community the datasets we used for our paper Network Characteristics of Video Streaming Traffic. Ashwin Rao, Yeon-sup Lim, Chadi Barakat, Arnaud Legout, Don Towsley, and Walid Dabbous. In Proc. of ACM CoNEXT'11, Dec. 6--9, 2011, Tokyo, Japan. This dataset contains detail traffic logs of packets exchanged during YouTube and Netflix streaming sessions. For each streaming session, we used tcpdump to capture the packets exchanged between the streaming server(s) and our client. We then parsed these pcap files to log the packet timestamp, the tcp sequence number, and packet length of each packet exchanged between the streaming server(s) and the client. This dataset contains these logs along with other auxiliary information that we used to better understand the observed traffic patterns. The dataset can be downloaded from http://www-sop.inria.fr/members/Arnaud.Legout/Projects/streaming.html All details on this dataset are available in our CoNEXT'11 paper. Feel free to contact me for any questions regarding this dataset. Regards, Ashwin </pre> Ashwin Rao 2013-01-31T18:13:21 http://comments.gmane.org/gmane.network.end2end/6988 <pre>We apologize if you receive multiple copies of this note. ************************************************************************* Call for Presentations: Research Track at the Open Networking Summit 2013 ************************************************************************* Software Defined Networking (SDN) refactors the relationship between network devices and the software that controls them. Open interfaces to network switches enable more flexible and predictable network control, and they make it easier to extend network function. Several router vendors have introduced software development kits for programming their network devices, and many commercial devices support the emerging OpenFlow standard. Open Networking Summit (ONS) has emerged as the premier OpenFlow and SDN event. The first two ONS events were very well received. The events showcased invited presentations on SDN from industry and academic leaders; 20+ exhibits that demonstrated SDN technologies and products; and, two day-long tutorials for engineers and managers. The research community is actively pursuing a variety of important open issues in SDN. Examples include switch design and APIs that balance flexibility and performance; new applications to capitalize on the programmability of the network; transitioning an existing network to SDN, and many others. ONS 2013 will feature a new **Research Track** where researchers can present their cutting edge SDN work. The Research Track is designed to leverage the strong industry presence at ONS to bring to focus research problems that are highly relevant to the larger SDN community, to allow a free exchange of ideas, and to help build a focused community effort to explore and realize the potential of SDN. We encourage interested presenters to submit a two-page extended abstract describing their SDN research. While we are particularly interested in early stage work, we also welcome submissions that summarize published results. Submissions will be selected based on originality of the work, likelihood of spawning insightful discussion, and technical merit. Each accepted submission would be granted a long (20 minutes) or short (10 minutes) presentation slot. We solicit submissions on topics including, but not limited to, the following: - Applications of SDN in home, wireless, cellular, enterprise, data-center, and backbone networks - Application of SDN to network management, performance monitoring, security, etc. - Virtual appliances (e.g., firewalls, intrusion detection systems, load balancers, etc.) on SDN - Virtualization support in software-defined networks - Switch designs for SDN - Control and management software stack for SDN - Programming languages, verification techniques, and tools for SDN - Performance evaluation of SDN network elements and controllers - Hybrid SDN approaches (integration with other control planes) - Transitioning existing networks to SDN - SDN control plane abstractions Important dates Submission deadline: Feb 11, 2013 Acceptance notifications: Mar 1, 2013 Final version due: Mar 15, 2013 Research Track dates: Apr 16 and 17, 2013 Program Committee Aditya Akella, UW-Madison (Co-chair) Martin Casado, Nicira/VMWare Nate Foster, Cornell Albert Greenberg, Microsoft Guru Parulkar, Stanford Nick Feamster, Georgia Tech Atsushi Iwata, NEC Jeffrey Mogul, HP Labs Vijoy Pandey, IBM Jennifer Rexford, Princeton Prodip Sen, Verizon Amin Vahdat, Google/UCSD (Co-chair) For further details, please see http://opennetsummit.org/research-track.html </pre> Aditya Akella 2013-01-10T01:40:58 http://comments.gmane.org/gmane.network.end2end/6977 <pre> [I tried to post this in a couple places to ensure I hit folks who would be interested. If you end up with multiple copies of the email, my apologies. --allman] I know bufferbloat has been an interest of lots of folks recently. So, I thought I'd flog a recent paper that presents a little data on the topic ... Mark Allman. Comments on Bufferbloat, ACM SIGCOMM Computer Communication Review, 43(1), January 2013. http://www.icir.org/mallman/papers/bufferbloat-ccr13.pdf Its an initial paper. I think more data would be great! allman -- http://www.icir.org/mallman/ </pre> Mark Allman 2013-01-07T18:36:07 http://comments.gmane.org/gmane.network.end2end/6960 <pre>Thanks, Joe. Bob Braden </pre> Bob Braden 2012-12-18T20:41:31 http://comments.gmane.org/gmane.network.end2end/6947 <pre>I have to apologize for this question, however, I would greatly appreciate to get in touch with academic persons who are interested in this area. </pre> Detlef Bosau 2012-12-11T13:20:03 http://comments.gmane.org/gmane.network.end2end/6946 <pre>========================================================================================== CALL FOR BOOK CHAPTER PROPOSALS (500 words) Convergent Divergence? - Cross-Disciplinary Viewpoint on Media Convergence Springer-Verlag, Germany Artur Lugmayr, Cinzia Dal Zotto, and Gregory Ferrell Lowe Lowe (Eds.) * 5 DAYS LEFT * * 5 DAYS LEFT * * 5 DAYS LEFT * * 5 DAYS LEFT * * 5 DAYS LEFT * http://www.tut.fi/emmi/Submissions/2012ConvergenceBook/ ++========================================================================================= Upcoming Deadline: 1st December 2012 - intention to prepare a manuscript Book Website: http://www.tut.fi/emmi/WWW/ameamain/2012convergence Email List:https://listmail.tut.fi/mailman/listinfo/emmi-convergence Submission System: http://www.tut.fi/emmi/Submissions/2012ConvergenceBook/ Contact us:emmi-convergence&lt; at &gt;listmail.tut.fi Media Convergence happens on many levels and each of them implicates specific challenges and priorities. Within the scope of this book, we focus on end-to-end convergence on various levels: managerial, information systems, and end-consumers level. The book will especially shed light into the complexity of the topic and act as a reference book and educational resource in this field. The implementations of convergence strategies can only succeed when they take into account the expectations and aspirations of every actor with a stake in the enterprise, including content producers. Managers unanimously agree on the importance of human resources management within the implementation process. This consideration implies that convergence is more than an economic opportunity and needs to be understood as well as a focus of editorial strategy. Convergence is often discussed at a rhetorical and political level. But how does convergence actually happen, and does convergence lead to divergence? Media industry understands convergence in ways that differ from the perceptions of consumers, who are clearly diverging in the ways they consume media. Media managers are faced with the need to satisfy users? expectations and also undertake convergence as an industrial strategy to achieve economies of scope &amp; scale. Another challenge lies in the development of information systems in media industries that support convergence. Do these also lead to divergence? Does blurring the boundaries between the various distribution platforms let media diverge from the consumer?s point of view? This book will encourage an active discussion around this theme, taking multiple viewpoints into account: a content creator perspective (journalistic or artistic), an information system perspective, the consumer?s expectations, management and technological challenges, as well as market dynamics. In conclusion, can all the challenges of convergence be solved, or does convergence lead to further divergence. ========================================================================================== Topics of Interest ========================================================================================== ------------------------------------------------------------------------------------------ Convergence Issues in the Media Industry and Media Organizations ------------------------------------------------------------------------------------------ o Media policy and regulatory challenges o Cross-platform, cross-country, and converging media policies o Convergence versus media market competition and concentration o Media products demand and offer, consumers versus producers: diverging convergence? o Convergence and managerial challenges in the media industries (TV, radio, news, publishing, music, online) o Converging newsrooms, organizational and human resource development o Convergence management and leadership o Business models and strategies for converging media products and services o Impact of social media on convergence processes o Branding media in converging environments o Marketing and advertising in converging environments o Intellectual property rights and royalty management in convergence processes o Quality and ethics in converging environments o Management, leadership of projects and media organizations for convergence ------------------------------------------------------------------------------------------ Technological Convergence ? Media Business Information Management &amp; Information Systems ------------------------------------------------------------------------------------------ o Media business information management for convergence o Media information system design enabling convergence o Business intelligence in converging media environments o Knowledge management systems in converging environments o Workflow management, operational efficiency and new capturing technologies producing converging services o Operational efficiency and cost reduction of converging technologies o Cross-media offering, distribution channels and convergence o Home platforms, mobility, multi-play and network convergence o Systems for management reporting, analysis, and decision support in converging environments o Standards to enable technical convergence o Data warehousing in converging environments o Integration of analogue and digital media productions o Mobile convergence o E2E systems and solutions in converging media environments o Production processes for convergence o Asset management and metadata enabling convergence o E2E systems, infrastructures and solutions o Collaborative media productions and convergence o Integration of analogue and digital media production and distribution ------------------------------------------------------------------------------------------ Convergence Issues from a Consumer, HCI, Experience Perspective ------------------------------------------------------------------------------------------ o Quality of Experience (QoE) o Customer service/relation management (CRM) and analytics o Audience and consumer research within convergence processes o Convergence versus personalized and individualized media products offerings o Convergence and consumer loyalty aspects, consumer targeting, niche audiences, and new revenue streams o Changing aesthetics of media in times of convergence o Human centred and user friendly computing and interaction o New technologies for consumer studies and research o User experience, user innovation and convergence o User experience, user innovation and convergence o Social impact o Security and privacy in a converging environment o Human computer interaction and experience design enabling convergence o Understanding the audience, audience trends, and audience statistics in converging eco-systems o and experience Tools, systems, theories, and techniques to understand, create and design interactivity ------------------------------------------------------------------------------------------ Convergence in Practice: Applications, Services, and Eco-Systems ------------------------------------------------------------------------------------------ o Converging service economy o Convergence and sustainability o Convergence project management o Business information systems o Convergence media industry projects (TV, movie, online, and print) o Successful and unsuccessful case studies on media convergence o End-to-end digital content o Live events o Etc. We strongly welcome other topic suggestions dealing with convergence on a managerial, information system, and consumer level beyond the topics suggested above. ========================================================================================== Schedule &amp; Deadlines ========================================================================================== * 1st December 2012 Notification for intending to contribute with a book chapter to help us in the review process planning of the book (author team, preliminary title, and very brief abstract of max. 250 words) * 31st January 2013 1st manuscript version (also authors who did not notify us to intend to contribute are invited to submit) * 1st March 2013 Review comments for 1st manuscript version and notification of acceptance * 31st May 2013 2nd manuscript version that should include several review comments and final notification of acceptance * 1st July 2013 Final manuscript ========================================================================================== Manuscript Preparation ========================================================================================== * please follow the manuscript formatting guidelines below, and only submit the original version (in Microsoft word) with the submission system * each final manuscript should be 15-20 pages long (depending on the number of submissions longer manuscripts will also be accepted) * Please prepare your manuscript according the following guidelines: http://www.springer.com/authors/book+authors?SGWID=0-154102-12-417900-0 * Manuscript submission website: http://www.tut.fi/emmi/Submissions/2012ConvergenceBook/ ========================================================================================== Stay Informed ========================================================================================== Email-list: https://listmail.tut.fi/mailman/listinfo/emmi-convergence Questions:lartur&lt; at &gt;acm.org (please cc to: emmi-convergence&lt; at &gt;listmail.tut.fi) Facebook:https://www.facebook.com/groups/ConvergentDivergence/ br, Artur -------------------------------------------------------------------------------------------------------------------------- Prof. Dr. Artur Lugmayr Tel.: +358 (0)40 849 0773 or +358 (0)40 821 0558, Fax.: +358 3 3115 4680 artur.lugmayr&lt; at &gt;tut.fi, http://www.tut.fi/emmi/, http://www.facebook.com/artur.lugmayr, http://www.artur-lugmayr.info/, http://twitter.com/lartur#, www.ambientmediaassociation.org Tampere University of Technology Department of Business Information Management and Logistics P.O. Box 541, Korkeakoulunkatu 8 FIN 33101 Tampere FINLAND </pre> artur.lugmayr< at >tut.fi 2012-11-26T22:16:16 http://comments.gmane.org/gmane.network.end2end/6944 <pre>Hi, all, The E2E list includes an advisory group who is provides oversight to the list, as noted here: http://www.postel.org/e2e.htm Craig Partridge has concluded his term as a member of this group, helping establish this list as free-standing upon the conclusion of the IRTF E2E RG. Lachlan Andrew has accepted our invitation to join the group, which also includes Henning Schulzrinne and Scott Brim. Please join me in thanking Craig for his service, and welcoming Lachlan. Thanks, all, Joe (as E2E list admin) </pre> Joe Touch 2012-10-25T00:27:00 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.network.end2end