[Iccrg] Meeting agenda

[Michael Welzl]

On Fri, 2006-09-08 at 19:38, Wesley Eddy wrote:
> On Wed, Sep 06, 2006 at 07:19:09PM +0200, Michael Welzl wrote:
> > Dear all,
> > 
> > Let's see what could be discussed at the planned ICCRG meeting.
> > Topics we recently discussed on the list are:
> > 
> > - congestion control definition
> > - taxonomy of congestion control approaches
> > - issues surrounding explicit feedback
> > - expanding the application of congestion control beyond file transfer
> > - applicability of TMRG drafts to congestion control research
> > 
> > Any volunteers who would want to do a short presentation on
> > one of these topics, or a similar one, and then hopefully
> > get a discussion going?
> > 
> > Are there topics which you'd consider more interesting? I'm
> > looking for your input!
> >
> 
> The odds of me attending the meeting are exceedingly slim due to a date
> conflict, but here are a couple of other topics that I think are sort of
> unanswered questions the group might want to consider:
> 
> 1) congestion control when striping data over multiple paths.  Issues
>    here involve mechanisms for detecting the degree of independence between
>    paths, and identifying shared-congestion on the common portions of
>    multiple paths.  These have come up in the IETF in the context of SCTP.
>    After shared congestion is identified, what is the proper response?
> 
> 2) congestion control for mobile nodes and within mobile networks
>    (either NEMO or Connexion by Boeing style).  What are the scenarios
>    where existing mechanisms are valid, and under what conditions do
>    they break down?  What is the space of solutions (e.g. you could do
>    things like TCP RLCI, or more radical things)?  What is sensible for
>    MANET-style networks?
>  
> I may be wrong, but if there are good and well-accepted answers to these
> questions, I don't think they are widely known.

Thanks Eddy! This inspires me to mention one more:

The correct reaction to corruption.

>From RFC 4340:

The combination of reduced checksum coverage and Data
Checksum options may let endpoints report packets as corrupt rather
than dropped, using Data Dropped options and Drop Code 3 (see Section
11.7).  This may eventually benefit applications.  However, further
research is required to determine an appropriate response to
corruption, which can sometimes correlate with congestion.  Corrupt
packets currently incur a loss response.


There seems to be some agreement (and, by the way, I
also personally agree  :-)   ) that the (not so uncommon)
idea of a sender which would not reduce its rate at all
in response to corruption is not the right way to do it.

Here's a (somewhat artificial) example explanation: you may
have a sender which generates a lot of traffic, yet doesn't
deliver anything useful - yet, this sender may cause other
senders to reduce their rates, even though they would
not experience any corruption whatsoever.

It may be the right thing to reduce the rate by less than
in the normal congestion case, but by how much...?

This question also applies to a current SCTP draft, btw.

Cheers,
Michael