Minutes IETF98: taps
minutes-98-taps-00

Meeting Minutes Transport Services (taps) WG
Title Minutes IETF98: taps
State Active
Other versions plain text
Last updated 2017-04-19

Meeting Minutes
minutes-98-taps

   TAPS

IETF-98 Chicago

Tuesday, March 28, 2017

4:40 PM CDT

Note taker: Kyle Rose

1. Administrivia and Chair’s Blah-blah - 10 min

2. Working group document updates - 20 min

2.1 draft-ietf-taps-transports-usage-03, Michael Welzl

•Aaron (chair): what's about TCP Auth? who is going to write it?

•Michael: one hour work, I shall write it.

•Aaron: ready for WGLC?

•Michael: yes.

•companion UDP usage document

        ◦Michael: IP layer functions, should they stay or go?

        ◦Gorry: ask the WG? UDP lite is a funny beast. like to continue with
        the document.

        ◦Michael: suggestion to make them standout as a part of generic IP
        things

        ◦Aaron: may be the title of the document is "UDP and others"

        ◦Michael will help Gorry.

        ◦Tommy Pauly asked about history of separate documents

        ◦Gorry: they are separate documents because they were written separately

        ◦Aaron: kept separate for managability, include text to point to the
        companion document

•ACTION: Tommy will volunteer to review Gorry's UDP document

•ACTION: Both documents need to be revised and then  going to WGLC, review the
UDP document, Micheal to write about TCP Auth

2.2 draft-gjessing-taps-minset-04 , Stein Gjessing

•Call for adoption

•Aaron: call for hands of people who read the draft

        ◦2 raised hands

◦Gorry: read the draft. Document seems as it should be. Not controversial. If
the WG want a document in this space then it should be adopted.

◦Tommy Pauly: Agree with that. Certain parts in the discussion area that we
should have more discussion on; word-smithing needed. A good thing to adopt: it
has the right core in it.

◦Aaron: anybody from remote has a say on this?

◦Brian Trammell: "Yeah, do it."

◦Hannes Tschofenig: one question on scope, Are you trying to cover security
layer into account? Shouldn't this cover security? for IoT any API document
includes guidance for DTLS would be useful.

◦Aaron: Tried to get someone from security directorate to participate, but no
one did, so we stuck with the stuff we knew. Would be useful to have an
equivalent of TAPS that handled security stuff

◦Tommy: Any practical API guidance will need to include security. Can't leave
it out. Is it possible to have another draft in TAPS that is the minset of
security features

◦Aaron: might be a charter scope change, but might be entirely appropriate

◦Tommy: would try a draft with min-set format to include security features.

◦Aaron: Hannes would you be interested in this? yes. lets talk about it in the
next meeting.

◦Gorry: Originally security was in-scope. would be cool to look at such draft.

3. TAPS Design Discussions - 60 min

3.1 Messaging, introduced by Michael Welzl

•Brian: Where is the boundary between application and some sort of library to
handle slicing? like minion and hollywood.

•Michael: The point here is to make it compatible with TCP.

•Brian: If a particular application protocol has a pre-existing framing
mechanism, the sender is using TAPS, and the receiver plain TCP, TAPS would
abstract the framing away from the application on the sending side but be
understood and dealt with explicitly by the receiver. Implementation level
details.

•Aaron: Good idea: needs refinement

◦ACTION: Refine idea

•Colin Perkins: If wire format is unchanged, but the parsing is moved from the
application to the transport stack

•Michael: your need a signaling protocol.

•Colin: no.

•Michael: My understanding is that you need the receiver to be TAPS-aware

•Tommy Pauly: Point is not to create new protocols, but to take what we have
and offer them as a service. Other side doesn't have to treat the transport as
messages. If we're writing messages and what's underneath is truly a
bytestream, all we're doing is scheduling how my chunks of bytes in TCP or in a
TLS stream arrive with respect to ordering.

•Michael: If we can make it work, I'm all for it.

•Tommy: I think is does work.

•Lars Eggert: Thinking about datacenter and low lantency, in the future, we'll
want to replicate memory writes to a remote machine rather than
serialize/deserialize

        ◦Is this a transport service that TAPS is looking at, or are we always
        serializing/de-serializing data?

        ◦Expresses concern about the cost of s11n/d13n

•Aaron: Out of scope

•Gorry: is there another way of doing (pointin to Lars's comment) it than TCP
way of doing it?

•Michael: not sure what Gorry is asking. This is a fall back to TCP mechanism.

•Colin: follow up on Lars's point. Should Discuss the security implications of
what Lars was suggesting.

•Aaron: sounds like a bar-bof topic.

3.2 Multi-streaming, introduced by Tommy Pauly

•Michael: in min-set it says for multi-streaming the only application specific
info required is priority of the streams.Speaking for option 3. Spoke about
grouping and how that applies to different transports depending on what's
available

        ◦as long a you know what the group is and what priorities applied then
        you can do it transparently.Thats the assumption here.

        ◦Opening and closing of connection is also not a big problem here, you
        establish connection by sending data.

•Tommy: a TAPS aware receiver can receive a HTTP stream and treat it at its
level.

•Micheal: yes, but in QUIC or SCTP there will be nothing on the wire when
connect is done.

◦Sending something to server to make request is a conner case.

•Colin: Does the API change if you rule out raw TCP vs. TCP with some streaming
structure (e.g., HTTP/1.1) on top?

•Tommy: if you can guarantee that your protocol is multi-streaming aware then
option 1 and 2 is more viable. But it does introduce a whole new bunch of error
condition and such.

•Colin: how do I use RTP on top of this? cannot see how to do this with option
3.

•Tommy: not familiar with such semantics.

•Colin: Requests are not completely independent

        ◦Some protocols have subflows that are aware of each other

•Michael: Maybe being able to query about the transport would be sufficient

•Kyle: Not sure query about a specific protocol is sufficient. Want to use TAPS
explicitly because I don't want to know exactly which transport I'm using, but
instead just want transports with specific characteristics

3.3 Early data transmission, introduced by Michael Welzl

•Tommy: Not sure it is the best way to expose fast open. Can use
characteristics of messages (e.g., idempotent) to give the transport some
flexibility in how to handle it, such as sending it via TFO or TLS 1.3 0-RTT
(or QUIC 0-RTT)

4. Related Projects - 30 min

4.1 Happy Eyeballs, Naeem Khademi

•Aaron: State of implementation?

◦Naeem: All implemented and available on GitHub

•Colin: Starting to look a lot like ICE (interactive connectivity establishment
WG)

        ◦The extensions they have are things that you'll need

        ◦Conceptually, something very similar

•Aaron: See lots of puzzled faces

        ◦Probing end-to-end and using heuristics to decide on what's working

•Colin: ICE does connection racing

        ◦Details are different, but conceptually similar

•Aaron: Similar problem that could be learned from

•Colin: (paraphrased) yes

•Tommy: Happy eyeballs is a bit higher-level

        ◦The race itself could use ICE

        ◦Great if document could go more into how to schedule fallback

        ◦Current approach is "do it simultaneously; see which works better, and
        remember"

        ◦When we do happy eyeballs for addressing, we keep everything on the
        table, because conditions may have changed

•Phillipp Weinrank: Concern about burning resources on the server side dealing
with races

•Naeem: Haven't looked into that. Something to consider.

4.2 NEAT, Naeem Khademi

•Aaron: Endpoints are going to discover which protocols do and do not work.
Have you given thought to sharing that information?

•Naeem: You mean between entities?

•Aaron: Maybe centralize it. Might be helpful to discover which carriers are
breaking standard protocols. Is this part of the scope of stuff you're thinking
about?

•Naeem: we have not arrived to the state to do large measurement but think it
is possible to do that.

•Gorry: Notion of collecting results of probing/races is a necessary element of
a system like this. Likes the idea of collecting information and making it
available to the user

4.3 Post-Sockets, Tommy Pauly

•Hannes: There exits diversity of elements for security (certificate types,
roots of trust). How do you deal with all of these?

•Tommy: Maybe provide a security object that encapsulates and abstracts the
implementation of the security "stuff" to whatever is specific to the
application

•Lars: "aside from the link going down how long message going to be kept
locally before you send them?

•Tommy: hopefully not too long

•Lars: Then do you really need this?

•Tommy: These are coming from real-time stuffs , like playout buffers.

•Brian: Looking for people to write applications. Really looking for wider
input on this from actual implementors.

•XXXX from Google: What about padding for security and privacy reason?

•Tommy: Would be nice if the application didn't have to worry about the
specific security properties (e.g., padding)

•Kyle: Maybe need to be able to enumerate and choose security properties in the
same way we choose transport properties. Maybe confidentiality of bits is good
enough, but maybe we also need to be resistant to traffic analysis