Minutes IETF97: taps
minutes-97-taps-00

TAPS@IETF 97 2016-11-16 09:30 Grand Ballroom #2

Chairs Aaron Falk and Zaheduzzaman Sarker started meeting 09:33
Scribe: Kyle Rose and Jake Holland
Jabber Scribe: Colin Perkins

Note well shown 09:33
Agenda bashing
*** = action item

Chair updates
3 wg docs:
    taps-transports, taps-transports-usage-udp, taps-transport-usage
3 related docs:
    gjessing-taps-minset: bottum up analysis, maybe not minimum
    mcquistin-taps-low-latency-services, trammel-post-sockets

milestones reviewed
        1. define set of transport services (done)
        2. specify subset of services that taps-supporting systems will provide
        (in progress) 3. mechanism and implementation discussions (just
        beginning)

progress minset:
    gjessing-taps-minset mentioned
    low latency services

michael welzl, draft-ietf-taps-transports-usage update 09:41
        * brian trammel 09:44-
                * For the scope of this draft, we leave it at that
                * None of these provide integrity, confidentiality, or
                authentication * How do we handle that?
        * Michael
                * No response from a query to the TLS list
        * Aaron
                * We don't have the expertise in the room
        * Brian
                * Will propose a paragraph to add ***
        * Tommy Pauly
                * If we want to limit it to specific transports, we should say
                that * There are other things we're going to want to get from
                TLS * There are similarly common patterns when you are doing
                secure transports that are out of scope
        * Lars Eggert
                * Have you thought about something like FLUTE
                (https://tools.ietf.org/html/rfc6726) * Limited by choice of
                protocols, and all the ones here are kind of similar
        * Michael
                * SCTP pretty much does it all
        * Lars
                * SCTP doesn't have simultaneous multipathing
        * Michael
                * But that is covered by MPTCP
        * Mirja
                * FLUTE is in other document we just finished
                * shook her hands no, this doc should not cover flute.
        * yoshifumi nishida
                * <I didn't get any of that> something about apis
        * Michael
                * <I didn't understand the point of this exchange>
        * Tommy Pauly
                * As we're doing this work, MPTCP should look at the API work
                we're doing and learn from it
        * David Dolson
                * Do the documented capabilities include accepting connections
                as any address (including foreign)? * Michael: it's in the base
                TCP spec so yes
        * Wolfgang Beck - 09:53
                * Query the send queue length
                * Real world example: server doing lots of transport over TCP
                * Renegotiated link from 10G to 1G
                * Buffer space filled up
                * Drained too slowly
        * Michael
                * Could add an appendix listing things that are important but
                aren't in any of the specs *** * security considerations ***
        * Aaron
                * Need any text contributions from people?
        * Michael
                * Intended to write it myself
                * Would be good to have some contributions
        * Aaron
                * Poll the tcpm list
        * Colin
                * gorry fairhurst via jabber: "SCTP i-data (ndata)" is nearly
                ready for WGLC

S. Gjessing - draft-gjessing-taps-minset-03 09:59
        * should this be a wg draft? (asked by author): 3 hands for "who has
        read?" +1 jabber-gorry * Colin
                * Looks consistent
        * Aaron
                * Anyone want to speak against adoption?
        * Tommy Pauly
                * What direction do we want to take toward making any changes
                to it * As a minimal set, it does seem quite large * Would we
                try to minimize it further? I.e, "This is the full set, and we
                should try to cull things out"
        * Aaron
                * Wait
                * Just move on and circle back to the draft later on, probably
                online
        * Mirja
                * What's different from what we have so far?
                * Not clear
                * What's different from the API we have on today's systems?
                Does it make a big change?
<author has left the pink box...>
        * Michael
                * it is what we have today.
                * Lists
                        * What you must expose if you want an app to be able to
                        use it * What you don't have to expose
                * Clearly a TAPS system can't offer capabilities that are not
                in this list * Which of the functional systems do we really
                want to provide? * Narrowing that down is definitely of
                interest * <I couldn't derive anything from the end of that>
        * Mirja
                * Looks very specific to MPTCP
                * Not what I want from my interface
                * Don't want to use MPTCP: I just want something to use for my
                application * Not sure this is where we want to be * Does this
                document give an implementor any benefit over what exists today?
        * Michael
                * Yes! It tells you which systems are functional
                * Categorization is what this is about
        * Steiner
                * <?>
        * Brian
                * Just read the draft now, enough to have an opinion (audience
                laughs) * Maybe we can take the automatable parts * Wondering
                why things listed in this draft aren't just additional uses in
                the TAPS transport usage draft * I think this minimization
                exercise is useful * Think it can go a little bit further *
                Wonder if this work just results in additional columns in the
                TAPS transport usage draft * Make it useful for people trying
                to find the minimal set * As a consumer of this information, I
                would find this useful
        * Tommy Pauly
                * Folding into the usage set would make sense
                * Can be minimized further
                * E.g., I don't want to know if I'm multipath; can this be
                abstracted out? * Look creatively at how we can specify this *
                Seems like it's still making things explicit that don't need to
                be * Maybe come up with a smaller set of common things that can
                be interpreted per-protocol and maybe end up with a smaller set
        * Mirja
                * Giving guidance on how to do automation if you don't <blah>
                * <I don't know anything about this automation, which is making
                it very hard to take notes on this>
        * Michael
        * Mirja
                * Stuff on automization can be a separate draft
        * Michael
                * Seems fine
        * Aaron
                * Still trying to figure out what's going where

Colin Perkins - Transport Services for Low-Latency Real-Time Applications 10:15
        * Wolfgang Beck: Application can never guarantee a deadline (slide 4,
        10:20)
                * Colin
                        * Transports don't give the option to say "deliver this
                        if you can get it there by X, otherwise discard" * TCP
                        does not meet the requirements of the idealized
                        transport. You cannot do this with TCP.
                * Wolfgang
                        * ?
        * Kyle rose: you don't want the stream to just drop if it can't get
        there inside your SLA
                * Colin: point is to drop packets that will be useless, not
                drop the stream.
        * Colin (continuing, slide 5)
                * Need expressive dependencies (e.g., want I-frame delivered
                even if it will be late because P-frames depend on it)
        * Michael
        * Colin
                * *Can* build all of this in an application
                * But it greatly simplifies the application if the transport
                service can handle it based on semantic information from the
                application * Partially reliable SCTP is pretty close to what
                we want * Don't think there is anything that does all of this,
                but PR-SCTP is closest
        * Wolfgang
                * So, API would expose ... ?
        * Colin
                * Proposed minimal extension to sockets API
                * When you write the data you give it an identifier X, and when
                you write later you say "this depends on previous data X" *
                Allows it to choose to drop something that isn't going to be
                useful to the receiver
        * continuing slide 6, 10:28
        * Asgeir Eriksson
                * How does the receiver distinguish between "packet loss" and
                "too late"? * You say it's PR, so sometimes receiver is ACKing
                packets * Sometimes it's jumping ahead and ACKing packets * How
                does the receiver ...? * What's different from UDP?
        * Colin
                * What's different is that it can rexmit
        * Asgeir
                * <didn't catch that>
        * Colin
                * Packets arrive with timing information
        * Aaron 10:33 - take questions offline please, agenda time concerns
        * Kyle Larose
                * Working on developing a network with guaranteed timing,
                bandwidth * Intention to develop a transport that can make use
                of these lower-level features?
        * Aaron
                * Interface between what applications want and what transports
                provide * Applications can ask for capabilities
        * Spencer Dawkins
                * interest in low latency in a lot of places. it will end up in
                transport someplace, can't say if taps is right for this or not.
        * Aaron - promises to walk if this turns into a qos working group.
        * Kyle Rose - fine line between qos and what this is proposing.
        colorful latency examples.
                * Hand-waving latency between earth and moon is like 2.5 seconds
                * Setting max latency to 100ms wouldn't make sense
                * So it's up to the application to set appropriate bounds
                * But what if the route changes out from underneath you (e.g.,
                direct link from earth to moon goes down, so you have to bounce
                through Mars) * Maybe there should just be notification to user
                that real-time chat is no longer available * Really want some
                way of saying "I want at least 90% quality and minimize
                latency, unless we get below 100ms, in which case I want 100%
                quality" * Quality is app-specific * Colin - application being
                able to articulate requirements is useful
        * Michael Welzl - <missed this...>
        * Michael Ramalho remotely - has most of these in sctp. is there
        something outside of partial reliability in sctp?
                * colin: not really, sctp is pretty close to what they're
                proposing
        * Zahed
                * TAPS as a service needs to talk back to the application:
                signaling about what the transport is actually able to provide
                to the application, and signaling about when/how this changes *
                Some apps don't care about multipath vs. not, but some do *
        * Jonathan Looney, netflix: use case example: content at high scale,
        it's important for application to touch sessions as little as possible,
        needs to dump to transport layer and forget it. however, (as mentioned)
        there's times when it becomes non-useful if it took too long. lower
        bitrate for instance. in those cases, it's counterproductive to resend
        that through transport. at high scale, it's important and useful to let
        the transport handle it and raise error if there's an issue. could get
        away with not even notifying the application of failure, and leaving it
        to client in some use cases. very important, very useful.
                * Doesn't think radical API change needed
                * colin: +1
        * Tommy Pauley - feedback is important. regarding minimal subset:
        minimal subset can leave out feedback. something that would work for
        traditional semantics and also this would be great, something something
        completions. * Aaron: charter review, and what are we going to do with
        this? (10:50)
                * we've identified something not supported which would be
                useful to have in the api. * sense is that it's out of scope
                for current charter, but we don't want to lose it. strawman
                proposal: suppose we turned this into an individual draft,
                circle back to this at milestone 3, and consider can we add
                onto this?  This maybe is out of scope of charter right now.
        * Jonathan Looney
                * Recommend this topic be moved to tsv
        * Brian
                * "Yes" to Aaron's proposal to write it up here
                * Once we've seen a specification of that...
                * H/2 can use this
                * Might make sense to understand how SPDY did this
                * Sticking this in SCTP and having them look at it in 2020 or
                2021 is too slow
        * Michael
                * Completely agree with Brian (Aaron: get used to it after a
                while) * Could even see it as a way of selecting and engaging
                SCTP
        * Tommy
                * Agree that protocol specification is out of scope for this
                * Dependencies are important for TAPS to incorporate
                * If a protocol doesn't support a concept (e.g., dependencies),
                it can be grafted on top
        * Anna Brainstorm
                * Thinks we could add capabilities not supported by transport
                        * Aaron disagrees because it means TAPS gets bogged
                        down in first milestone
        * Colin
        * Brian
                * This (dependency?) can be just an API trick
                * Can be seen as an experimental support mechanism
        * Mirja
                * something about protocol-independent meaning it's reasonable
                maybe?
        * Spencer
                * Writing drafts is good
                * Encourages people to write individual drafts
                * What we're talking about is not in the current charter
                * Recharter requests that say "we've completed our work, and
                headed to new and exciting things" go a lot faster than other
                types of recharter requests * If you think this is really
                interesting, finish existing milestones first

Chairs lost track of time: now rushing through last two minutes

Tommy Pauly 10:59, running way late.
        * aaron: this is a concrete approach in milestone 3. can you do a draft?
        * tommy: sure ***
        * mirja, brian, 2 other hands offer to participate in making that draft.