MINUTES FOR MARCH 31, 1998 IAB BUSINESS MEETING

PRESENT:

Fred Baker

Steve Bellovin

Brian Carpenter

Jon Crowcroft

Steve Deering

Robert Elz

Ned Freed

Tony Hain

Don Heath

Tim Howes

Erik Huizer

Cyndi Jung

John Klensin

Keith Moore

Robert Moskowitz

Charlie Perkins

Radia Perlman

Jon Postel

Abel Weinrib

NEXT MEETING:

Teleconference Tuesday May 12, 10-12 Eastern Time.

ACTION ITEMS:

NEW ACTION ITEMS:

• Charlie Perkins and Bob Moskowitz: Draft document on tunnelling issues, architectures, etc. Send to IAB list.
• Keith Moore and Charlie Perkins : Draft document on “finding stuff” issues, architectures, etc. Send to IAB list.

OLD ACTION ITEMS:

• Brian Carpenter: Send note to IETF list outlining IAB role and response re. green paper issues.
• Jon Postel (IANA): Build consensus on how to assign IPv6 addresses–get the registries to do something or perhaps form a BOF on the issue.
• Tony Hain: Put together a crisp problem statement for the NAT/VPN/IPv6 problem.

DRAFTS IN PROGRESS:

• Charlie Perkins, Radia Perlman, Sue Hares: Routing workshop report.
• Brian Carpenter and Erik Huizer: IAB charter (updated RFC 1601).
• Radia Perlman: What should be in protocols.
• Steve Bellovin: Security workshop report.
• Charlie Perkins: Technical value of IPv6.

NOTES:

Review actions

• Brian Carpenter: Send note to IETF list outlining IAB role and response re. green paper issues.–done
• Jon Postel (IANA): Build consensus on how to assign IPv6 addresses–get the registries to do something or perhaps form a BOF on the issue.–Postel and Hinden had a meeting with representatives of the registries to discuss draft proposal. It will be published as an Internet Draft; the registries will take it to their members for comment. Finally, will probably be published as an informational RFC documenting the agreement among the registries.
• Tony Hain: Put together a crisp problem statement for the NAT/VPN/IPv6 problem.–done

Review drafts in progress

• Brian Carpenter and Erik Huizer: IAB charter (updated RFC 1601).–on hold
• Radia Perlman: What should be in protocols.–suffering from lack of interest on mailing list. Radia will post to IETF list with a pointer to discussion list.
• Steve Bellovin: Security workshop report.–with RFC editor, waiting for IPSEC documents to clear.
• Charlie Perkins: Technical value of IPv6.–draft published; shorten; informally ask IPng list for comments on accuracy

Welcome/introduction for new members (Brian)

Welcome to Ned Freed and Tim Howes.

Fond farewells to Radia Perlman and Robert Elz.

Review of routing workshop (Radia/Steve D)

After the workshop, there was one rather vociferous complaint regarding the closed nature of the invitation-only workshop. However, limited attendance by a set of experts is both the only way to hold a valuable workshop, and is entirely within the IAB charter, RFC 1601. Remember, neither the IAB nor IAB workshops set standards.

Radia and Steve previewed their overview of the workshop for Friday’s IAB open plenary. See the notes and presentation slides from the plenary.

Thanks to Steve Deering and Radia Perlman for setting up the workshop, to Cyndi Jung for taking care of local arrangements, and to Charlie Perkins and Sue Hares for taking detailed minutes!

Round table to list IAB work items for 1998/99

• what do we need for routing in five years… how do we get there
• million-entry router table entries (or achieving the same effect)
• QOS multicast routing
• multicast key management
• rationalization of RAP, RTFM, etc.–working on similar problems, but unaware of each other
• finding stuff (which to use: dhcp, multicast, ldap, etc.)
• roadmap for all the ways you can find things
• naming things, URI
• directory services
• indexing and searching
• tunneling
• VPN tunnels: naming, addressing, routing
• NAT
• firewalls–make them part of the architecture
• applicability statements for the security building blocks we have–a living document
• security: actually making applications secure
• object security
• authorization and access control framework
• policy beyond RAP
• network management in heterogeneous environments; paradigms beyond SNMP; DEN;
• network applications management–more than just instrumentation
• IPv6
• in-home and to-the-home
• root server architectures; is there any way to flatten the hierarchy
• document things that are commonly done wrong (implementation and configuration)
• new transport protocol

These items will be clarified and prioritized by email discussion going forward.

Report from POC appointees Rob Austein and Patrik Faltstrom

Things were going fairly smoothly until December, when the US Federal Government got involved. Green paper comment period just closed. Unclear what will happen next. POC has been doing very little technical work.

Question from the IAB: Should the IETF take on specifying a protocol for interactions between registrars and registries? Yes, this would be a useful thing to do now. All existing proposals on the table require this functionality. Protocols for maintaining consistent copies of a registry would also be interesting.

Question from appointees: Does the IAB want to relinquish the voting rights of its appointees to the POC when the POC changes its constitution? The POC appointees pointed out that everything is done by consensus anyway, and this would be a politically good thing to do. The IAB’s proper role is to make sure that reasonable technical solutions are pursued–voting rights appear irrelevant to executing this role. Issue is when should this be done, and should this be unilateral or conditional on everyone else giving up their vote?

The IAB in general felt that the voting rights of its appointees is not that important–we want to advise, not vote. However, we do not want this to be taken as a repudiation of the POC. A decision on this will be taken when the revised constitution of the POC is decided.

Whither NAT? (Tony)

Tony reported on the NAT working group meeting today. The working group is focused on making NATs as good as possible. The IAB needs to focus on the areas where NATs impact the architecture of the Internet. We need to document the long-term consequences of NATs, so that people don’t erroneously conclude that NATs preclude the need for IPv6. More broadly, as with firewalls, perhaps we should also explore ways that applications and NATs can work together better.

Straw poll on 1998/99 IAB Chair (conducted by Abel)

Brian Carpenter agreed to continue to serve as chair; his offer was met with enthusiasm.

Future Meetings

Regular teleconference second Tuesday of the month at 10:00 AM Eastern Time.

These minutes were prepared by Abel Weinrib, weinrib@intel.com. An online copy of these and other minutes are available at http://www.iab.org/documents/IABmins. Also, visit the IAB Web page at http://www.iab.org/iab.

Slides used at the Open IAB Plenary

Slides – Deering, Perlman

Preliminary Report on the

IAB Workshop on
Routing and Addressing

March 23-25, 1998

Santa Clara, CA

reported by

Steve Deering

Radia Perlman

Purposes of Workshop

• stimulate interaction among various communities working on Internet routing & addressing issues
• identify current and future routing & addressing problems (both unicast and multicast)
• identify means of understanding and solving those problems (e.g., measurements, simulation, bug fixes, education, IETF working groups, IRTF research group, etc.)

Structure of Workshop

• 30 people (14 IAB / IESG members, 16 invited experts)
• 2.5 days
• 1 room

Topics

• scaling of unicast routing
• scaling of multicast routing
• NAT
• ToS / QoS routing
• routing security
• routing policy
• making net properties visible to applications
• multi-stranded links
• mgmt & diagnostic tools
• automatic numbering & organization of hierarchy
• anycast addressing
• load-sensitive routing

Scaling of Unicast Routing

• most current scaling problems can be fixed with improved implementation
• long-term concern about systematic issues:
  • volatility grows with size of default-free zone
  • multi-homed sites threaten aggregation
  • knowledgeable network operators are a scarce resource
• need more research into what’s breaking (not just more data, but more/better analysis)
  => IRTF Routing Research Group

Scaling of Multicast Routing

• dimensions #sources, #receivers, #groups, amount of data, burstiness, duration, topological distribution, .
• reviewed current approaches (DVMRP, MOSPF, PIM, CBT, BGMP)
• .and possible different approaches (single-source multicast, registry of group-RP bindings, replicated unicast, application-layer multicast)
• not yet clear that current approaches scale adequately in all desired dimensions
  => needs further study

NAT (Network Address Translation)

• identified yet more problems introduced by NAT, e.g., sessions that span multiple TCP connections, effects of inter-ISP NAT on trust boundaries
• discussed options: no NAT, fix NAT, fix apps, don’t do certain things (like IPsec)
  => will pass our detailed findings to the NAT working group

=> IAB will continue to worry about NAT

ToS / QoS Routing

• definitions:
  • ToS: hop-by-hop routing based on destination + ToS bits
  • QoS: routing of set-up packets (to make path for subsequent data packets) according to resources requested and available
  • both are examples of “constraint-based” routing
• discussion revealed demand for some sort of constraint-based routing both within and, eventually, between ISPs
  => recommend Routing AD consider IETF work in this area

Routing Security

• routers need to improve their “host” security – getting console access enables all sorts of harm
• we may or may not have discussed other security vulnerabilities of current Internet routing 🙂
• identified a few important areas of work, e.g., wire-speed authentication

Routing Policy

• reviewed what can and cannot be done with BGP
• some policies not supported by BGP can be accomplished by tunnels & static routes
• symmetric routing deemed not a realistic goal, so “get over it”
• router configuration languages very complex & error-prone; need better router policy language
  => refer to RPSL working group

Making Network Properties Visible

to Applications

• example desired services:
  • “nearest” of N addresses?
  • from multi-homed host, which outgoing interface to use?
  • MTU to destination?
• identified two general classes of solution:
  • on-demand, like current Path MTU Discovery
  • pre-computed, like unicast routes=> hold a BOF -> WG?

Multi-Stranded Links

• to get more BW between a pair of routers, sometimes use multiple, parallel links, treated as:
  • individual links, visible to IP routing, or
  • “multi-stranded link”, appearing as one link to IP routing
• multi-stranded approach is preferred, but need “richer” metric to reveal “how much” of link is up
  => L2 work (maybe not IETF)

=> L3 routing support for richer metrics in IGPs

-> OSPF and other routing WGs

Management & Diagnostic Tools

• database of prefix-AS bindings
• SNMPv3 with better authentication & scoping & rate-limiting
• remotely-controlled traffic sources
• tools for pro-active problem detection
• combined traceroute+ping with “intelligent analysis” rather than just data dump
• distributed probing system
• more analytic DNS diagnostic tools

Automatic Renumbering &

Organization of Hierarchy

• discussed
• no conclusions

Anycast Addressing

• work needed:
  • characterizing scaling properties
  • host-to-router protocol to allow host usage
  • pre-TCP handshake protocol?
• need to understand domains of applicability (as compared to multicast, svrloc, DHCP, DNS,.)
  => BOF -> WG (if torchbearer can be found)

Load-Sensitive IGP Routing

for Best-Effort Traffic

• believed to be a demand for this

• believed not to work

  (oscillation/stability problems, excessive routing overhead)
  + may be time to revisit
  => IRTF Routing Group or Routing AD: do something (or not)

Concluding Comments

• full workshop report will be published as an RFC
• our thanks to:
• Cyndi Jung for local arrangements
• Sue Hares & Charlie Perkins for recording the discussions
• all the attendees for contributing their time, effort, and insights

Slides – Braden

The End-to-end Research Group —

Internet Philosophers and ‘Physicists’

Bob Braden
University of Southern California

Information Sciences Institute

Marina del Rey, California

What is this IRTF Thing, Anyway?

How did we get here?

Once upon a time long, long ago … [1981]
- “Internet was a DARPA-funded research program
- Vint Cerf was the program manager
- Cerf created an informal panel of researchers to advise him on technical issues; this was the Internet Configuration Control Board (ICCB)

Continuing Real-Life Drama

Jan 1983: The ARPANET was converted to TCP/IP

1984: The DARPA PM (Barry Leiner) reorganized ICCB into the Internet

Advisory Board

IAB membership:
* Dave Clark, Chair and INternet Architect
* Jon Postel, RFC Editor and Protocol Czar
* The chairs of new research Task Forces

(Curiously, the membership of the IAB was identical to the membership of the ICCB …; self-perpetuation in action)

Research Task Forces — 1984

• Gateway Algorithms TF — Dave Mills, Linkabit
• New End-to-End Services TF — Bob Braden, UCLA
• Applications Arch. & Req’s TF — Bob Thomas, BBN
• Privacy TF — Steve Kent, BBN
• Security TF — Ray McFarland, DoD
• Interoperability TF — Rob Cole
• Robustness & Survivability TF — Jim Mathis, SRI
• Autonomous Systems TF — Dave CLark, MIT
• Tactical INternetting TF — Dave Hartman, MITRE
• Testing and Evaluation TF — Ed Cain, DCEC

Evolution

• In Sept 1984 IAB meeting, Dave Mills reported:

  “*The Internet has grown into a very large system:

   143 ntworks in the [hosts.txt] tables
  
   900+ hosts
  
  85 nets [in the gateway routing tables*“
  

• The DoD adopted TCP/IP offically, then backed off as the Great OSI War began

• Tasks Forces evolved or dies, and new ones arose; eg

  Privacy -> Privacy & Security

  Gateway Alg’s -> GADS -> INARCH + IETF

IAB Research Task Forces in Jan 1989

Four years later:
+ Internet Engineering TF — Phil Gross, CNRI
+ Internet Architecture TF — Dave Mills, UDel
+ Autonomous Networks TF — Deborah Estrin, USC
+ New End-to-End Services TF — Bob Braden, UCLA
+ User Interface TF — Keith Lantz, Olivetti Research
+ Privacy & Security TF — Steve Kent, BBN
+ Scientific Requirements TF — Barry Leiner, RIACS

Meanwhile (1989):

• The NSFnet backbone had happened
• The INternet had outgrown the DARPA research program that created it.

• The IAB and its TFs continued to exist, trying to guide the technical evolution of TCP/IP

  This was made possible by the aid & support of an INter-agency committee of the US government, the FRICC (->FNC)
  * The IETF-TF was clearly outgrowing the org. chart

A clandestine meeting in a crab-filled room in Annapolis, Md in summer 1989 lead to another re-organization

(First) New World Order

End-to-End TF — Objectives

Early years:
+ Active role in guiding, promoting, and coordinating relevant research
+ Fostering development of new E2E protocols for network researchers and users.
+ Advisor to IAB & RFC Editor on E2E issues.

Summary: the TF had a mission and a viewpoint

But the world moves on…

Today:

The E2E RG is just a bunch os Internet protocol bigots who like to meet twice a year to share crazy ideas and to debate esoteric architectural questions to the point of exhaustion.
Its primary controbution to the Internet world is the

mailing list on E2E issues:

end2end-interest@isi.edu (800+ members)

E2E Agenda

Question: “So, What DOES ‘end-to-end’ MEAN?”

My answer: “NOT routing or network management”.+ Obviously, transport layer and above; but also
+ End-end semantics of IP,

which includes e.g., nulticasting semantics, integrated and differentiated services, queue management algorithms (RED), scheduling algorithms, …

• Or (almost) any other Internet-relevant researchy issue that tickles out fancy.

But what is this ‘research’ stuff?

A fair question… these are muddy waters.

To quote out most aphoristic member, Dave Clark:

A. “Research is what you do when you don’t know what you are doing.

B. “Research is allowed to fail.”
Another view:

Research is when you are searching for universal concepts or mechanisms, or simply searching for uniderstanding.
The product of research is the written or spoken word.

E2E Agenda: A Sampling

Major themes have been:
* Support for RPC and transactions
* Multicasting & logical addressing
* Internet architectural principles
* Performance limits of the protocols
* Congestion control and INternet dynamics
* Internet service models and mechanisms

1. Support for RPC and Transactions

A. Application layer support
+ Semantics – Looked at Mercury, Cronos
+ Marchalling/Demarshalling => appl Layer framing
+ [Server location and binding]

B. Transport layer support

Dilemma: academic research was done [Birrell & Nelson]; needed corresponding Internet protocol standard. Looked hard at:

ESP, VMTP, REX, TTP, T/TCP,…
None crossed threshold be become a standard.

2. Multicasting & Logical Addressing

• One of the earliest TF agenda items
• E2E played a significant role in monitoring and promoting the development and deployment of Deering & Cheriton’s group multicast -> IP multicast (=>logical addressing)

This is probably our most unequivocal success
* Reliable multicast has always lurked on our agenda
+ Monitored research looking for a universal RM protocol. No successful, but lead to SRM.

3. Internet Architectural Principles

These are the “what if” questions:
+ What if the port numbers were in the IP header?
+ What if internet bandwidth were 10**15 bps
+ What if clock synchronization were a fundamental Internet mechanism?
+ What if we built a logical network of agents to performed staged delivery? [~ Bitnet]
+ What if UDP streams from non-adaptive apps become significant?

4. Performance Limits of TCP/IP

• Truth squad, debunking myths such as…

  <<“A new protocol architecture is needed for high speed networks”>>

  <<“We need light weight transport protocols”>>
  * Jacobson, Clark & Partridge showed that:
  + transport performance problems were in implementations, not in the protocols.
  + TP perf limits set by memory bus bandwidth
  * Discussion -> PAWS, large window extensions to TCP

NetworkPerformance Issues

Over the 14 years, the E2E RG has considered performance issues including:
+ Transport protocol performance, especially TCP performance (Early and Often!)
+ Presentation Layer performance
+ High-performance host interfaces

TCP trailing checksums, …

• Caching to improve performance
• Internet traffic measurements

5. Congestion Control and Internet Dynamics (“Physics”)

• TCP congestion control [Jacobson]
  [Our contribution: arguing with Van.]
• The fundamental significance of RTT & BW*Delay

• Roiuter queue management algorithms -> RED

  (Random Early Detection) [Floyd & Jacobson].

  *[Internet Draft -> RFC to IETF about RED]*
  

  • Rate-based flow control [NETBLT, VMTP,…]
    [Beware the Jaberwock of instability!]
  • The Quixotic (?) search for a ‘phase change’.

6. Internet Service Models & Mechanisms

• Early research goal: supplying multiple grades of Internet service, not just Best-Effort.
• Many discussions of packet scheduling and admission control algorithms.
• Two concerns led E2E RG to develop Integrated Services:
  1. [We thought] the elephants were coming
  2. ST-II was not the right answer

Integrated Services

• In 1989, the prediction of very widespread use of multimedia work stations was scary —
  • If we could not support multimedia services over IP, Internet growth could stumble and ultimately stop.
  • UDP streams without congestion control would threaten Internet stability
• The same DARPA research program that developed TCP/IP also developed the STreams protocol to support :real time” applications (packet voice
  ST did not run over IP and it was connection-full

Integrated and Differentiated Services

• In 1989, the ascendancy of the Internet architecture was by no means assurred. E.g., the OSI war may have been won, but not surrendered.
• These concerns led members of the E2E RG to develop Integrated Services during 1990-1995 [PARC, MIT, USC]
• IS was introduced into the IETF process in 1995 and reached Proposed Standard in 1997
• The research agenda has shifted to Differentiated Services.

Miscellaneous Issues…

• Develop a standard file access protocol

(To fill a known gap in FTP. Left to vendors)
* Communication for distributed systems

(Looked at in Locus, Cronus, V-system… Lost interest. CORBA in the intellectual heir of this problem)
* Internet standard presentation syntax

(We didn’t follow through, and we got what we deserved: ASN.1)
* Active Networks

A diversity of opinions

Conclusions

• Historically, the E2E RG has played a useful role in building the Internet
• Today, members of the E2E RG continue to play important roles (12 are registered for this IETF)
• The furture is less certain…
• There are strong political & social forces battering against the technical consensus upon which the Internet rests.
  It is unclear what/who will keep it from falling apart