[an error occurred while processing this directive]
Second Internet2 QoS Working Group Meeting
February 24-25, 1998
Hyatt Regency, Chicago O'Hare
Attendees:
-
Terry Gray, Univ Washington
-
John Sikora, ATT
-
Chuck Song, MCI vBNS engineering
-
Ken Peirce, 3Com
-
Sue Hares, Merit (pseudo-scribe)
-
John Coulter, Bell Canada
-
Allan Ryan, Univ Chicago (guest)
-
Bob Riddle, Internet2
-
Kathleen Nichols, Bay Networks
-
Jerry Sobieski, Internet2
-
Osama Aboul-Magd, Nortel
-
Paul Ferguson, Cisco (pseudo-scribe)
-
Guy Almes, Internet2 (pseudo-scribe)
-
Ben Teitelbaum, Internet2 (facilitator)
Agenda:
Tuesday, February 24th (13:00 - 18:00 CST)
-
Welcome
-
Review requirements draft
-
Review differentiated services approach to QoS
-
Discussion: "Is diff-serv the answer?"
-
Identify what we know, think we know, and definitely don't know
-
Initial discussion: "What's the best scope and ambition-level for the May
proposal?"
-
Initial head-scratching on division of labor
-
writing tasks
-
other (i.e. meeting planning)
Wednesday, February 25th (8:00 - 13:00 CST)
-
Three short presentations:
-
Continued discussion: "What is the best scope and ambition-level for the
May proposal?"
-
Final division of labor
-
Schedule for March
Goals
-
Consensus within WG on requirements
-
Clear characterization of QoS approach to propose in May (First Internet2
Joint Applications / Engineering QoS Workshop)
-
Better understanding of what we do and do not understand
-
Decision on the scope of the proposal
-
Division of labor
Minutes
Tuesday, February 24th (13:00 - 18:00 CST)
Welcome
-
In addition to/during Ben's presentation:
-
Dates still being discussed for Joint Applications/Engineering QoS
Workshop in May. One conflict during mid-May is the IWQoS workshop in Napa
(May 18-19) (see http://www-ece.rice.edu/conf/iwqos98/)
-
Brief discussion of how the phases of the problem space & the solution
space could be visualized into timelines. Both QoS, Engineering, and Applications.
Review Requirements Draft
-
Discussion of requirements & framework documents. Needs further
-
discussion.
-
Sue correctly suggests that the Apps folks add some meat to the Requirements
document in terms of motivating applications requirements. (lean on Ted
H.).
-
Discussion on "eventually multicast" -- point being that the diff-serv
model of QoS is less the issue here than the simple
-
problems regarding multicast deployment in and of itself (which are arguably
already being solved in the Internet).
-
Sue correctly suggests that we need to keep our eye on how our QoS thinking
will work out over time when many of the motivating applications (e.g.
distance learning) are naturally multicast.
-
Review differentiated services approach to QoS.
-
Paul asks why we seem to have closed on the Van/Premium version of diff-serv,
and noted that there are versions other than Van and Wroclawski.
-
Rathole discussion about diff-serv flavor used within Internet2. ("Sorry
about that." - Paul)
-
Also brief mention of Lucent possibly having patents in this area throwing
a major monkey wrench into the whole area of "marking at the edges &
administering in the middle" of the network.
-
Discussion of diff-serv semantics being somewhat confusing.
Discussion: "Is diff-serv the answer?"
-
Paul correctly points out that there is a difference between engineering
and providing a service.
-
Paul notes that some gigapops will be carrying commodity traffic, and ponders
what the implications will be.
-
Sue asks about the joined-once joined-forever problem, first noted by Lothberg
in the context of CIDR and AUPs.
-
Side discussion that needs to happen (arguably not within the Internet2
QoS WG on we are calling the "forever joined" aggregation method of QoS
aggregation model).
-
Guy: Applications contract -- Between the workstation and the first-hop,
is this reasonable or true? Diff-serv variants fall within this characterization?
-
Confusion on diff-serv (models within diff-serv, CoS, premium, assured)
-
Still seems a lot of confusion here on what model is exactly what.
-
Sue and several others ask whether casting the contract between two clouds
as a single capacity/bucket parameter. Consider the case where a
cloud has ten nodes who each ask for 1 Mb/s; the cloud must be prepared
for all ten nodes to send packets that use the same bottleneck resource
(e.g., if they are all ten going to the same destination). What is
the implication of this?
-
Several people noted that, if we agree on the family, even if we do *not*
agree on the right eventual element of that family for the future, it would
be good to pick one well-defined plausible element of the family, and build/deploy/use/measure
it.
-
Discussion of tools v. models. Architecture deployment -- all at once,
or incrementally. What happens if a piece of the architecture fails to
fulfill its designed purpose? You fall back to incrementalism.
-
Terry pointed out correctly that it would be a strong positive attribute
of the set of elements considered if the union of the low-level mechanisms
they require is bounded/manageable.
-
Overlap in the toolspace, irrespective of model = good.
-
Ended Day 1 on a discussion of policy control & AAA
Identify what we know, think we know, and definitely don't know
Initial discussion: "What's the best scope and ambition-level for the May
proposal?"
-
Obvious need to justify thoroughly the family of QoS we are proposing (i.e.
Profile-Based Differentiated Services)
-
Guy harped on the idea that, while there might be several different elements
of the family with important/crucial differences in plumbing, it would
be very good if it were possible for a single abstraction to be given to
the hosts and/or applications developers. This seems to be very possible
to do.
-
Discussion of need to nail down standard Internet2 QoS API soon.
-
Winsock2 as an interface aggregation point -- not specific enough.
-
Kathie: Lixia has been looking at having hosts use RSVP to signal DS requests.
-
Bob Riddle will work with applications folks to nail this down soon.
Initial head-scratching on division of labor
Writing tasks
-
Ben: need "working grouplets" to attack sub-problems and sub-tasks
-
Ben: initial thinking on writing chores:
-
Finalize Internet2 QoS requirements statement and invite feedback.
-
Make the case that the diff-serv family is the most promising, seemingly
viable QoS approach to address the stated requirements
-
Scrutinize the most promising member of this family (premium service ?)
-
Make convincing plausibility arguments for:
-
incremental deployment
-
pre-standards deployment
-
containment of cost and administrative complexity
Other (i.e. meeting planning)
-
Idea: Physical meeting during IETF week in LA. Kathie says: better
if later in week.
Wednesday, February 25th (8:00 - 13:00 CST)
Three One-Hour Presentations with Discussion:
Continued discussion: "What is the best scope and ambition-level for the
May proposal?"
Final division of writing tasks (see
slide):
-
"Requirements" - B. Teitelbaum, T. Hanss, T. Gray
Analysis of what users need/want (as distinct from what the advanced
applications folks need/want) (Terry)
-
"Characterization of general approach (Profile-Based DS)"
- B. Teitelbaum, K. Nichols, P. Ferguson, J. Sikora, S. Bradner (ed.)
Include discussion of what low-level mechanisms are needed for each
of the elements of the family emphasisizing overlap
-
"Administration" - T. Gray, L. Conrad, K. Klingenstein
Nice administrative properties of PBDS; examples of policy basis for
responding to such requests
-
"Host" - B. Riddle, J. Sobieski, O. Aboul-Magd, K. Peirce,
(L. Zhang?)
Technical interface between host/application and first cloud (API and
host to first BB interface)
-
"Example Campus Architecture" - T. Gray
-
"Example Gigapop Architecture" - J. Grisham, R. Hutchins
-
"Example Backbone Architecture" - C. Song, S. Brim, J. Coulter
PBDS for the vBNS
-
"Premium" - K. Nichols
Analysis paper on how premium service could be done in Internet2; relevance
to requirements and deployment plausibility
-
"Assured / hybrid flavors" - P. Ferguson
Analysis paper on how assured/hybrid services could ...
Schedule for March
-
Next meeting: definitely at March IETF in LA late in week (Ben will poll
for best time and find a space)
-
Goal: Have drafts of all writings ready before IETF week so that WG members
and invited VIPs who will be around during IETF week may have time to review.
-
Weekly conference calls in March to check in with progress on writing tasks.
(Ben will poll for best time.)
[an error occurred while processing this directive]