RE: Group B comments (was Re: Poke Poke...)

From: Elwyn Davies (elwynd@nortelnetworks.com)
Date: Mon Mar 04 2002 - 13:29:45 EST


Hi.

Observe that the piece on control theory is in a section labelled 'Open
Issues'. This section is intended to remind people that there may be
alternative answers and that the authors of the group B draft do not claim
to know what all the solutions are! ...and of course this is *requirements*
so no solutions mandated as yet... The question should be 'If we had a
control theory type solution or something else off the wall, do we get any
interesting insights into the requirements?'

I agree with Howard that it would be helpful to keep comments about the two
drafts in separate threads, with possibly a third for comparative work.

The Group B drafts can be had from (and they are already up on the IETF I-D
directory):

http://www.cdt.luth.se/babylon/drafts/draft-irtf-routing-reqs-groupb-00.txt

http://www.cdt.luth.se/babylon/drafts/draft-irtf-routing-history-00.txt

Word versions can also be found in the same directory:

http://www.cdt.luth.se/babylon/drafts/draft-irtf-routing-reqs-groupb-00.doc

http://www.cdt.luth.se/babylon/drafts/draft-irtf-routing-history-00.doc

Regards,
Elwyn Davies (co-editor of Group B docs).

> -----Original Message-----
> From: Howard C. Berkowitz [mailto:hcb@gettcomm.com]
> Sent: 04 March 2002 18:06
> To: Lloyd Wood; Tom Scott
> Cc: irtf-rr@puck.nether.net; babylon@sm.luth.se
> Subject: Group B comments (was Re: Poke Poke...)
>
>
> Speaking as a coauthor of the Group B document, it's going to get
> extremely confusing if we get individual comments in a thread that
> started out referring to Group A. Our drafts should appear in the
> I-D archive in the next couple of days; it was sent in on Friday.
>
>
> At 11:43 AM -0500 3/4/02, Lloyd Wood wrote:
> >On Mon, 4 Mar 2002, Tom Scott wrote:
> >
> >> was typo. this url works:
> >> http://partner.unispherenetworks.com/rrg/
> >>
> >> Regarding Group B, I'd like to draw attention to section 10.9:
> >>
> >> Is it possible to apply a control theory framework,
> and analyze the
> >> stability of the control system of the whole network
> domain, for e.g.
> >> convergence speed and the frequency response, and then use the
> >> results from that analysis to set the timers and other protocol
> >> parameters.
> >>
> >> Control theory could also play a part is QoS Routing,
> by modifying
> >> current link state protocols with link costs dependent on load.
> >> Control theory is used to increase the stability of
> such systems.
> >>
> >> At best, it might be possible to construct a new
> totally dynamical
> >> routing protocol solely on a control theoretic basis
> as opposed to
> >> the current protocols which are based in graph theory
> and static in
> >> nature.
>
> One of my coauthors wrote that particular section, so I don't want to
> second-guess him. But I'd be awfully hesitant to say that ANY
> approach is "the solution" until we have a consensus on the
> requirements.
>
> > >
> > > Solution is ASM model:
>
>
>
> > >
> >> http://www.eecs.umich.edu/gasm
> >
> >Is this related to Dina Katabi's congestion control work in her
> >thesis?
> >
> >http://ana.lcs.mit.edu/dina/dkpub.html
> >
> >Good stuff, but imo the main problem with applying control theory
> >widely in the Internet is that traditional control theory isn't very
> >good at being subverted and having the things it is using as control
> >inputs _lie_ for their own ends. So, if you have state concerning
> >utilisation in the routers (and state is expensive) tracking this -
> >can you trust that state? It's always cheaper not to store the state
> >and just make up a convenient lie on the spot.
> >
> >The problem with applying the abstract state machine model to the
> >network is that you've really got a whole bunch of machines which
> >don't (can't!) trust each other. (also why many bright-eyed ideas to
> >load more information onto BGP data between ASs are doomed to
> >failure...)
> >
> >The other problem is that you have to fall back to TCP congestion, as
> >Dina's PCP does, to preserve the current anti-congestion collapse
> >status quo.
> >
> >OTOH, right now we're simply trusting all endhosts to implement given
> >heuristics effectively, which is equally flawed (Savage
> >exploits, DOS attacks etc.)
> >
> >L.
> >
> >sure, it's possible. But is it useful?
> >
> ><L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>
>
>



This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:03 EDT