SAHARA First Winter Retreat 1618 January 2002

1
SAHARA First Winter Retreat16-18 January 2002

• Randy H. Katz, Anthony Joseph, Ion Stoica
• Computer Science Division
• Electrical Engineering and Computer Science
  Department
• University of California, Berkeley
• Berkeley, CA 94720-1776

2
Who is Here (Industry)

• ATT Research
• Yatin Chawathe
• Ericsson Research
• Per Johansson (VIF)
• Tony Johansson
• Martin Korling
• HRL
• Son Dao
• Keynote Systems
• Chris Overton
• Microsoft Research
• Venkat Padmanabhan
• Lili Qui
• Helen Wang
• Nokia/Univ. Helsinki
• Kimmo Raatikainen

• Nortel Networks
• Tal Lavian (PhD student)
• Ben Warren
• NTTDoCoMo
• Shoji Kurakake
• Takashi Suzuki (VIF)
• Siemens
• Markus Wischy
• Sprint ATL
• Chen-nee Chuah
• Bryan Lyles
• Timothy Roscoe (VIF)
• Stanford University
• Peter Danzig

Italics indicates Ph.D. from Berkeley VIFVisiting
Industrial Fellow
3
ATT Research

• Overall goals are good and relevant
• Range of student project broad and deep
• Who is defining the overall architecture of
  Sahara? A name is necessary!
• What is the nature of services able to be
  supported in this architecturewhat can and
  cannot be supported
• Service composition across independent service
  providers
• Roaming billing/not an exact service matchhow
  to deal with this
• Verification/self-verifable protocols interests
• Trace/monitor services across providers built in
  from day 1 similar to security issues as a first
  principles part of architecture (IETF group
  working the DoS attack traceback across service
  providers monitoring for multicast across
  service providers (e.g., Bill Fenner_at_ATT)
• Verifying SERVICES rather than protocolsprogress
  needed, hard problem!
• AON Comments identify basic services that will
  be providedhow different from underlying
  distributed hash table? What does it require for
  opt performance? What at the AON level, what at
  the underlying level like Tapestry? Security
  issues critical impediment against deployment!
• Negative feature interactionbe aware! Same
  mechanism for different servicessource of
  performance problems?
• Other detailed comments for the students!

4
Ericsson Research

• Methodology overlooked sometimesbut this time
  beginning with understanding the existing stuff
• Internet competence at Berkeley, companies like
  Ericsson understand mobile networks, e.g.,
  understand BGP for mobile industry
• Scope is HUGE! But that is OKrouting through
  services
• Scope of expertise is excellent but there is
  risktoo thinly spread
• AON
• Interesting, 7-10 years convergence between
  mobile data networks and Internet, AON is a kind
  of unifying concept practical yet fundamental in
  structure
• Testbed and emulation
• What are the use cases? What kind of results do
  you expect to obtain? Will they be relevant? Can
  your emulator study the interesting general
  environment? E.g., mobile networkindirection/anch
  or points could be hot spots in the
  networkopportunity as well as a problem! Impact
  for new emergent architecture when there are high
  traffic agents in the networkgood places to put
  other services like caches
• Adaptation as users go mobile
• Structure of fixed Internetdo same thing for
  mobile internet and comparetake opportunity
  lots of competance in Mobile architecture and do
  comparison

5
Ericsson Research (Per)

• The Sahara group represents a unique in-depth
  knowledge how the internet is structured today
  and is underway to define functionality that will
  be important to handle the heterogenous
  environment we expect further on in the emerging
  internet. For instance, overlay networking in
  different forms may help to bring structure in
  such environments and form/compose services with
  collaborating "owners". Perhaps can mobility be
  handled with an AON also for a wide area network
  (cellular) -- performance implications are of
  course very important here.
• Now, how much of these ideas will have impact on
  the emerging "mobile internet" (3G) -- how much
  of an "internet" is 3G really? Will the
  services/applications be a lot different form
  what we see in the Internet today and how
  different are the requirements posed on the 3G IP
  networks from requirements posed on the IP
  networks of the "fixed" Internet? What kind of
  traffic (characteristics etc.) will go in and out
  from the GGSNs of the core 3G networks. Will they
  be really large "sinks" in the future IP networks
  that are hard to distribute (node oriented)? How
  will it for instance affect CDNs? Where should
  the 3G services be placed? (in the mobile
  operator's "ISP cloud"? or is it a another party
  (ISP) providing this? combinations?
• I have spent quite a lot of time the last months
  to lobby for the Sahara project internally within
  Ericsson in order to understand where we have our
  receivers and where we can make a difference. The
  feedback i get is positive but not very concrete
  in terms of how Sahara ideas can be applied to
  3G.
• We have been looking at the ABC (WLAN/GPRS) work
  as one pretty concrete piece of work that we even
  implement on campus and can start doing some
  measurements on etc (the bottom-up type of work).
  However, it is not really within Ericssons "core"
  business in the same way as 3G (UMTS) is. I think
  it would be good if we got more involved in how
  the actual 3G networks will be architected and
  see where the competence in the sahara group can
  be applied. (something i have realized quite
  recently after discussions within the company) It
  seems as if surprisingly little work have been
  done in how the 3G networks shall fit into a
  larger internet context and here the good
  internet understanding in the sahara group may
  give a very good insight on upcoming issues.
• In order to do this we need to have a good
  understanding of the UMTS architecture and
  functionality in order to be able to start
  sketching on this map.
• Unfortunately i wish i had more of expertice on
  3G UMTS/GPRS than i have to be able to guide the
  project here but i'm trying to get up to speed (i
  spent two-three years very focused on bluetooth
  and ad-hoc networking). Perhaps your networking
  course could be a placeholder for this. At the
  same time as a more 3G oriented research is an
  opportunity it has also potential drawbacks in
  terms of prototyping since it is on more of
  proprietary grounds. However, if we reach good
  understanding on the "real" issues i think we can
  get the right equipment if needed.
• As i see it we have a two-front approach here 1)
  the ABC testbed to get concrete results in an
  combined UMTS(GPRS)/Internet environment. 2)
  Start to understand the UMTS architecture and its
  impact on the fixed internet (and vice-versa) for
  end-to-end services (still in a multiaccess
  environment).
• The latter would be in the form of an initial
  investigation to come up to speed.

6
HRL

• Overview good
• Need better coordination among student projects
• Need to define vertical applications to better
  understand horizontal architecture
• E.g., GM Smart Car applicationpossible
  collaboration
• Traveller service/maintenance service in mobile
  environment
• Top down as contrast to bottom up approach
• Mobile agent coordination standard
  FIPAnokia/ericsson/GM composition service
  standard
• Nice architecture
• Suggested applications
• Advantage/disadvantage of different approaches to
  overlay networks Tapestry vs. AON
• See better how these projects interact with each
  other
• Emulation testbedNEEDED! Good idea
• Source code for emulator as well as Overlay code
  would be good deliverables to industry
• Data broadcastingpossible collaboration with HRL
• Expand beyond core to mobile networking research

7
Keynote Systems

• Enthusiastic about scope of research
• Important problems
• Adaptive measurement problemlaunch monitors
  based on workload but there are costs and so have
  to coordinate how to do it
• Localized referred painlocus of the pain is not
  its source! Traceback, speed of recognition,
  limitation of false positivesfilter before
  notification
• Tools needed/best practicesaccumulation of
  experience or automation of what people actually
  do with tools
• Do brief internships in industryto see those
  best practices
• Dynamic content distribution is still an open
  problemelement to be addressed by OceanStore?
• Emulation must evolvereal or fake? Competiing
  teams? High-level scrutiny is essentialhigh
  level problemgeneral scepticism
• Look at the big problems! Change impact but most
  research is by its nature incrementalunderstandin
  g structures and explaining how things work is
  also important difficulty of publicationbut
  still important to make them known!
• Developing an infrastructure is very important!
  Dont get blocked behind industry proprietary
  approachestodays open protocols may not have
  ever been developedservice composition at early
  stage dont get limited/leverage/develop a
  reference architecture that is easy to uselow
  glamor but potentially high impact
• Auction-based pricing services hard to see, SLAs
  not negotiated based on technology but
  personalitiesdisconnect with industry, slow
  progress of industry adoption! Consider concrete
  financial and contractual modelinvolve MBAs in
  this?
• Feasibility success of embedding function in
  overlay networks
• Deploy in local UC Berkeley infrastructure

8
Microsoft Research (Helen)

• On peer-to-peer systems
• Convergence in face of large node insertions and
  deletions in peer-to-peer systems (e.g., AON,
  Tapestry) is an important property which
  determines the kind of applications they can
  support.
• For example, for AON to support seamless and
  efficient mobility, not only it needs to handle
  high volume of handoff requests, it also needs to
  ensure short handoff latency which requires quick
  trigger insertions (and maybe deletions for
  bandwidth saving) into the system. I got the
  impression that the throughput of AON is good,
  but it is unclear how quickly newly registered
  triggers can deliver data.
• I think AON is very neat. And I think it is not
  too late for AON to be renamed to "Indirection
  Overlay Network" - ION. And I think the idea of
  tuple space is very relevant to AON.
• On Auction-based resource allocation (Weidong and
  Matt)
• This is a really neat project which is an
  important mechanism for the Sahara architecture.
  The goals of the project, generality,
  application-level knowledge, adaptivity, and
  efficiency are really good goals.
• I mentioned during the talk that one concern is
  that one cannot predict how much resource she
  will get after bidding. Since auctioneers have
  lots of information like the current resource
  usage, and history of resource allocation
  requests, it may be possible for auctioneer to
  tell bidders how much resource she is likely
  getting with how many tokens.
• On The overlay policy protocol for BGP (Sharad)
• Sharad's project makes the keen observation on
  how current BGP policy specification causes BGP
  routing pathologies. Sharad's framework also
  seems quite practical for fixing the problem. I
  can see a number of future work in this area
• 1. policy specification language
• 2. policy conflict resolution (may be able to
  borrow some ideas from feature interaction work
  from telecom)
• 3. interworking with existing policies in the
  edge BGP routers
• 4. diagnose current policy conflicts in the
  existing BGP routers
• I really enjoyed the retreat, very interesting
  student projects! Would like to be invited again
  )

9
Microsoft Research (Venkat)

• AON
• Interesting project. I think it is a great idea
  for certain things. But I think it is important
  to clearly identify the specific
  scenarios/situations where AON is a win and why
  it is so. Although AON provides a general
  mechanism, I don't think it is a good fit for all
  cases.
• Mobility is a good example to illustrate this. I
  think AON is a good fit for mobile-to-mobile IP
  telephony because of the high degree of mobility
  and the mobility of both communication
  end-points. However, it may not be such a good
  fit for a server talking to a client that has a
  small but non-negligible probability of moving.
  Rather than paying the performance penalty of
  indirection at all times (as AON would force us
  to), it may be better to use an alternative
  approach (e.g., end-to-end migration) that
  invokes its expensive mechanism only if and when
  needed.
• At a conceptual level, the AON indirection layer
  is a good fit for multicast. However, an
  interesting research question is how efficient
  the resulting multicast distribution tree is
  given the constraints introduced by the choice of
  an identifier for a multicast group and the
  mapping of this identifier to specific node(s).
  Other application-level multicast schemes offer
  the flexibility of handcrafting an efficient
  distribution tree.
• One interesting question is whether AON can be
  used as a fallback mechanism for when the
  primary/default mechanisms for mobility, DNS,
  etc. fail rather than as the primary mechanism
  itself. This would enable us from the simplicity
  (and hence robustness) of AON without having to
  worry much about the potential performance
  penalty.
• SAHARA
• Again, it is an interesting project with
  ambitious goals. There is the potential of having
  a significant impact on industry as new service
  architectures (e.g., Microsoft's .NET) are rolled
  out over the next few years. In particular,
  research on the question of when/how cooperation
  among providers and the composition of services
  from heterogeneous providers make sense would be
  very valuable.
• One issue with the composition of higher layer
  services (e.g., text-to-speech conversion) from
  multiple providers is data privacy.
• I think research on network measurement, distance
  estimation, service placement and selection is
  very interesting. I think an effort to build a
  50 node distributed testbed with geographically
  and organizationally diverse coverage would be
  great. This is something that can be undertaken
  in collaboration with groups at other
  universities, labs, ISPs, etc.
• One the topic of network proximity measurement,
  it would be interesting to study the correlation
  between latency (which is easy to measure) and
  bandwidth or loss rate (which are harder to
  measure but may be more meaningful).

10
Microsoft Research (Lili)

• Comments on doing Internet-scale research at
  universities
• I think it's a great idea of setting up a
  measurement infrastructure available to
  researchers, as proposed in the panel discussion.
  Some of the issues we may need to consider are
  (i) where to place measurement points in order to
  make the measurement results representative (ii)
  what kind of resource sharing policy to be used,
  and how to enforce them. It is conceivable that
  once such infrastructure is ready, many
  researchers from universities and industry want
  to use it. Some kind of coordination and policing
  will be necessary. I talked to Vern Paxson about
  NIMI a few months ago. He mentioned that a major
  obstacle that prevents NIMI measurement
  infrastructure from being available for outside
  researchers to set up their own experiments is
  the resource sharing issues. (iii) developing
  techniques to collect/infer more information from
  a limited number of measurement points is also
  worth looking at (iv) while real data are always
  valabable, simulation offers opportunity for more
  comphensive study of the system. Even with rich
  measurement data available, it would still be
  useful to use simulation to study the system
  under wide range of target environments and look
  at the sensitivity of the system with respect to
  the environment change.
• Comments on AON
• It's a very interesting idea to use a level of
  indirection to enable interesting
  functionarities. Some of questions occurred to
  me (i) how many AON nodes to be deployed to get
  reasonable performance? where to deploy these
  nodes? (ii) AON seems to give a general framework
  to provide mobility, server selection, etc. How
  would it compare to the techniques that are
  specifically designed for solving a particular
  problem. How about its scalability? Does
  generality of the system makes it more
  challenging to scale?
• Comments on Sahara
• There are lots of interesting components in
  Sahara project. I'm glad that I had the
  opportunity to closely interact with students in
  Sahara project during the poster session, and
  give them my feedback in person.
• Comments on Tapestry
• It's a very interesting system. On the other
  hand, given several other competitive p2p
  schemes, such as CAN, Chord, and Pastry, it might
  be even more interesting to look at optimization
  techniques (such as attenuated bloom filters and
  dynamic management algorithm discussed today, as
  well as future optimizations) to p2p system in
  general (not specific to Tapestry). In that way,
  the impact of research results will be bigger. Of
  course, it's possible that not all optimizations
  are applicable to all system, but identifying the
  techniques in which all p2p systems could benefit
  from would be really useful.
• General comments
• It's very nice to see quite a few projects on
  routing and BGP, a fundamental area but not very
  well understood.
• I'd like to see more projects in network
  security.

11
Nokia Research/U Helsinki

• The project is on sound basis
• Trust management is important for dynamic
  federations
• end-users trust in visited domain is widely
  overlooked
• Perhaps a little bit more focus on the usage
  scenarios
• also other than content delivery
• many users will be mobile
• Internet in your pocket
• Expected communication characteristics
• Human interactions
• Messaging (async non real-time also
  uploading!)
• Interactive content retrieval (almost real-time)
• Rich call (voice attachments)
• At least two-party interactive games
• M2M applications
• Control and command (delay bound lt 1 sec
  payload 10-10k octets)
• Management (delay bound a few secs)

12
Wireless World Research Forumhttp//www.wireless-
world-research.org
Context
Devices, Communication and End Systems
13
Nortel Networks

• 6-10 year perspective, but what are we going to
  deliver in 2-3 years (Ben Warren)
• What is the elephant story? Different
  angleswhat are our individual views? Write down
  and compare notes?
• Posters
• Great this time BGP and Overlay networks newer
  concepts shown in the posters
• Industrial partner mix is good
• Other vendors Cisco? Lucent? Their directions
  and points of view
• Other customers RBOCs/Pacific Bell/Verizon
• Optical networkinghow does it change the
  fundamentals of networking? Implications for
  application of the technology in future networks
• Focus on physical layer need more insights on
  implications for the higher levels e.g., QoS,
  why multicast?
• HW for Nortel technology point of view and
  present it in this context

14
NTTDoCoMo

• General Comments
• 3G in Japan NOWnext step all IP-networks!
  Including voice, and it is an unsolved problem
  (as well as other real-time applicationsmajor
  source of revenue)
• Effectiveness/performance essential for these
  applicationsneeds study IETF Mobile IP meets
  QoSlayer 2 triggers to manage mobilityideas
  appropriate for organizing mobility in overlay
  networks?
• 3G no longer next generation network research
  for 2010 or beyond, no dominant network, combine
  WLAN, data over cellularhow to do this,
  heterogeneous access serviceshow to make service
  composition work
• Access to service different across different
  access networks to different access
  devicessingle logical serviceoperator service
  platform needed not specific serviceslatter come
  from service providers, operator understands the
  user preference, location, etc.
• Proxies service composition to provide adapted
  service for operators subscribercontent
  provider does not know details of user/user
  preference/user access device/etc.
• The operator is the composer, presents common
  service
• Who is responsible for the services
  quailtytools needed to control/measure/trace
  failure/assure good service provisioning to its
  customers
• Next target heterogeneous access
  networkssimultaneous MM situation multiaccess
  terminals use several networks at the same
  timehow best to use? E.g., reliability
  issuescertain important streams carries over one
  network, less critical information over another,
  like control versus loss tolerant data
• Dynamic handovers among network sets is of
  interest
• AON supporting mobility and naming problem
  importantMobile IP does not solve the
  multinetwork problem!

15
Siemens

• Wide-area sim testbed important tooladjust
  model and verify the models for good methodology
• APIs? Not protocols?
• More work needed on service description and
  service verification, important to enable
  composition
• AON how does the name space really get used for
  useful services and functions in the network!
• End-devices, what are their properties high
  latency/unavailable network/mult-network
  accesshow to keep everything connected
• Management
• Overview and posters
• Preparation material beforehandlike AON

16
Sprint ATL

• Write your service specification! Applies to
  various projects explicit as well as what is
  explicitly NOT part of the service. Define the
  service
• Simplicity at expense of what? Slight
  complexity can have advantages elsewherewhere is
  the cost pushed and what is it?
• Composition/verification important! Go to it!
  Push complexity into the core to enable
  verification, then do it!
• Overlay network know what problem you are trying
  to solve insures relevance to network
  operatorsevolving Tier 1
• Sprint looks for longer term perspective in
  Universitiesdont get too focused!

17
Sprint ATL

• Overarching architecturewho is working on this?
  What are Saharas technical goals?
• Create a new architecture to replace the existing
  one?
• Put clothes on the work of existing projects? Not
  necessary to do this
• Other ways to look at Sahara/common threads
• Internetworking of connectivityHow the internet
  works now
• Resource Allocation
• Overlay networks/service composition
• Goal? Explore this as a design space?
• Identify requirements for new distributed
  architecturethrough away todays internet and
  replace with something better/different
• Suggestion Sahara own paneltechnical/operator
  experts to educate the students on what is
  actually happening in real networks
• Emulation value in doing itstress
  test/parametric studieseven operators dont
  always allow this for internal researchers to do
  Internet-scale experiments
• What is the realistic scenario? Realistic traffic
  generatorSprint could helpflow
  generators/routing dumps/route flaps/convergence
  turn dumps into generators (Univ of
  Saarbrucken)

18
Sprint ATL

• High level tension in the retreatdistributed
  systems vs. networking not many that span the
  two areasbut no explicit effort to combine
  these dense! Hardwork! Lots of things to
  presentless informal interaction
• AON/Tapestry combined as single session?
• Concrete stories needed to tackle what is a
  service? User experience/which provider
  involved?
• Internet-scale research particularly from
  University
• Hidden assumption to be valid it must be
  deployablebut is this really the case? Not
  historically true! New things not immediately
  deployable in existing system! Can sometimes
  limits the scope of undertaken researchinterestin
  g research area in this on its ownsuppose there
  was a new thinghow to evolve the world into this
  directionIPv6 transition offers a (not very
  good) modelincremental tweaks to BGP to add new
  features unlikely to be adoptedwhat is a
  radically better way to do it

19
Sprint ATL

• Internet-scale research particularly from
  University
• Hidden assumption to be valid it must be
  deployablebut is this really the case? Not
  historically true! New things not immediately
  deployable in existing system! Can sometimes
  limits the scope of undertaken researchinterestin
  g research area in this on its ownsuppose there
  was a new thinghow to evolve the world into this
  directionIPv6 transition offers a (not very
  good) modelincremental tweaks to BGP to add new
  features unlikely to be adoptedwhat is a
  radically better way to do it
• What are the systems problems in evolving the
  architecturecohaptating with the old, restricted
  systemgeneral approach to evolving composible
  services

20
Stanford University

• Among the research issues, I think how to compose
  services is a very important research problem
  because of the services heterogeneity and
  diversity. From the discussions with students I
  feel that it has been a little considered yet. I
  think the architecture might require a general
  framework for service composition. This thought
  leads me to several questions.
• How does the sahara compose services? Will the
  sahara use type system, semantic information,
  policy, trust, reputation, and performance
  metrics?
• What are (concrete) target service compositions?
• Which services are statically composed? In what
  extent can services be composed dynamically (in a
  short-time scale)?
• The research on the Internet indirection layer is
  especially interesting to me. I am excited about
  the idea of making the indirection layer over IP
  instead of building independent application-layer
  services. I think it is helpful, for clear
  understanding, to explain additional
  functionalities used with the indirection layer
  depending on target services. For example, a
  large-scale publish-subscribe system may require
  a scalable lookup service like chord. However,
  the lookup service may not be necessary for a
  small number of hosts in video conferencing. As a
  side note, I think that anonymity is also an
  example service that can be supported by the
  indirection layer.
• The investigations on the Internet topologies and
  geographic information in the project are
  interesting. I expect to see how much performance
  gain can be achieved by applying the information
  to the current Internet systems or to use the
  information to create new applications.
• I heard that the NTT Docomo is planning to use
  Mobile IPv6 for mobility management in 4G
  networks. I am curious about other mobile phone
  companies plans. If Mobile IPv6 is considered
  mainly in the companies, I think its necessary
  to check the values of the NAT-based mobility
  support in the Always-Best-Connected-Service.
• Among the posters, there were auction-based
  resource allocation and congestion-based pricing.
  I think it may be interesting to combine those
  two schemes. For example, the base price of an
  auction can be set to the price that is
  determined by congestion-based pricing. I am
  curious about the effects of congestions-based
  pricing on the performance of the auction-based
  resource allocation and vice versa.

21
Peter Danzig

• Sahara/composible middleware servicesICAP embed
  other vendor services in the middle of Akamais
  service
• We need a service definition architecture,
  network emulator, composing serviceswrite lots
  of code, Harvest project led to 20 companies
• CDNs voice over IP gateways as well as Content
  distributionbut control architecture they
  developed unpublished! Architecture for managing
  this with available service codeuse the
  emulator, relevant to the panel discussiona real
  composed service, with changes being made, how to
  do itexciting project! But this is hard!
• CIO Omnisky200 users/customer service rep to set
  up POP service! Mail is a servicebut hard to
  make usable
• AON Tibco like? Within individual organization,
  not as global internet servicescalable
  infrastructure for wide-area enterprise
  environmentcan finesse some hard problems like
  security
• BGP overlaycore problem 5 companies/measurement-
  based approachindustry current
  solutionresearchers looking longer term
• CDNsdynamic delivery for CDNs very hard like
  composible services, dynamic content assembly NOT
  solvedscale issues, what to do when things break