Subject: INT SERV Minutes

From: Craig Partridge <[email-masked]>
Date: Fri, 15 Apr 94 10:13:15 -0700

[Sorry for last second minutes but aside from overscheduling my time, I was
hoping we'd get everyone from the INT SERV meeting on the mailing list by now.
Apparently that hasn't happened (at least, I haven't been notified that it has)
thus the long CC list.

I'm going to ship these minutes to CNRI in about 4 hours -- so any comments
people have should be made ASAP.  Thanks and sorry again for short notice. --
Craig]

MINUTES of INTEGRATED SERVICES Proto-Working Group Meetings

First Meeting

    The first meeting was an organizational meeting, describing the
motivations for the group, its organization, and timeline.

    The goal of the working group (which is still awaiting approval)
is to make the Internet friendly to real-time applications (e.g., multimedia
conferencing) by enhancing the Internet architecture to support integrated
services.

    The proposed working group organization calls for Craig Partridge (BBN) to
be the WG chair, and John Wroclawski (MIT), Scott Shenker (XEROX PARC) and
Dave Clark (MIT) to be vice-chairs.   It was explained that the large
management team is intended to ensure that the necessary outreach to various
affected communities is made.

    The WG timeline calls for delivery of several RFCs over the next two
years.  The question was raised about whether anything with delivery two
years into the future was "research" and thus not within IETF scope.  The
concensus answer seemed to be yes, it sometimes takes that long, and that
this agenda was appropriately conservative (i.e., we might finish faster)
rather than wildly optimistic.

Second Meeting

    This meeting was devoted to trying to investigate what requirements
integrated services might place upon IPng.  Partridge explained that this
was definitely putting the cart before the horse, given that the group had
barely even had a chance to talk about proposed integrated services
architectures, but at the request of the IPng directorate, we'd agreed
to hold a discussion.  To launch discussion, two WG co-chairs gave talks.

    John Wroclawski gave a talk about flow ids.  One of John's key points was
that there's a range of tradeoffs involved in how to identify a flow.  The
problem is locating some state in a router that tells you what special
handling a particular packet requires.  (A series of packets which
receives special treatment is what constitutes a flow).  John also
pointed out that we already do this state lookup or classification
today -- when we look up a route.  What's making the future different is
that we'll want to do several classifications on a single packet (finding
state based on issues such as security, accounting, flow control, and
destination), and that while there are logically several lookups being
done here into multiple databases, for efficient forwarding, in practice
all these virtual lookups need to be reduced to one actual lookup.

    At one extreme one can locate the state by looking at enough fields in a
packet header (e.g., IP src, dst, protocol id, protocol ports, TOS field, etc.)
to uniquely identify a particular flow of packets.  This may well be what we
do for IPv4, since it lacks any specific flow ids.  At the other extremely,
there is a flow ID in each packet which points to some state.  Another issue
is what to do if after you look up the flow ID, you find you don't have
state.  If one examines the header, one might be able to figure out what
state should be given to the packet.  If one uses flow ids, the flow id
can either be a hint (if missing, you can probably puzzle out from the
headers what to do with the packet), or as Noel Chiappa suggested, it can
be a "key" which if missing means a router should discard the packet because
it will probably do the "wrong thing" (e.g., route to the wrong place).

    John's conclusions were:

1) It is highly desirable for IPng to support a mechanism for fast
multi-axis classification of *all* packets. This requirement is
general, not just required for integrated services.

2) The *mechanism* chosen for the ng IP protocol should not assume any
particular definition of flow or choice of classification criteria.

    John's talk engendered a long discussion, with various people debating
which type of flow id semantics were really desired, whether multiple
applications' traffic should be combined into one flow, or if a single
application's traffic might be split into multiple flows and even if flows
were needed.  (For an example of multiple applications in one flow, consider
several video channels aggregated together, perhaps to yield a flow with less
variable bandwidth demands.  For an example of multiple flows for one
application, consider multi-layer encoded video, where different receivers may
only want certain layers, and thus different layers are sent as different
flows).

    Dave Clark then gave a talk based on part of the IAB retreat report that
discussed authentication issues for IPng and flows in particular.  It is
clearly undesirable for an entity Bob to be able to access the resources
reserved for a flow that has been established for Alice, provided Alice is
actually using the resources.  (If Alice isn't using them, we'd presumably
like to see the resources available to others, as needed).  Dave talked about
a number of ways that one could try to inexpensively authenticate packets
as belonging to a particular flow.  Dave pointed out that, unlike the needs
in some security contexts, the authentication mechanisms don't have to be
perfect, they simply need to keep unauthorized access to a manageable level.
(For details of the various proposed mechanisms, see the IAB retreat report,
available as an I-D).

    After Dave's talk, there was some discussion of how to related
authentication needs to the flow id issues raised by John's talk.

    At the end of the meeting, the proto-WG concluded that there were two
requirements it would like to place on IPng:

    1. That an IPng have some mechanism to locate per-datagram
    classification information (e.g., flow state) and that the mechanism
    should be consistent with forwarding at the media speeds expected in
    the future.

    2. That an IPng should have mechanisms to hinder Bob from using
    or disrupting resources that Alice has been granted and is using.

Craig Partridge was tasked to write up these points and circulate a
draft to the WG, for consideration as submission as a white paper to the
IPng directorate.

%%% overflow headers %%%
Cc: [email-masked], [email-masked], [email-masked],
        [email-masked], [email-masked], [email-masked],
        [email-masked], [email-masked], [email-masked],
        [email-masked], [email-masked], [email-masked],
        [email-masked], [email-masked], [email-masked],
        [email-masked], [email-masked], [email-masked],
        [email-masked], [email-masked],
        [email-masked], [email-masked], [email-masked],
        [email-masked], [email-masked], [email-masked],
        [email-masked], [email-masked], [email-masked],
        [email-masked], [email-masked],
        [email-masked], [email-masked], [email-masked],
        [email-masked], [email-masked], [email-masked],
        [email-masked], [email-masked], [email-masked], [email-masked],
        [email-masked], [email-masked], [email-masked],
        [email-masked], [email-masked], [email-masked],
        [email-masked], [email-masked],
        [email-masked], [email-masked], [email-masked],
        [email-masked], [email-masked], [email-masked],
        [email-masked], [email-masked],
        [email-masked], [email-masked], [email-masked],
        [email-masked], [email-masked],
        [email-masked]
%%% end overflow headers %%%