IAB Minutes 1998-03-31 | Internet Architecture Board

Home»Documents»Minutes»Minutes 1998»IAB Minutes 1998-03-31

MINUTES FOR MARCH 31, 1998 IAB BUSINESS MEETING

PRESENT:

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)

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

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
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’

University of Southern California
Information Sciences Institute
Marina del Rey, California

What is this IRTF Thing, Anyway?

How did we get here?

“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

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 DoD adopted TCP/IP offically, then backed off as the Great OSI War began
Tasks Forces evolved or dies, and new ones arose; eg

IAB Research Task Forces in Jan 1989

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
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

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…

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

E2E Agenda

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

“NOT routing or network management”.

Obviously, transport layer and above; but also
End-end semantics of IP,
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.

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

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

Semantics – Looked at Mercury, Cronos
Marchalling/Demarshalling => appl Layer framing
[Server location and binding]

B. Transport layer support

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

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…
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

Transport protocol performance, especially TCP performance (Early and Often!)
Presentation Layer performance
High-performance host interfaces
Caching to improve performance
Internet traffic measurements

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

TCP congestion control [Jacobson]
The fundamental significance of RTT & BW*Delay
Roiuter queue management algorithms -> RED
Rate-based flow control [NETBLT, VMTP,…]
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