AT&T LABS
Fred Douglis
 

• First, thanks for having me again. It was, as usual, an interesting and rewarding experience, not to mention a good time.
• Now, comments: On the positive side, I've seen a lot of progress since last year, and I think the projects are on the whole doing quite well. I paid the most attention to ninja, and thought the infrastructure such as the distributed data structures Steve described were quite promising. I really enjoyed the breakout session on proxy services for untrusted end stations. If this had been in AT&T, we'd probably be getting ready to apply for a couple of patents on what was discussed (and maybe the parties involved should .... my corporate hat speaks). The idea of how to use a trusted PDA in conjunction with a kiosk, for instance to download an encrypted email digest, seems novel (but isn't my area so I won't swear to it).
• "Constructive criticism": I believe last year I may have made a comment about this; in any case, it certainly applies now. I have found a general tendency to ignore related work -- very few talks ever mentioned what was novel relative to previous projects. Occasionally the speakers would be challenged, e.g. for indirect TCP. Don't succumb to NIH.
• The relationship between the two paths projects was muddled. I still don't buy why there are two, and since they were presented as "fault tolerant paths" followed by "paths" in general, it seemed like the cart was before the horse until the speakers of the second talk spoke about iceberg versus ninja as the distionction - something that I don't quite follow or fully buy.
• I think some of the projects have a tendency toward speculative complexity: doing something more complex in the hopes it will show benefits later. Ben's treaps are an example of this, I think. Time may tell.
• Regarding Jimmy's talk on building a H.323 user base, I think you will have more luck if you can get it picked up for incoming calls rather than outgoing calls. But now, if people need to dial an 800 number and then specify a user, they have to go through extra hoops and may not buy in. Plus you need services like call forwarding, answering systems, and so on, if you don't already (unclear). I am certainly skeptical about the ability to have lots of users in a common terminal room using the phone on a regular basis. How many home users are there who could take advantage of this?

• Focus shifting away from protocols towards Internet Service Platform
• No roadmap of where we go next
• Need to prove scalability of the architecture
• No single standard: attribute of the architecture has to be heterogeneous
• Device classification scheme architecture that supports classes with interoperability
• DC: Services company? Comm stack, open architecture, who develops apps for the vehicle of the future?
• Services vs. platform vs. end-to-end control of the customer
• Car is a challenging environment

ERICSSON
Stephan Bauke
Rolf Leidhammer
Gunnar Nilsson
Kourosh Pahlavan

• Start of new lab in Berkeley-overlap with some research projects especially in the wide area
• Next research: better preparation in advance for industrial participants-materials in advance, perhaps helping focus relevant industrial presentations
• Would lead to better comments in context

HRL
Son Dao

• Good Ideas. Two overview talks on Ninja and Iceberg are very good ideas. It allows people to understand the goal of the project, high level architecture, and technical focus areas of the project.
• Secure infrastructure is a very important research area. I hope that this area will be extended more in the future.
• Always impressed with students' presentations

• Lots of potential synergy with IBM efforts
• Initiate joint work
• Think through the elevator talks-why are you doing what you are doing; useful for posters and all talks; What are you doing, Why are you doing it, How is it different
• Simplifying assumptions arose many times-do these turn out to be true? Do they really simplify the implementation or speed up the performance of the system.
• PAC talk: privacy issues embedded-Tracker vs. Coordinator; what is our strategy with request to privacy?
• Service Platform session: Focus on call service, think more broadly, use specific examples beyond phone call model
• Technical issues: event models, events are being used, two different approaches-Gribble, distributed I/O, FSM, plus separate group on event model in distributed environment;
• What is really happening in Ninja Version 2? What is the road map through the versions? What are the incremental steps?
• What is a service-still unclear to Michelle. What kind of services are we trying to compose, connection with Path Compilation?
• Security issue critical; hard to make comments about this unless very knowledgeable, maybe tutorial on this topic specifically would be value
• Data structure area: how they relate to proxies, gateway, Ninja, Telegraph, etc. Hard to pull together in a common vision of research strategy for this area. Tradeoffs in data flow, service composition,
• What is the unification of telecomm/ninja-why are services any different; hard to see the difference, top vs. bottom-up, local vs. wide-area focus.

• Metrics needed. Numeric metrics easy. Hard to measure success in apps: what are we trying to accomplish
• Missing piece:
• Airport scenario-gate info on the move walking thru airport
• "Which gate?" "Gate 31"
• understands context, where you are, what you are about to do-minimizing the number of clicks to get the info you are likely to want and need
• Leverages PAC concept, user interface issues
• Buy tickets, enters calendar as event, triggers other events (see also: "this is an airport relevant event")
• Generates additional context proactively-how is this captured as a service
• Useful in other than mobile environment-like portals
• Overall architecture well suited to support services like this
• Service creation for proactive services of this kind to support "intelligent" "context aware" applications
• A focus of Intel pervasive computing investigations

• Good topics presented - professional slides
• Overviews useful
• Slides WILL BE PUT ON THE WEB - with elevator talk summaries
• Overview talks done at participating labs? Useful for a wider community
• Open houses would be useful to reach larger group
• Preference registry needs UI work, but great idea
• Visual browsing of preferences modify interactively would be useful
• Consistency checking among rules
• Clearing house is great-billing work needs research attention
• CHs communications bottleneck? Does this scale particularly in terms of communications traffic? Call statistics, aggregation possible?
• Mobile/Wireless-Wide area Internet scale: support for mobility
• Protocol work: identify by name not address

• Do some background studies before making assumpltion
• What is important, what needs to change, what needs to happen
• What are your trend assumptions, what is the future environment, in what way will you have impact on the industrial landscape of that time
• PDA can?t support secure sockets-but it will in the near future
• Industry moving forward on standards efforts-need to understand this to have influence-can?t reinvent the world

NORTEL
Tal Lavian
 

• Second visit-lots of progress and more people
• Mix of industry and Berkeley, company interest
• Leverage industry capabilities, insertion of new technology for Berkeley group, flow of new ideas the other way
• Lot?s of potential synergy with Industry
• Collaboration-influence product plans
• Proposals:
• Summer students to work and influence activities in industry/part time job/pursue PhD during school year
• Programmable networks: source code at Berkeley, let students play with it, immediate feedback to industry sponsors
• "Expensive" devices given to research groups to experiment with-cost doesn?t matter given the value of having the experimentation
• Tutorials valuable!
• Nortel focus: Services, Scalability; new explorations very valuable for the company
• Good relationship between programs, leverage each other, don?t need to reinvent the wheel, few places do this-PhD students start from scratch
• Poster session valuable!

PHILIPS
Janna Chang
Erik Ekkel
 

• Understand the projects here, utility for Philips
• Agenda on line not very useful, need more details in advance
• Posters and tutorials very useful in learning about projects
• End devices should include consumer products like set-top boxes, digital recorders-how will the network support these? Incorporate into our experimental environment
• Student presentations: more examples would lead to better understanding
• Emphasis scalability-end points as well as servers
• Affordability as a metric-reuse existing software and elements of the end-to-end system
• Business model thinking: effect on the architecture-e.g., Clearing House, HP?s business model for services, how does this affect our evolving work
• Project plan for next six months-not covered!
• Smart TV, living room space as new access environment
• WebTV-properitery platform, moving away from closed systems, so there is an opportunity

• Large progress since last retreat
• Intellectually stimulated
• CH, Simulation comments
• Bring Internet to telecomm world-CH is just like old style telecomm view! Hierarchical structure, large-scale making decisions, similar work to Tenet group but done distributed in that project
• Why introduce a new hierarchy? Similar to hierarchical OSPF routing, border router concept, interdomain routing via BGP-why not extend these?
• Reservations-made ahead of time based on Internet "weather". Who will pay? Other work on network weather at UCSD-probes throughout the network
• Split CH into three separate systems or components
• Weather/Routing/Reservations
• Simulations: handful of students planned for simulations, simulations as a goal, see more of this, buttress scalability claims, wide-area data collection difficult

• Wide-area case realization interesting to see-fundamentally different from the local case!
• Local case well covered-but not everyone understands the wide-area challenge: heterogeneous, no global architecture, interfacing with other architectures, no global control
• Still need for organizational relationships for ninja/iceberg deployment-implicit relationships already there? Needs to be more clear
• Security model: needed for Ninja!
• Protocol-Distributed Systems-UI: where are the results of this integration? Where is the OS? Resource control in Ninja-a blind spot? Inside or outside the Ninja scope?
• Uninformed comments about SS-7: better understand how this works, how it does composable services; TINA is another scheme: OO-oriented service architecture for telephony; needed to convince phone company folks this is the way to go
• Mantra: Build it and break it-think through the limitations, vulnerabilities
• SS-7: make use of Berkeley expertise in this area (?)
• End-to-end argument: used to knock down proposals, Internet not currently end-to-end! Iceberg services are not end-to-end; defend the decisions/architecture.
• Important service to Internet community by leading this discussion.
• Scaling arguments: look at arguments with critical eye
• IntServ for example:
• Kbyte of info per connection-but this is NOT a big deal at the core of the network: revisit assumptions!
• Arguments often driven by 5 year old limits rather than 5 year out viewpoint-be explicit about technology assumptions
• Brute force things can solve these problems
• CH-think carefully between IP routing and the CH, QoS routing literature, State in the net: moral equivalent of the Virtual Circuit, need to understand SS7, MPLS, BGP, IGP, etc. ISP basics on routing, hot potato routing
• Initial security steps-but have work to do
• Formal descriptions can be short if done well
• Need to do more of this
• Easier to convince people that you are right
• Presentations on a single PC
• Overlap here and ATL, hiring and summer opportunities!

• Galactic scope
• Pitfall: your piece inherits galactic scope; need to understand where you are placing your bets
• Focus on high leverage!
• System without billing that makes it possible to add billing later
• What have other people done before, put together in new and interesting ways
• Compelling voice/computer integration services needed!
• APC: wide-area hard problem-Prefs, spreading, path creation, personal mobility, pressing issues-should be worked on.

• Many of the example scenarios involve phone calls between a sender and receiver. Iceberg is flexible enough to allow for the sender and receiver to negotiate on how a particular realtime communication flow between them will look. This negotiation would be similar to the IPIP protocol the IETF has designed, which allows for negotiation of multimedia characterstics between two parties. The negotiation I'm looking for doesn't have to be done explicitly by the sender and receiver, but could be done by their respective Personal Activity Coordinators (PACs). An example scenario like this would be nice to see in the future.
• One of the things that the Universal Inbox and the Mobile People Project have in common is that they both aim to give the receiver control over how he receives his communication. I think a nice extension would be to allow the _sender_ to have some say in how the receiver receives a particular communication. There are circumstances where the sender does not want his communication to reach the receiver unless it is in a particular format. Iceberg is flexible enough to allow for a Universal Inbox/Outbox that enables both receiver and sender control.
• APC
  There was a lot of discussion on how to perform APC in the wide-area. Yes, it is a big challenge. However, I would argue that solving this problem in the local case is still very difficult and more pressing a challenge to address. By local, I mean we assume all operators, user preferences, and dynamic user information are kept in one well-known place. Depending on how complex the user preferences are (especially if we allow for the features I described above), automatic path creation in the local case is a nontrivial problem. I think this should be looked at carefully before addressing the wide-area problem.

USC/ISI
Lew Girod