John Heidemann | 24 Jun 18:58 2014
Picon

CFP: HotNets 2014 (conference: Oct 27-28, 2014, abstracts: July 9, 2014)


HotNets 2014: the Thirteenth ACM Workshop on Hot Topics in Networks

October 27-28, 2014 -- Los Angeles, California, USA

http://http://conferences.sigcomm.org/hotnets/2014/

Call for Papers

   The 13th ACM Workshop on Hot Topics in Networks (HotNets 2014) will
   bring together researchers in computer networks and systems to engage
   in a lively debate on the theory and practice of networking. HotNets
   provides a venue for debating future research agendas in networking and
   for presenting innovative ideas that have the potential to
   significantly influence the community.

   We invite researchers and practitioners to submit short position
   papers. In particular we are interested in papers that foster
   discussions that can shape research agendas for the networking
   community as a whole. Thus, we strongly encourage papers that identify
   fundamental open questions, or offer a constructive critique of the
   state of networking research.

   We also encourage submissions of early-stage work describing enticing
   but unproven ideas. Submissions can, for example, advocate a new
   approach, re-frame or debunk existing work, report unexpected early
   results from a deployment, or propose new evaluation methodologies.
   Novel ideas need not necessarily be supported by full evaluation;
   well-reasoned arguments or preliminary evaluations can be used to
   support their feasibility. Once fully developed and evaluated, we
(Continue reading)

Detlef Bosau | 3 Jun 14:43 2014
Picon

A Cute Story. Or: How to talk completely at cross purposes. Re: [ih] When was Go Back N adopted by TCP


I presume that I'm allowed to forward some mail by DPR here to the list
(if not, DPR may kill me...), however the original mail was sent to the
Internet History list and therefore actually intended to reach the public.

A quick summary at the beginning: Yes, TCP doesn't manage for sent
packets a retransmission queue with copies of the sent packets but
maintains an unacknowledged data queue and does GBN basically. This
seems to be in contrast to RFC 793, but that's life.

A much more important insight into the history of TCP is the "workload
discussion" as conducted by Raj Jain and Van Jacobson.
Unfortunately, both talk completely at cross purposes and have
completely different goals......

Having read the congavoid paper, I noticed that VJ refers to Jains CUTE
algorithm in the context of how a flow shall reach equilibrium.

Unfortunately, this doesn't really make sense, because slow start and
CUTE pursue different goals.

- Van Jacobson asks how a flow should reach equlibrium,
- Raj Jain assumes a flow to be in equilibrium and asks which workload
makes the flow work with an optimum performance.

We often mix up "stationary" and "stable". To my understanding, for a
queueing system "being stable" means "being stationary", i.e.
the queueing system is positively recurrent, i.e., roughly, in human
speech: None of the queue lengths will stay beyond all limits for all
times but there is a probability > 0 for a queue to reach a finite
(Continue reading)

Eric Rozner2 | 28 Apr 21:08 2014
Picon

IEEE LANMAN Call for Participation

CALL FOR PARTICIPATION
IEEE Workshop on Local and Metropolitan Area Networks (LANMAN)
http://www.ieee-lanman.org/ <http://www.ieee-lanman.org/#papers>

DEADLINE APPROACHING
Early Registration: April 28, 2014

CONFERENCE DATES
May 21-23, 2014
Reno, NV USA

DESCRIPTION
IEEE LANMAN has an established tradition as a forum for presenting and
discussing the latest technical advances in local and metropolitan area
networking. Continuing that tradition, IEEE LANMAN 2014 invites
cutting-edge papers spanning both theory and experimentation. Papers are
solicited in all areas of networking, but in keeping with the current
research trend, this workshop’s central theme is data center networking.
The intimate single-track session format of the workshop encourages
stimulating exchanges between researchers. The workshop is expected to be a
forum for discussion of new and interdisciplinary ideas on architectures,
service models, pricing, and performance. Speculative and potentially
transformative ideas are particularly encouraged, as are studies reporting
measurements from real-life networks and testbeds. Papers are solicited on
any LANMAN topic including, but not limited to, the following:

PROGRAM
http://www.ieee-lanman.org/#program

KEYNOTES
(Continue reading)

Pei Zhang | 20 Apr 05:43 2014
Picon

Call for Papers: ExtremeCom 2014 - The Galápagos Expedition (due in 2 weeks)

Dear Colleagues, 
I would like to bring your attention at the ExtremeCom 2014 submission deadline of
May 4th, 2014

******************************************************************

CALL FOR PAPERS AND DEMOS

Extreme Conference on Communication and Computing - The Galápagos Expedition

ExtremeCom 2014

11-16 August, Galápagos Islands, Ecuador

<http://www.extremecom.org/> http://www.extremecom.org/

******************************************************************

Important dates

--------------- ----

Submission deadline: May 4, 2014

Notification of acceptance: May 26, 2014

Early registration deadline: June 7, 2014

Registration deadline: June 15, 2014

(Continue reading)

Bob Braden | 27 Mar 23:32 2014
Picon

A not-end-to-end question

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 
(Continue reading)

J. Pan | 17 Mar 06:52 2014
Picon
Picon

[ACM IMC 2014] Call for Papers (Due: April 30, 2014)


[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
(Continue reading)

Detlef Bosau | 11 Mar 21:04 2014
Picon

Re: Just as an idea. Why can't we use hop by hop flow control for TCP?

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.
(Continue reading)

Joe Touch | 10 Mar 17:34 2014
Picon

a note about posts


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)

Jinsong Wu | 10 Mar 08:43 2014
Picon

Deadline April 1 CFP – 2014 IEEE Globecom Green Track


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
(Continue reading)

Detlef Bosau | 6 Mar 17:58 2014
Picon

Re: Just as an idea. Why can't we use hop by hop flow control for TCP?

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.

(Continue reading)

Detlef Bosau | 19 Feb 15:55 2014
Picon

Re: Just a very quick remark on system theory Re: Why don't we talk about segments/objects instaead of layers? Re: Lost Layer?

Am 19.02.2014 12:22, schrieb Saverio Mascolo:
> On Wed, Feb 19, 2014 at 9:56 AM, Detlef Bosau <detlef.bosau <at> web.de
> <mailto:detlef.bosau <at> web.de>> wrote:
>
>     And this is particularly true for engineers as they often don't
>     see the
>     "real" system equations but only the Laplace transform.
>
>
> laplace transform are equivalent to linear differential equation

Yes. And pigs can fly.

You never read a text book on analysis and the requirements for the
backward transformation to be unique? At least, things are extremele
tricky here.

Nevertheless: Differential equations are not suitable for the Internet,
neither is the Laplace Transform.

It is funny how the reactions are when I only point to what everyone
knows for decades: We worship a religion here.


Gmane