Excellent notes from Wes Eddy from the TAPS meeting.
TAPS (Transport Services) BoF
IETF 90
Toronto
Chairs: Aaron Falk and Michael Welzl
Aaron reviewed the agenda and meeting objective to form a new working group.
Spencer Dawkins is the sponsoring Area Director. He summarized the previous
TAPS BoF meeting in London and that it covered "everything in the world",
but
this meeting has to be more focused on answering the chartering questions.
There are two levels of IESG review for chartering:
- internal review: "is this ready to go out for others to review?"
- external review: "should this working group be formed?"
Spencer noted that the BoF list may be copied on these discussions, as the
IESG has started including mailing lists in this process.
Brian Trammell
TAPS and Transport Evolution: History and Next Steps
- The sockets API is not expressive enough for new transport requirements
- Brian reviewed past activities up to and including the prior BoF in London
- There has been a lot of discussion in different directions (academic work,
middleware, etc), but the forward direction was not clear
- IAB has been looking at this problem too, concerned with (1) application
access to new transport services and (2) improving path transparency
- there are slides from the APPSAWG meeting discussing this from Joe
Hildebrand
(a link was posted in the jabber room)
- proposed focus on:
- set of existing transport services and which are useful
- methods for providing services in context of incremental deployment
Michael Welzl
The TAPS Charter
- Michael described "zig-zagging" of the charter content that has been
happening
(inserting and removing things) and provided links to the history and list
archives
- Michael's presentation moved through the charter paragraphs and described
what
each is supposed to mean
Lars Eggert: Is a transport protocol in this definition identical to a
transport
service, or is it a combination of services?
Aaron Falk: A combination of protocols or a set of protocols may provide the
set of behaviors that is required for a service; the terminology will be
defined as part of this work, and Brian is itching to do that.
Need to give applications the flexibility to ask for what they need in terms
of services, not just protocols.
on the part of the problem statement about finding what works in the
network:
Dave Thaler: This is not the full explanation of the problem. Falling
back to
TCP or UDP is not sufficient, since many places drop both and only let
HTTP
through. It should include HTTP as a possible fallback.
BCP56 and Websockets discussion in the charter mentions HTTP.
on the deliverables:
Joe Hildebrand: if we see good ideas from non-IETF protocols, we should
allow
them onto the list of services, but the way it is written now doesn't
encourage
this
Aaron Falk: the IETF tends to require strong justification / use cases for
doing things, and the output of this working group is an intermediate
point;
can you give an example of what you're thinking of?
Joe: as long as others aren't excluded, I'm fine with prioritizing IETF
protocols.
MOSH, for example (is one that isn't an IETF protocol)
Pete Resnick: asking Joe a question, thinking of the other direction in the
stack, and whether IEEE or 3GPP layer-2 protocol features will be
requested
to be made available to applications
Gorry Fairhurst: let's start with ones that we know well, published here
rather
that a wide list of proprietary and other standards bodies work
Lars Eggert: other things aren't under the IETF IPR rules, and you might get
things that you don't know the IPR of, even though other people have good
ideas
Joe: I would be fine with their being a "higher bar" for non-IETF things,
just
don't want it to be explicitly prohibited
Eliot Lear: +1
David Black: +1; also see deterministic networking / 6TSCH in TSVWG
Youske Doy (???): what is the transport service along the path?
Gorry: This means we need feedback about what works on a given path
Dave Thaler: is this set of services mentioned just an example or expected
to
make other things not on the list require strong arguments to be included?
Chairs: no; this is just an example of things we can quickly agree on
Dave: thinking about things about mobility, proxy traversal, etc.
Brian Trammell: lots of "kilo-comments per word" on this part of the
charter;
suggest just striking the sentence from the charter
Lars Eggert: agree (those are actually really bad examples - not even
transport
services)
Ignacio Solis (PARC): to what degree does the network layer protocol
reflect on
this API, and is it possible to not use "IP"?
Joe Hildebrand: one of the ADs wanted some examples in here, so let's be
careful
about striking this list; explicitly marking them as examples is easier
than
striking them in this case
Aaron: Lars raised things he doesn't think are transport services that I do.
I think of "behaviors" rather than services, and they can be axes where
you
can turn a knob (degree of reliability, ordering, throughput); is that
incompatible with your understanding?
Lars: mine is a point on the scale, not a knob that varies. the transport
services is the mechanism that delivers data reliably or unreliably. in
congestion control, what you choose (CUBIC vs LEDBAT) scores differently
in latency vs thoughput
Aaron: a bad outcome would be if transport services were just a list of the
existing protocols. would you accept that a service might define its
congestion control, reliability, and privacy differently?
Many in the room: Yes
Brian: a service has behaviors ... first thing we need to do is capture the
terminology from this discussion
Joe: I like thinking of these as points on a continuum, and want to
eventually
get to the point where behaviors are discrete points
Ted Hardie: compile-time set versus real-time choice ... each decision is
made
when an application defines what to build into its code, if that gets more
modular but remains selected at compile time, that's ok, but very
different
from being selected at run-time
Brian: I would suggest on this point that we don't know yet what the model
is
going to be for using these and don't want to make a decision today
***both are in scope***
Ted: this should be in the charter text
Pete: agree with this
Roman Veldt (???): are you looking at point-to-point only or is point-to-
multipoint also included?
Gorry: let's start with something we can do (unicast)
(much applause and laughter in the room)
Aaron: deliberately make this out of scope for the initial charter (we don't
know how to do it)
Preethi ??? (Cisco): dynamism in the path / changes in the network drive
dynamic
service discovery, but this is a very big problem to tackle
Aaron: there are other deliverables, and I think this comes up in those;
there is
a third deliverable (Experimental RFC) that describes how you might
implement
this; let's come back to the discussion
Colin Perkins: not here to argue in favor of multicast, but do think this
is not
the right way to look at it ... RTP is not listed as an example transport
by
the way ... group communication can be built using unicast, and nothing
like
that is mentioned; multipath TCP also has one sender and receiver but
isn't
exactly unicast since there are multiple flows. the charter should
either be
expanded or constrained more clearly
Brian Trammell: I think it would be a gigantic mistake to scope to unicast
now,
because it could be impossible to adapt to multicast later; agree with
Colin
that we need language
Aaron: can one of you give us a hint what the point is?
Brian: charter language has to let us consider behaviors that are exhibited
by
unicast, multicast, multipath, etc. otherwise it's not going to be
relevant,
but I don't know how to put it into charter language
Andrew McGregor (Google): can think of 2 other things, anycast and
termination of
TCP connections in CDN
Gorry: let's not dig a rathole with multiple exits; scope deliverable to
something
we can actually do, but allow other things in scope of WG discussion
Colin: agree on keeping things focused, but may need term other than
unicast for
communication between 2 participants
Lars: unicast/multicast is a behavior that the application requests just
like any
other thing
Aaron: does anyone feel strongly that the charter needs to define this or
can we
allow the WG to figure out how to do the right thing?
Joe: allow the WG to do the right thing
Andrew: +1
Colin: giggling; tempted to constrain it a little in the charter and
recharter if
we need to try to tackle group / multicast communication
Aaron: how about the charter "emphasizes" communication between 2
participants?
David Black: I think that's good; it gives the ADs an opportunity to reign
things
in if the exploration gets out of hand
Mo Zanaty: if we exclude group communication, link local multicast or
anycast for
service discovery could be excluded; also layer-2 behaviors; these are
important
to the application and services that it wants
Aaron: trying to add a layer of abstraction so the application doesn't need
to be
aware of layer-2 behaviors
Mo: requests for a specific behavior should carry through all the layers
Joe H.: cringed but could live with the "emphasized" suggestion
Dave Thaler: agree and suggest wording, "consider services between two
endpoints
such as:"
Lars: when you say "specify the subset" do you mean write a spec on how to
implement?
Michael: no just "list" or "document" them
Lars: will you have documents that descibe how you provide the services?
how do you
envision doing this absent specifications for how to provide them?
Gorry: not sure what Lars is asking ... are you assuming it's going to
define services
or protocols? We're not intending to define new protocols, just how to
determine
what protocols are used.
Lars: 2988 (computing TCP retrnansmission timer) has been updated, but do
you envision
that building blocks like that would be described in stand-alone abstract
fasion?
Aaron: does app need RTT?
room says some protocols do
Lars: what kind of documents do we envision coming out of this 2nd bullet?
Aaron: modularizing on existing protocols
Colin Perkins: following on from Lars ... this makes me think of WGs like
RMT that was
putting building blocks together, but not sure that's what's being
proposed here
Michael: this would require developing new protocol, which is not what this
intends
Colin: the text is not clear on this
Gorry: I hoped to actually produce new protocols and machinery, but *NOT*
for doing
transport, but rather for making them work e.g. Happy Eyeballs
Aaron:
1st document "list of stuff"
2nd document select what's included in API
Gorry: makes sense to me
Dave Thaler: confused on use of passive tense (doesn't say who does
choosing or selection),
is the audience the person writing code or an application running, or is
the intention to
be deliberately agnostic
Agreement that both are to be included in-scope (compile and run-time)
*** charter needs to include notion of audience e.g. application writer
Stuart Cheshire: part that makes me nervous is idea that TAPS is
meta-protocol doing run-
time negotiation go figure out what to use; application writer will look
at available
options and pick what they think they need, and don't want at run-time to
be told that
it isn't there
Michael: goal of this charter is to focus on things we can agree on as a
starting point;
this 3rd point is experimental
Spencer: need to ask the BoF questions and wrap up discussion; this is
actually under a WG
review on the IETF discussion list
on out-of-scope items:
Lars: one minor point, new stuff should be excluded too
Eliot Lear: noted a cut-and-paste error
Toerless Eckert: QoS discussion deferred (need to discuss offline)
Brian Trammell: want to make sure that confidentiality, integrity, etc. are
behaviors
Yes
Colin: transports have quite different security models to TCP
Understood and WG will have to deal with
Preethi: depending on how service discovery gets done, there could be new
kinds of attacks
Questions:
A. Does the room understand and agree on the problem?
solid hum from room
Are there people who don't understand and agree?
some small number of hummers
Scott Bradner says he just doesn't understand
Dave Thaler says he hummed against because he thinks others have different
understandings
B. Is there support to form a WG with the following charter?
solid hum
C. Does anyone feel that a WG should not be formed?
small hum
Dave Thaler: just observing that this charter may not be the right one
Toerless: think that some charter modifications should be made
Aaron: not bolting the charter down; still in IETF review
Pete Resnick: hum that this charter is not ready
Colin: should a WG be formed once we've iterated the charter a bit more; I
absolutely
support a WG in this area, but not the specific charter at the moment
Spencer: what I'm expecting to happen is that a updated version of the
charter will be
posted with responses to comments that have been made here and on the
IETF discussion
list
Aaron showed a list of changes he recorded:
- follow SFC
- add re-charter at end
- spelling nits
- name change (wiretapping implication)
- design-time vs run-time
- services between 2 endpoints as scope to be emphasized
- audience is developers of apps and stacks
Brian: agreed terminology (behaviors, etc) needs to be reflected in charter
Stuart Cheshire: rather have "facility" than "behavior"; will engage on list
Aaron heard a strong hum that WG should be formed. Disagreements should be
taken to
the list.
Does anyone feel that a WG with the charter modulo upcoming discussion
should not
be formed?
no hums
D. Who would be willing to review documents?
maybe 2 dozen hands shown
E. Who would be willing to serve as an editor for one of the initial two
documents?
Brian, Michael Tuexen, Gorry, Michael Welzl
Spencer: thanks for coming and asking questions; watch for revised proposed
charter to
come out after the WG review period ends
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
