Minutes IETF102: tsvarea
minutes-102-tsvarea-00

TSVAREA @ IETF-102 (Montreal)

Wednesday, July 18, 2018
15:20-16:50 - Wednesday Afternoon session II
Room: Viger
Michael Tuexen - Note-taker

* Administrativa - TSV ADs
 - Note Well, Blue Sheets, Jabber Scribes, Agenda Bashing
 - TSV Overview and status
   Spencer (remotely) and Mirja walking through the slides...
   The ADs thanked the TSV Area Review Team members for their help.
   We do have a few working groups finishing their chartered items.
   If people have new work to propose, the next couple of IETF cycles
   would be a great time to let the ADs know ...
   Kent Watson has asked for help from TSV on a proposed statement about
   application-level keepalives. Please provide feedback on the TSV-AREA
   mailing list, in the thread with subject "statement regarding keepalives"
 - TSV AD expertise and reporting/feedback from current ADs
   Aaron Falk: How much time do you need to read e-mail?
   Mirja: Trying to keep the time for AD work including e-mail down to two days
   a week. Spencer: I filter my IESG mail into "documents I'm responsible for",
   "other telechat documents", and "everything else". That helps with
   prioritizing. Also, as Mirja has mentioned a couple of times, there are
   topics that the IESG thinks about, or worries about, but we don't need 15
   people thinking and worrying on every topic. If you're the right person to
   do something, you do it, or if you're one of two or three people who care
   about something, you spend time on it, but otherwise, you don't need to be
   involved with everything that comes to the IESG. Mirja: at the beginning, it
   freaked me out a little bit, but it's doable. (Brian Trammell helpfully
   provided a pointer to Mirja's Pechakucha on becoming a TSV AD in Jabber:
   http://snaggletooth.akam.ai/IETF-097-Seoul-videos/) Spencer: If you have
   questions about anything involving the AD positions, please ask - we have
   unlimited interest in answering them!

* How hard can it be? Adding Multipath TCP to the upstream kernel - Christoph
Paasch
  Christoph going through his presentation, which is a modified version of a
  presentation given earlier in the Linux Network Developer's (NetDev)
  conference. This presentation included a description of the impact that
  protocol design decisions had on implementations - not all of which were
  recognized at the time. Using a TCP option seemed like the right thing to do,
  but had a major impact because the TCP Linux kernel implementation is so
  optimized - even adding elements to a structure can cause more cache misses
  and cause a performance impact. Aaron Falk: You said that protocol design
  directly impacts implementations.
        Shouldn't implementation constraints also influence the protocol design?
  Christoph: Yes, absolutely.
  Aaron: is the list of constraints you encountered written down anyplace?
  Christoph: not really. It's mostly mail on developer mailing lists. Writing
  it down
        would be a good thing to do.
  Aaron: You've identified a pretty big issue here - we're doing things like
  using
        Github to reduce the distance between protocol designers and
        implementers, but protocol designers are making decisions that make
        their protocols less deployable.
  Christoph: recognize that a lot of these constraints are specific to the
  Linux TCP
        implementation. Even in iOS, we kind of don't care about the same
        things.
  Brian Trammel: "TCP Options are best used for 'unreliable' signals".
        The farther away you are from the core specification, the less you can
        count on it working. There seems to be an architectural issue here.
  Christoph: How should this influence multipath in QUIC?
  Brian: this seems to be easier for QUIC with versioning.
  ????: How much of this is specific to SKBUF, and to Linux? How much is
  directly applicable
        to iOS, or to userspace implementations? Have you compared notes with
        implementors for other implementations?
  Eric: Yes, we have compared notes, but we definitely should write this down.
        It would be good to put the information out.
  Ian Sweet: In QUIC it seems simpler to evolve the stack, but we're ACKing
  packets, not
        byte sequence ranges, which makes multipath a lot simpler.
  ???: Linux has gone a long way down the road on optimizing unipath
  implementations.
        How much would it have cost if the Linux stack would have been designed
        to initially include multipath?
  Tim Shepard: There's also the question about whether the MP-TCP working group
  could
        have made different decisions. I recall a meeting where somebody
        (Michael Scharf) raised concerns. But using TCP options was very
        popular in the WG, and we went that way, and here we are. Could we do
        MP-TCPv2 that didn't use TCP Options?
  Yoshifumi: The performance is not only tied to using TCP options. If you could
        do it knowing what you know now, would you put the information in the
        payload, not as a TCP option?
  Christoph: In a clean-slate design, I would add the sequence number to the
  data stream
        and use options for the data ACKs.
  Mirja: Let's defer redesigning MPTCP to the MPTCP working group, because
  we're running
        short on time, but I'm glad there is a lot of interest on this topic.

* QUIC Internet-Scale Deployment on Linux - Ian Swett
  Ian going through his presentation, which is a modified version of a
  presentation given earlier in the NetDev conference.
???: If you ACK every packet or every other packet you might run out of send
opportunities (WiFi). ???: Do you delay the time when you create the packet, do
you delay the time when you send the packet.
                Is that a difference.
???: Who does the timestamping?
Ian: It is the release time, which is in the future.
???: Is the crypto the bottleneck or the kernel? Which offloading helps more?
Ian: If the acceleration on a platform is working well, crypto is now pretty
cheap.
        The expensive part is if you have to touch memory.

* Wire Images, Path Signals, And the (Inter)network ahead - Brian Trammell, Ted
Hardie
  - see also draft-trammell-wire-image and draft-hardie-path-signals
  Brian and Ted going through their slides.
  The IAB is looking for feedback on both of these drafts.
  Roni Even: You need to be sure you have no security and privacy issues with
  the signals. Ted: Done. A good example of this is the analysis that a QUIC
  design team did to
    determine whether the spin bit could leak geolocation information to an
    observer in the middle. After a lot of work, we learned that what you can
    determine from the spin bit is much less precise than what you can learn
    about geolocation from a variety of other sources - it's not an effective
    leak. But after you've done the analysis on your proposed bit, you can't be
    sure that this data won't be put together with other information in the
    future. This is why these bits must be optional.
  Dan: One bit per use case can be very challenging. Can we do a general
  framework? Brian: Considering the Spin was was relatively easy because there
  were no other bits
       that we had to consider interactions with.
  Dan: Need a better way, a common framework.
  Tim Shepard: Wasn't aware that the spin bit caused privacy concerns because
  you can
       discover the RTT. I'm now realizing that clients could lie about RTTs
       when they set the spin bit, if there were reasons to lie.
  Brian: Don't want to talk about this specific case...
  Ben Schwartz: How will clients make the decision to use wire frame features?
  Ted: Is the bit valuable for the client. Does the client care if the network
  observers
       can measure the RTT? For example state timers in NATs - in IPv4, you
       might want to expose the RTT to prevent rapid aging of NAT bindings, but
       in IPv6, you might say "there shouldn't be any NATs, so I won't expose
       this information". You can make decisions based on address families.
  Brian: For Diagnosis it might be important. Could be controlled via the UI
  when you're
       in debug mode - the user can enable it, if necessary, but usually leave
       it turned off.
  Lorenzo: Spin bit is opaque. Why not send every 12 packets a RTT of 12 bits.
  If you exposed
       more information, would that be more likely to give intermediate devices
       enough information to give you the policy outcomes you want to achieve?
  Brian: We haven't been able to come up with a framework for exposing more
  information. Ted: You need to consider what both ends are going to get out of
  any information they
       expose, as well as the network devices. There's a lot of information we
       collected during the spin bit analysis about specific application
       patterns, that's applicable here.
  Chris Steel:  As an operator I would like to have a few bits that tell you
  specific
       things, rather than having to infer everything.

* Open mic
  (We didn't actually have time for this - please talk to the ADs!)