[Iccrg] Meeting agenda

[John Leslie]

Michael Welzl <michael.welzl at uibk.ac.at> wrote:
> On Fri, 2006-09-08 at 19:38, Wesley Eddy wrote:
>> 
>> 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?

   There is a "correct" thing to do; but I don't claim it's practical:
have the two routers surrounding the split maintain it as a single virtual
path, with a single congestion behavior.

   Anything less than this will tend to break the model on which congestion
control is built. :^(

>> 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?

   This one is hard! Congestion characteristics will change at each
handoff. The best we can hope for is to pass the characteristics to one
or both endpoints. (Interestingly, this shares some features of the split
case above, but none of the stability.)

> Thanks Eddy! This inspires me to mention one more:
> 
> The correct reaction to corruption.

   Actually, there is one: increase the reundancy of coding.

   This actually will result in a hopefully-slight _increase_ in bandwidth
demand. This is _not_ wrong!

> 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.

   TCP, of course, will throttle back _and_ retransmit as often as needed.
That will actually make _more_ bandwidth available than the ideal.

> 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 is always "wrong" to fill a pipe with traffic which serves no useful
purpose. Alas, there's often no way to determine whether it's useful.
Were it known to be useless, the sender should of course scale back.

   This brings up the "broadcast-like" usages found today. These are
incorrect uses of the Internet -- trying to make it something it isn't.
Most of the time, these should probably behave more like time-shifting
uses: when there is a genuine need for "real-time" data, they should
mimic VoIP.

   There are, of course, genuine "multicast" uses -- such as conferencing.
Multicast is its own research issue...

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

   Wrong question!

   Sufficient redundancy can repair the corruption (and, of course,
eliminate the need for retransmission). If retransmission _is_ needed,
I would agree that transmission rate should be reduced -- at a minimum
the retransmission must be counted against the allowed rate. I would
personally like to see an additional decrease to match the increase
which would be needed for sufficient redundancy, but this may not be
worth trying to specify.

   As for the question of correlation of congestion to corruption: this
assuredly does happen in wireless. But I'm not sure it's practical to do
anything about it. It can come either from noise due to more data being
sent or be due to a sender being configured to push the envelope on
signal-to-noise permissible for a higher data rate. The first is too hard
to measure (if indeed it's even related to anything we're involved in);
the second needs to be punished more severely than we can do.

--
John Leslie <john at jlc.net>