[e2e] Is a control theoretic approach sound?

[John T. Wen]

Stability usually refers to "stability in the sense of Lyapunov", which
means that if the state starts sufficiently close to the equilibrium, then
the entire trajectory will stay as close as to the equilibrium as one
specifies.   There is also the notion of practical stability which loosely
means trajectory will converge to an ultimate bound that is "acceptable" for
whatever application under consideration.  In terms of the source rate, I
think it may be true that it will remain bounded, but it may diverge from
the equilibrium and the oscillation and ultimate bound may not be acceptable
for practical applications.  For queue length, however, it can certainly go
unbounded.
John

----- Original Message -----
From: "Ibrahim Matta" <matta at cs.bu.edu>
To: "Gaurav Raina" <G.Raina at statslab.cam.ac.uk>; "Saverio Mascolo"
<mascolo at poliba.it>
Cc: "Shivkumar Kalyanaraman" <shivkuma at ecse.rpi.edu>;
<end2end-interest at postel.org>; "John Wen" <wen at ecse.rpi.edu>; "Murat Arcak"
<arcak at ecse.rpi.edu>
Sent: Thursday, July 31, 2003 11:29 AM
Subject: RE: [e2e] Is a control theoretic approach sound?



It's nice to see the term "stable limit cycles"! I have seen some folks
wrongly referring to such behavior as "unstable", when in practice, a
finite system like TCP (with finite link capacity, finite buffers, ...)
can *never* be unstable!

This wrong classification as "unstable" sometimes comes from using
standard stability analysis techniques on a model linearized around a
certain operating point. The system going outside this range does *not*
mean that the system is unstable - rather it might be oscillating
between two different operating regimes (cf, non-linearity). We point to
some of these issues in "On the Efficiency and Fairness of Transmission
Control Loops: A Case for Exogenous Losses"
http://www.cs.bu.edu/techreports/pdf/2003-013-exogenous-loss-effect.pdf

Ibrahim


--
Ibrahim Matta, Associate Professor
Dept. of Computer Science, 111 Cummington Street
Boston University, Boston, MA 02215, USA
Email: matta at cs.bu.edu, Tel: (617) 358-1062, Fax: (617) 353-6457
http://www.cs.bu.edu/fac/matta


> -----Original Message-----
> From: Gaurav Raina [mailto:G.Raina at statslab.cam.ac.uk]
> Sent: Thursday, July 31, 2003 8:01 AM
> To: Saverio Mascolo
> Cc: Shivkumar Kalyanaraman; end2end-interest at postel.org; John Wen;
Murat
> Arcak
> Subject: Re: [e2e] Is a control theoretic approach sound?
>
>
> The analysis in:
>
> Dynamics of TCP/RED and a Scalable Control
> S. H. Low, F. Paganini, J. Wang, S. Adlakha, J. C. Doyle
> Proceedings 2002 IEEE Infocom, New York, June 2002.
>
> Showed very carefully (using ns) how as delays increase, stable limit
> cycles are formed which increase in amplitude as the delay increases.
> With delays we get an infinite-dimensional system, which
> will not produce limit cycles if it has a linear structure.
>
> Linear (delayed) systems will either have fixed points as attractors
or
> unbounded trajectories - So it is a boon that TCP has a non-linear
> component to it.
>
> Gaurav
>
>
> On Thu, 31 Jul 2003, Saverio Mascolo wrote:
>
> > Hi,
> >
> > why do you think that TCP is a nonlinear system?
> >
> > By quoting V. Jacobson cornerstone paper :
> >
> > "Network is, to a a very good approximation, a linear system. That
is,
> it is
> > composed of elements that behave like linear operator-integrators,
> delays,
> > gain stages, etc"
> > - Van Jacobson, "Congestion Avoidance and Control," in Proceedings
of
> ACM
> > Sigcomm'88.
> >
> > I think that modeling the TCP as a nonlinear system not only
introduces
> not
> > useful complexity but it is  wrong!
> >
> > Saverio Mascolo
> >
> > ----- Original Message -----
> > From: "Shivkumar Kalyanaraman" <shivkuma at ecse.rpi.edu>
> > To: <end2end-interest at postel.org>
> > Cc: "John Wen" <wen at ecse.rpi.edu>; "Murat Arcak"
<arcak at ecse.rpi.edu>
> > Sent: Thursday, July 31, 2003 2:49 AM
> > Subject: Re: [e2e] Is a control theoretic approach sound?
> >
> >
> > >
> > > The issue of considering delay robustness and several other
> > > properties directly in a non-linear dynamic control theoretic
> framework
> > > has been proposed by my control-theory colleagues John Wen and
Murat
> Arcak
> > > in their INFOCOM 2003 paper -- this framework is a superset of
Kelly
> and
> > > Low static optimization frameworks and linearized stability
analyses.
> > > Since my colleagues do not read this mailing list, please cc your
> > > responses directly to them too.
> > >
> > > It is becoming clear that basic dynamics and steady state behavior
of
> > > congestion control schemes are best understood at the "flow"
> > > level in optimization frameworks; and "fine-tuning" of schemes can
be
> done
> > > at the "packet" level (eg: estimation robustness issues,
> > > increase/decrease: AIMD etc, slow start, interaction with
timeout/rtt
> > > estimation etc). This "packet-level" dynamic behavior can be
validated
> by
> > > ns-2 simulations or implementation trials.
> > >
> > > This is the essence of the approach of Kelly and Low frameworks
and
> the
> > > other generalized frameworks...
> > >
> > > -Shiv
> > > ===
> > > Shivkumar Kalyanaraman
> > > Associate Professor, Dept of ECSE, Rensselaer Polytechnic
Institute
> (RPI)
> > > 110, 8th Street, Room JEC 6003, Troy NY 12180-3590
> > > Ph: 518 276 8979   Fax: 518 276 4403
> > > WWW: http://www.ecse.rpi.edu/Homepages/shivkuma
> > >
> > > A goal is a dream with a deadline -C. Knight
> > >
> > >
> > > On Thu, 31 Jul 2003, Panos GEVROS wrote:
> > >
> > > >
> > > > ----- Original Message -----
> > > > From: "Yunhong Gu" <ygu1 at cs.uic.edu>
> > > > Subject: Re: [e2e] Is a control theoretic approach sound?
> > > >
> > > > > Well, I think to decide how "aggressive" the AI will be is not
> that
> > > > > *simple* a problem :) It is not the more aggressive the better
> (even
> > if
> > > > > the per flow throughput is the only objective), right?
> > > >
> > > > agreed but only if you want to address the problem in its full
> > generality
> > > > ... if it is restricted to those areas of the (capacity,traffic)
> space
> > where
> > > > the packet loss is in [0...7-8%] range (and AIMD is indeed
relevant)
> > since
> > > > out of this range timeouts start becoming the norm) then it is
> > > > *fairly*straightforward* to decide on AIMD parameters which
provide
> > specific
> > > > outcomes (wrt individual connection perfromance -within limits
> > obviously-
> > > > and wrt capacity utilisation).
> > > >
> > > > > > ..in their case they know pretty much that the links they
are
> using
> > are
> > > > in the
> > > > > > gigabit range and there are not many others using these
links at
> the
> > > > same time.
> > > > > >
> > > > >
> > > > > But what if there are loss, especially continuous loss during
the
> bulk
> > > > > data transfer? No matter how large the cwnd is initially, it
can
> > decrease
> > > > > to 1 during the transfer, then the problem arise again.
> > > >
> > > > drastic measures (timeout, exponential backoff etc) will always
need
> to
> > be
> > > > in place -
> > > > I 'm saying that (at least in the first attempt)  it pays being
> > optimistic
> > > > (this is the idea underlying slow start anyway..)-  and in
certain
> > > > environments indeed more optimistic than the standard prescribes
> since
> > there
> > > > is a-priori knowledge of the network path characteristics and
even
> > traffic
> > > > conditions - which is the case when considering OCxx links
> connecting
> > > > particle physics laboratories.
> > > > this approach seems to me a lot simpler and (most likely)
equally
> > effective
> > > > compared to elaborate control schemes which try to do better
while
> > trying
> > > > hard to remain "friendly" at the same time.
> > > >
> > > > Panos
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
>
> --------------------------------------------
> Academia: Academia was a public garden near
> Athens where Plato lectured his pupils. The
> school became known as the Academy and the
> teachers and pupils as academics.
>
> tel: +44 (0)1223 519 166
> web: http://www.statslab.cam.ac.uk/~gr224
> --------------------------------------------