[Tmrg] Now, where were we...?

lachlan.andrew at gmail.com (Lachlan Andrew) Thu, 19 November 2009 00:47 UTC

From: lachlan.andrew at gmail.com (Lachlan Andrew)
Date: Thu, 19 Nov 2009 11:47:14 +1100
Subject: [Tmrg] Now, where were we...?
Message-ID: <aa7d2c6d0911181647i755ed6eft9dbe3168d38019b3@mail.gmail.com>

Greetings all,

Things have been rather quiet on this list since Sally's retirement,
and I'd like to get things moving again (after Aaron's gentle
prompting :)

Just as a stock-take, could people please indicate whether they
consider themselves
  A: part of the TMRG
  B: subscribed to this list to follow "what they in the TMRG are doing"
Since this WG was chartered as "mailing-list only", everyone on the
list is really in group A, whether they know it or not.

For those who prefer publishing papers than writing Internet Drafts,
remember that the licence for an ID allows "derivative works", so you
can still publish your models/evaluation/...  Like the ArXiv, the ID
process is a good way to place a stamp on your ideas and get feedback
before publishing.

What important open issues issues are there in transport modelling?
(Rather than having an "open issues" draft like ICCRG is doing, let's
start with a discussion here.)

To get the ball rolling, here are some issues (mostly courtesy of Doug Leith):

1. How can we model "loss synchronisation" between flows sharing a
congested link?  Theoretical models typically assume either that the
per-packet loss probability is equal for all flows (no
synchronisation) or that all flows lose a packet whenever one flow
does (perfect synchronisation).  The truth is somewhere in between,
but where?  How does it depend on the behaviour of the transport
algorithms?  (e.g., H-TCP induces more synchronisation than Reno.
CUBIC can induce either more or less, depending on how its
fast-convergence mode behaves.)

2. How reliable are implicit congestion indicators?  The prevailing
wisdom in the IETF seems to be that "ECN=loss = congestion, delay =
noise, nothing else is useful for congestion control".  What criteria
would "delay" have to satisfy in order to be a useful indicator of
congestion?  Should we listen to the average delay, the frequency with
which delay exceeds a threshold, or the jitter?

More importantly, are there other ways the network might be telling us
things?  For example, does packet reordering tell us anything?  (I
believe that Van Jacobson's key insight was not "loss indicates
congestion", but that we should "listen to the network calling for
help", however it does that.)

3. Most internet users are now home users with dedicated bottlenecks,
rather than institutional users.  Should we reconsider whether
artefacts such as phase effects deserve a place in our models?
Recently some people here at Swinburne noticed a similar effect
occurring with a single CUBIC flow on a "clean" network.  Are these
artefacts or important phenomena?

4. What role should highly-idealised models play?  Are there generic
ways to include important phenomena like jitter and loss
synchronisation into mathematical models of congestion control, or is
that too naive?

5. What aspects of transport protocols need to be modelled other than
their congestion control mechanisms (for which we have the ICCRG...)?
For example, are there "correctness" issues (deadlock avoidance etc)
with multi-path and multi-endpoint transport protocols?  Does this
list reach the right community to address those issues?


Lachlan Andrew  Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia
<http://caia.swin.edu.au/cv/landrew> <http://netlab.caltech.edu/lachlan>
Ph +61 3 9214 4837