Subject: [Taps] Fwd: Draft IETF-90 TAPS notes

From: Aaron Falk <[email-masked]>
Date: Tue, 22 Jul 2014 15:48:42 -0400

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

---

From: "Velt, R. (Ronald) in 't" <[email-masked]>
Date: Thu, 24 Jul 2014 20:19:08 +0000

Excellent, indeed.

I would like to claim my 5 seconds of fame, however ☺

s/Roman Veldt (???)/Ronald in ’t Velt/

Thanks,
Ronald
From: Taps [mailto:[email-masked]] On Behalf Of Aaron Falk
Sent: dinsdag 22 juli 2014 21:49
To: [email-masked]
Subject: [Taps] Fwd: Draft IETF-90 TAPS notes

Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de wijze waarop u deze gebruikt en voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

---

From: Aaron Falk <[email-masked]>
Date: Sun, 27 Jul 2014 17:58:16 -0400

On Thu, Jul 24, 2014 at 4:19 PM, Velt, R. (Ronald) in 't <
[email-masked]> wrote:

> Excellent, indeed.
>
>
>
> I would like to claim my 5 seconds of fame, however J
>
>
>

Sure.  Will be fixed.

--aaron