Where to control [was Re: [e2e] TCP in outer space]

[Jon Crowcroft]

actually, given the way the core nets are going faster, faster than
moores law (see sprint core net stats for example) and given the
nature of the internet traffic matrix (flash crowds are the norm,
nearly)
it seems to me that the typical congestion point is the inbound
interface on an egress (or interprovider) router, but that it wont
have the processing power to do any more than drop (not even  ECN mark
as it wil lbe a hop earlier the mark should have happened) - 

application level traffic engineering is a part of our active nets
project (we call "application level" it active nets to get research 
funding, but its really distributed applications with a bit of
performance management built in...see our iwan paper (
ftp://cs.ucl.ac.uk/darpa/iwan.ps.gz
for some details)

the basic idea is to generalize overlays and application level munging
in one fell swoop - we presented a bit of it in the context of
beep/apex at the minneapolis Ietf.....but it was regarded as a little
too early (not a lot tho...)

meantime, a note from the past:
when we were testing the TCP RTT estiamtor and congestion control 
on the  satnet (in about '87), i had one day when i was getting really
bad goodput - a colleague who is also a physics/astronomer pointed out
the window of our shared office at the thundercoulds and lightening
and said - "are you running FEC on the  link layer?" - we werent at
that point (BBN had disabled it for some other experiments).....so the
effective average BER was probably about 10^-3 (10^-5 is norm, and with
FEC, more like 10^-7) 

an offline discussion with van elicted the explanation of the
sensitivity of the cwnd adjustment algorithm to actual bit rot - 
but note its only sensitive in _extreme_ like this - once FEC was on
then the loss of thruput due to real loss is negliegable - i.e. the
false stalls you incur are not so bad.....

the point is that this is part of experimental experience that led
people to consider the problem as largely not a key one for prinme
time just yet and its only now that wide area wireless is becoming
so large on everyone's horizon that we are revisiting it (well ,that
and the absolutely massive bandwidtsome grid folks are deploying 
which expose single TCP connectiosn to a residual packet error rate per RTT
which is going to occasionally stall things, but then we have SACK TCP
deployed and its easy to rig that to do the right thing

on the rtopic of _real_ interplanetary IP/TCP (as opposed to just orbit)
i beleive the applcatio nlevel overlay (e.g. from earth to earth
orbit, thence to lunar, then areostationary (for mars) and possibly
later with solar "polar" orbit satellites is the only way to go
because not only do you get burst noise that outlasts several TCP
connection lifetimes, but you also get some RTT and bandwidth
variation that operates on these sorts of timescales, so end2end
 feedback control is not really a viable model

(note for example that the RTT of a spaceship swining by venus to get
to mars _varies by a huge amont within one RTT so the estimators make
no sense at all - you need to run predictors based on the planned
route of the vehicle, plus you need to have much more macroscopic
repair mechanisms (e.g. whole file recovery with the recovery
algorithms in the file is being discussed in the research group)...

think apollo 13 ^ 10 being perpetrated on your packets:-)
In message <3AD92E56.7CF014EC at attglobal.net>, Cannara typed:

 >>Steven, I agree 100% and a number of folks have talked about application-level
 >>control via network-level feedback, as you mention.
 >>
 >>Alex
 >>
 >>
 >>Steven Low wrote:
 >>> 
 >>> Alex
 >>> 
 >>> While I agree that routers should do more to help contorl congestion,
 >>> I believe they should *not* determine source rate, as done
 >>> in ABR Explicit Rate.   Rather, a router should figure out the right
 >>> measure of congestion and feed back this information to sources that
 >>> use this router.   A source, knowing the congestion information
 >>> on its *path*, is in a better position to determine its rate.   A
 >>> potential bonus of this approach is that
 >>> sources with different valuation of bandwidth can adjust
 >>> their rates differently even when the congestion on their paths is
 >>> "identical".   For example, they can choose utility functions that
 >>> are tailored to their applications, and use that to adjust their
 >>> rates.   In summary, a router only knows how congested it is,
 >>> and this is what it should inform the source about.   This is
 >>> necessary and sufficient for a source to figure out its rate.
 >>> 
 >>> All these can be made precise, and it can be shown that
 >>> this approach can be made optimal, stable, and robust as network
 >>> scales up *arbitrarily* in delay, capacity and load.
 >>> 
 >>> Steven
 >>> 
 >>> > The point is that router/switch code can do far more these days than ever
 >>> > imagined when the decision to offload performance and capacity decisions from
 >>> > 'gateways' (routers) was made years ago.  The corollary is that this is not a
 >>> > surprising reality.  So, for example, rather than simply using the hardware
 >>> > RED capability now available to drop packets, use it to generate a more
 >>> > intelligent control statement to the sender.  Source Quench and its original
 >>> > purposes have been discussed, but consider that intelligent folks might even
 >>> > go further -- let a little of this processor-cycle wealth be directed at the
 >>> > network-layer without tricking the assumed transport, which is not the source
 >>> > of all the traffic.  This is, of course being discussed.
 >>> 
 >>> __________________________________________________________________
 >>> Steven Low, Assoc Prof of CS & EE
 >>> slow at caltech.edu                        netlab.caltech.edu
 >>> Tel: (626) 395-6767                     Caltech MC256-80
 >>> Fax: (626) 792-4257                     Pasadena CA 91125

 cheers

   jon