1st retreat: feedback discussion

Neal Cardwell (cardwell@cs.washington.edu)
Wed, 1 Jul 1998 16:28:02 -0700 (PDT)

some notes i took from today's discussion of the feedback at the retreat
(please send out corrections if i misinterpreted stuff or left something
out):

Routing measurements (traceroutes)
----------------------------------
- they liked the measurements
- to do:
- where are the drops? the NAPs?
- plot how loss rate and delay variance accumulates as you hop along a
path
- are better (faster, less lossy) paths correlated with AS Path Length?
- are faster paths also less lossy?
- can we identify which routing pathologies are causing particular
problems?
- ex: early exit

Using aggregate info to inform congestion control
&
TCP Hacks
--------------------------------------------------
- they liked using aggregate info to inform congestion control
- especially if it's info you clearly can't get e2e

- they didn't like our TCP hacks, b/c, they say
- old fixes just implemented at the edge is not research
- if you could do it at the end host, you ought to
- to keep complexity out of the middle of the net
- it's dangerous to break semantics
- it's scary to go faster when congestion is already a problem

- issues:
- as # end hosts grows exponentially, most end hosts are new
- deployment is easier
- if app-specific tansport protocols come into use (webTP), tricking
TCP is not the issue any more
- is it research to look at just moving stuff to the edges? probably, if
- that's the future
- we may discover something new by actually building it

- transmog helps w/ management
- end host (which you could get with other management fixes)
- but also network routing and shaping issues

- the duality of
1) sending centrally-gathered info to end hosts so that they can make
their own decisions (SPAND)
vs.
2) using centrally-gathered info to control traffic as it passes through
a central point (Transmogrification)

- to some extent, the only difference is
- scheme (1) explicitly gives info to end hosts
- scheme (2) implicitly gives info to hosts (drops, etc.)

- but if you view this purely as an issue of disseminating info, you miss
that:
- TCP may not do the right thing with the info
- you may still have to enforce the right thing, since you may not trust
all TCPs sending through you
- the control loop may be too loose

Future Traffic Types
--------------------
- we need to pay attention to them
- Stefan will send pointers to papers on inelastic flows

Pings
-----
- Hillary mentioned that pings to end hosts have cyclic results on the
order of seconds
- maybe due to TCP synchronization from loss storms (from short flows?)?

Routing
-------
- what's our story?
- are tunnels the way it oughta be?
- are tunnels a value-added service that will be there?
- are tunnels a validation that there is a problem with routing, and that
it could be better-designed?

- McCanne's point: we can do complicated stuff to try to optimize because
if it breaks we can always failover to the real net

- our routing work can be useful for people designing VPNs, but we don't
need to specifically target this

- conclusion(?):
- we should demonstrate that routing is very suboptimal, and say "here
are some ideas that could help inform the deployment of the next internet
routing system"

- to demonstrate the validity of the ideas, we need traffic on our
virtual net, and to do this we need lotsa folks using it

XBONE
-----
- we need racks of PCs at many well-connected universities in order to
carry out experiments involving wide area networks
- ABONE ain't happenin
- need a new multi-university effort
- big problem: SW to manage the distributed clusters

Alternaticve deployment scheme
------------------------------
- suggested by Corbato
- use our measurement results as input to a tool that automates BGP
tweaking

Cooperation
-----------
- we need to cooperate with the web cache group
- joint detour/web cache box deployment
- topology generation
- workload generation
- UW traces
- synthetic traces

Simulation
----------
- get Nicol's monster simulator