Minutes for TAPS at IETF-96
minutes-96-taps-1

TAPS (Transport Services) Thursday 2016-07-21 18:30-19:30
Chairs: Aaron Falk and Zaheduzzaman Sarker
Room: Bellevue
Minutes: Kyle Rose and David "Tale" Lawrence
Jabber scribe: Colin Perkins

*** Chairs update - 5min

https://www.ietf.org/proceedings/96/slides/slides-96-taps-7.pdf

Zahed: need for "northbound" information.   taps abstracts complexity as much
as possible, but apps need to know what lies beneath.
  - custom behaviour based on transport
  - need to know especially why things are not working
  - have more info about svc cost and want to tailor traffic based on that, not
  just at start but while in use later too - require session mobility, for
  addresses at either endpoint

*** Update on draft-ietf-taps-transports-usage - 10 min (Naeem Khademi of neat
project) – updated draft promised by the authors.

https://www.ietf.org/proceedings/96/slides/slides-96-taps-5.pdf

1. added some explanations clarifying nomenclature
2. Christoph Paasch contributed mptcp
3. Update "rules" to allow inclusion of experimental RFCs

TLS chairs feedback:
    - lots of docs ref TLS without describing API
    - lots of features also not described in TLS spec
    - lots of options that depend on X.509/PKIX make it a lot more complex
    Conclusion: dont have expertise or motivation within taps to write that
    section

Future plan:
      - sctp beyond RFC 4960
      - tcp experimental RFCs
      - dccp included

*** Update on draft-fairhurst-taps-transports-usage-udp - 5 min (Gorry
Fairhurst for neat) – already updated.

https://www.ietf.org/proceedings/96/slides/slides-96-taps-1.pdf

Running code with high level api, neat_{open,accept,read_write} for udp
All done with what planned to do.  Merge into -transports-usage draft?  Or keep
as separate doc? Tale: I like smaller pieces. Spencer Dawkins: fine with taking
docs through in smaller pieces.  Don't use NFSv4 as a yard stick. If there are
normative cross references, they will tend to move together. Gorry: Any reason
just to keep it as one? Aaron: Nothing substantial.

*** Update on draft-gjessing-taps-minset - 10 min (Michael Welzl also for neat)
- updated draft promised by the authors.

https://www.ietf.org/proceedings/96/slides/slides-96-taps-0.pdf

Trying to document the trade-offs for a feature-rich API covering all possible
transport features versus a simpler to grok system.

Aaron: in the interest of starting a small argument
Brian Trammell:  Dang, *I* wanted to start an argument.
Aaron: Are we going to make an effort to expose aspects of multi-path?
Brian: Hey that was my argument.
Aaron: Wait, are you saying the document is basically done?
Michael: No.
Aaron: So where's the bit about what needs to be done?
Michael: draft-ietf-taps-transports-usage isn't finished and this document
needs to grow along.

*** Investigation on the use on happy eyeballs for transport protocol selection
- 10 min (Anna Brunström, yet more neat)

https://www.ietf.org/proceedings/96/slides/slides-96-taps-4.pdf
Slides based on IRTF ANRW paper: https://irtf.org/anrw/2016/anrw16-final27.pdf

Set up three different test cases between a web app (linux) through a network
emulator (linux) to a web server (freebsd). Unencrypted and TLS encrypted, with
no caching; then with caching. Adding TLS quadruples CPU utilization, much
larger change than just adding happy eyeballs.

Overall conclusion: Happy Eyeballs is a feasible transport selection mechanism,
especially with caching. tsv lib with HE on http://github.com/NEAT-project/neat
See draft-grinnemo-taps-he

Tommy Polly:  How realtime are these?  Simultaneous?
Anna: Yes
Tommy: Apple experience is that staggered races seem to mitigate a lot of CPU
overhead factors.  Can we do something like that? Anna: Try your preferred
protocol a little bit earlier, but initiate the backup just in case the
preferred protocol doesn't work Tommy: In addition to a priori preference would
like to have some kind of learning. Anna: Caching allows you to remember when a
recently-tried protocol didn't work, so you don't try it again too quickly

Steven ?: Not going to answer the question but want to make some trouble:  how
do you manage it in app layer vs network layer?  Realtime apps do it with ACE,
but it's a bit messy.  Can something cleaner come out of taps? Anna: this is
why we started with sctp

Tommy: We have some experience with double happy eyeballs between address
families and interfaces.  Now here's a third layer.

Varun: ICE working group had similar results.  Colin Perkins(?) did some
experiments with this on NAT.  The number of combinations was really large
though, so it made a huge amount of traffic just for connections.  UDP and not
congestion controlled, so all you could check was the timer.  This sort of
thing seems to really demand congestion control for feasibility.  If you come
up with guidance on HE here, ice would take it into their wg.

Colin: Yeah this is essentially ice, so there is some scope for co-operation.

*** Post socket - 10 min (Brian Trammell)

https://www.ietf.org/proceedings/96/slides/slides-96-taps-2.pdf

SOCK_STREAM is yesterday's interface.   Limited, but it makes the network look
like a file, so simplicity wins (or won, at least in the 1970s). Really good
interface for getting a tape from one side of the room to the other.

SOCK_SEQPACKET, "tomorrow's interface, yesterday".  Solves a lot of problems
but is bound to sctp which hasn't succeeded.

Some insights or assumptions:
    Apps deal in objects/messages, ordering not as important  Let transport
    solve optimization. Network of future is explicitly multipath. Future
    transports demand security Message reception is already inherently async

taps lets you select transport but if each one has its own API, not useful.
neat api is one solution, but if apps have to change anyway then PostSockets is
an alternate, more radical approach that can be used. Read Colin's paper about
my [Brian's] awesome API.

Colin: related - the last presentation coming in the session; also, Clark and
Tennenhouse paper on ALF (SIGCOMM, ’85?) Tommy: I think this great and I like
your model; the tricky thing is to get everyone to agree on it and use it. 
Early on you need to get implementers on it.

*** Socket intents, Leveraging Application Awareness of Multi-Access
Connectivity - 5 min (Philipp Tiesel)

https://www.ietf.org/proceedings/96/slides/slides-96-taps-3.pdf

Want to be able to have application specify the intent of the socket.  Tried
minimal approach modifying addinfo struct to bsd socket api. For connection
reuse though really need a different api to connect, choose or release. On
github https://github.com/fg-inet/socket-intents

*** Implementing Real-Time Transport Services over an Ossified Network - 10
miin (Stephen McQuistin)

https://www.ietf.org/proceedings/96/slides/slides-96-taps-6.pdf
Also https://irtf.org/anrw/2016/anrw16-final25.pdf

Name?: Something about SCTP?
Brian: Really awesome stuff.  Looks like you're now drafted to get into the
group of stack people to make it better.  Would like to see larger scale
measurements.

Aaron: Thanks everybody for staying late.  Looking forward to Korea and will
try to get a longer slot.

close()
reap()