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

dunn at umn.edu (Larry Dunn) Thu, 19 November 2009 12:44 UTC

From: dunn at umn.edu (Larry Dunn)
Date: Thu, 19 Nov 2009 06:44:40 -0600
Subject: [Tmrg] Now, where were we...?
In-Reply-To: <aa7d2c6d0911181647i755ed6eft9dbe3168d38019b3@mail.gmail.com>
References: <aa7d2c6d0911181647i755ed6eft9dbe3168d38019b3@mail.gmail.com>
Message-ID: <B7F5500F-02D4-4F75-AAE2-2D654AD9891D@umn.edu>

   I'll self-declare as group "A" - though you wouldn't conclude that  
from my level of
     contribution to the list, lately. ;-)

   Nice set of issues- I'll start re-pondering them (and hope others  
   more quickly than me on said issues...)


On Nov 18, 2009, at 6:47 PM, Lachlan Andrew wrote:

> 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?
> Cheers,
> Lachlan
> -- 
> 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
> _______________________________________________
> Tmrg-interest mailing list
> Tmrg-interest at ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/tmrg-interest