Minutes interim-2020-panrg-01: Wed 17:00
minutes-interim-2020-panrg-01-202006031700-00

General Notes:
    - no agenda bashing required
    - moving to twice yearly virtual meets
    - three drafts for discussion today

Open Questions in Path Aware Networking
B. Trammell
        - overview of diffs between draft 03 and 04
        - since SIN,
                - some feedback on making sure language and vocab articulates
                what we mean - path element (properties) have temporal scope
        - Brian would like to ask the RG "do we have consensus on the draft?",
        possibly take a snapshot and later do a retrospective?
                - Spencer: Good enough list to publish; explains research
                questions to those outside of RG - Theresa: maybe RGLC - Gorry:
                Do we have to think about defaults, and signals for
                non-defaults?
                        - Brian: happy to leave it implicit
                        - Gorry: agree

Vocabulary of Path Properties
T. Enghardt, C. Krähenbüh
        - overall no change to path definition, but attempted further clarity
        about individual aspects
                - admits all notions of path from physical, up to just
                source-destination pair
        - added "reverse path"
        - minor structural and textual changes to Use Case section
                - measurement aspects removed; viewed as independent of
                protocol and service selections
        - 2 new path properties:
                - "Transparency" doesn't modify stuff
                - "Symmetric Path" where path and reverse path consist of the
                same path elements; but in reverse order
        - Security
                - Difficult to characterize security properties
                - Security properties are orthogonal to path properties
        - Minor modifications to Access Technology and ???
        - Questions?
                - Authors would like specific feeback on Transparency Property
                and ne Security Considerations
        - Gorry: You invented the terms path and reverse path, this seems to be
        based on routing view. But paths can have other properties that make
        them not symmetric - could be symmetric-routing? other properties can
        differ.
          - Cyrill: we try not to make to many qualifications
          - Gorry: prefer something slightly different. Service functions don't
          require a symmetric path - they just need to be able to observe both
          directions of the flow (not even necessarily observing in the same
          place - and possibly the forward/reverse path can differ after the
          function). Asking just to make sure authors are thinking about this.
        - Brian: picking on slide 5. Everything Gorry said, Brian was going to
        say. Previous life worked on path transparency. Transperency might be
        looking at headers without changing them and that can affect protocols.
        There might be more shades of grey, at least three. Add some nuance.
        (Cyril: blocking or not blocking) Yes, that as well. Other kinds of
        behavior changes as well. - Spencer: follow-on question about symmetric
        paths. Is it symetric in the same level of abstraction?
                - Cyril: yes


Path Aware Networking: Obstacles to Deployment (A Bestiary of Roads Not Taken)
S. Dawkins
        - changes since -04 (at IETF 106), now up to -08
                - could be finished but are we
        - Comments a couple of times: what is "Path Aware Networking exactly?"
        - Sec 1.2 text added "A Note about..."
        - -04 rev of questions draft lists two important properties
        - path-properties-00 also has an opinion
        - do we have a canonical definition? do we need one?
                - if we have it, where does it go?
        - Questions/discuss
                - Theresa: yes we should hae a definition, thinks the questions
                draft is ok. A review comment on path properties suggested
                there may be a need for an architectural document but not sure
                that's a good idea. The definition probablydoesn't beong in the
                path properties draft Brian: personal take is no we do not need
                a canonical definition. The questions draft lays out an
                approach to research. Looking across docuements the questions
                are asked in different ways. MAybe the whole questions document
                *is* the definition. Being amorphous is useful. Would be fine
                adding one paragraph somewhere, a standalone I-D may be
                onerous. - Spencer: work together and put it in the questions
                draft, then cite questions in this one
                        - Brian: all 3 drafts are far more aligned than
                        different - still worth discussion off-line - Spencer:
                        perhaps used the term canonical where it doesn't quite
                        fit, perhaps a better way to think is a single place
                        for what we think is going on - Theresa: agreed,
                        canonical not needed; suggests referring to charter -
                        Brian: notes that more definitions exist than
                        documents, so some cleaning up needed - Gorry: some
                        text would be useful to refer to, in response to views
                        that transport is purely e2e
        - Reasons to publish this draft Seal Soon
                - informational drafts are intended to inform: research *in*
                the RG, research *outside* the RG, and *engineering outside*
                the RG - are we done? if not, what else?
                        - Brian: we're done modulo the changes we might want to
                        make regarding canonical definition. With chair hat,
                        that seems to mean the next draft is GTG (because its
                        already been through LC)

Path Aware Networking: Research Goals
S. Dawkins
        - how to recognise a 'good' approach to PAN?
                - useful "beautiful baby" analogy to keep in mind
        - do we already have design goals? We learned a lot in what-not-to-do.
        That draft was backwards-facing. - been asked to capture what *to* do -
        Scalable Routing is a benchmark. Routing RG thought there were design
        goals and published RFC ???? and ???. - Is something like RFC 6227 a
        good model?
                - Spencer thinks agreeing what were trying to accomplish would
                be a good thing
        - Discuss/Questions
                -Brian: refreshing memory of RFC 6227. The goals need to solve
                questions  2.2 and 2.3. Need an interface related to
                implmeneting. And there are higher order bits. Do't want to
                stuff design goals into a questions draft. To some extent, the
                reason some people care about PAN is related to scalable
                routing. E.g. SCION for routing scalability, traffic
                engineering is similar to QoS, multihoming. How many goals are
                actualyl PANs goals (because we still have the problems to
                solve)? Use 6277 as a pattern but it seems like an attempt to
                boil the ocean,lets be cautious with trying to solve all points
                at once
                        - Spencer: mostly agree, but worth teasing out details
                        from Sections 2 and 3 may serve as starting point for
                        design aspects. Separately, RRG origins were facing
                        greater pressures than those facing PANRG - Brian:
                        based on sections 2 and 3, we have a good sense of what
                        not to do, but indeed there's no clear sense of what
                        *to* do - Theresa: problem statement for scaleable
                        roting might be more narrow than PAN. Wondering if a
                        place to start is looking at existing successful Path
                        aware technology. See email from January sent to the
                        list. - Spencer: this work may not be as under the gun
                        as impending routing table explosions.
                - Colin: Risk of 'design goals' constraining any output or
                architecture; perhaps 'principles' or 'guidelines' is better
                suited to spirit of question?
                        - Spencer: ideal would be something akin to '*some*
                        design goals' - Colin + Spencer: exchange that leads to
                        agreement about examples, or notions of possibility
                - Russ: the situation between this group and RRG is different.
                Think we have a different goal, if we can do something to
                document PAN, what are the benefits to applications that use
                it. Perhaps an ordered list of goals, and not all of those fit
                the same puzzle.
                        - Spencer: this is what happens when you take puzzle
                        pieces and use them as LEGO
                - Brian:seems there is appetite to do something, take it
                backout to the list

ETOSAT Update
G. Fairhurst
        - Understanding ACKS using High BDP Paths. Not quite all about PAN yet,
        but maybe that's where we'll get
                - particularly where paths are asymmetric
        - analysis using some spreadsheets, and some software (quicly, and
        chromium) using Reno - return paths are not allthe same:
                - bit-congestive paths - asymmetric available capacity, shared
                capacity (contention ratios) - packet-congestive paths -
                asymmetric "cost" of transmission
        - TCP is recommended to ack every-other-segments, which turns out to be
        too much for some networks. In actuality there are stretch acks that
        tend to be done by offload cards or in-network devices. Maybe even wifi
        chipsets
                - useful to look at ACK traffic data as a percentage of
                forwarddata traffic - QUIC generates ~2x ack traffic vs TCP -
                "ack-thinning" reduces to 10% from original
        - Evaluations with a set of widely respresentative paths (wifi to
        satellite); ack-thinning is common practice
                - cases emerge where send rate is limited by return (ack) rate
        - packets containing acks can consume uplink capacity
        - QUIC as designed is not helping, it squeezes out traffic on the
        return path too - Plot of how ACK ratio can affect traffic flow when
        varying capacity/asymmetry and using BBR - Plot of how ACK ratio can
        affect traffic flow when varying capacity/asymmetry and using Reno -
        Message: acks affect throughput, if we can't thin QUIC acks in the path
        what to do - What about a higher ack ratios? They can benefit high
        transmission rates but it might side effects (> 1:10 cann affect CC or
        loss recover). The optimum choice may be impacted by the path. - What
        happens if there is too much ACK traffic? link can't see inside QUIC
        packets by design, a queue build and the return gets congested - Could
        configure a short outer queue, may have compication and/or implications
        - Suggestion that Ack ratio 1:10 would avoid a lot of mess


Google QUIC over Satellite Testing Update
J. Border
        - Follow up to early data that was presented
        - Refresh of problem statement
        - Overview of test setup and testing variants
        - Results: with no packet loss spoofing works pretty well but H2 and
        QUIC suffered. Packet loss affect things as expected. Without PEP
        things are pretty slow as expected.
                -Brian: results table. two interesting things 1) PEP effect on
                QUIC 2) direct path, QUIC does pretty well in spite of packet
                loss - better than TCP even
                        - John: would like QUIC to be as good as TCP with PEP.
                - Gorry: are you going to remeasure?
                        -John: getting a testbed with h2o server built up and
                        definately going to get more data
                - Spencer: where do you want additional disucssion to take
                place?
                        - John: so far in ETOSAT, wanted to get something more
                        concrete before taking to QUIC WG - Spencer: aiming for
                        testing draft 28? - John: yes - Spencer: we're
                        interested in testing this stuff too

Updates on QUIC Over In-sequence Paths with Different Characteristics
N. Kuhn
        - Satellite can be strange but they are just one part of strangeness
        - Overview of typical GEO satellite-based internet access: data rate,
        latency and loss
          - Paths with very different characteristics. So this makes things
          complex for end-to-end protocols when local break-out is not possible
                        - Solution 1) adapt protocols
                        - Solution 2) inform endpoints of path characteristics
        - Testing solution 1 on end-to-end path with/without split
                - using picoquic client and h2o server, and also curl client
        - With TCP proxy, tuning buffer sizes allows to reach the capacity
        - Experiment found an issue with h2o server due to many retransmits.
        Switching to picoquic server showed differences cause by different CC
        algorithm or transport parameters - picoquic clent and server work
        pretty well together, other combinations fail to meet objectives in
        some cases - solution 2) see draft-kuhn-quic-0rtt-bdp-06 - overview
        table on why picoquic meets objectives compared to other
        implementations - next steps
                - further work on the parameters that are game-changing for
                satellite use cases - implement 0rtt draft - see if picoquic
                implements thigns that would be useful to others
        - integrate other QUIC implementations
        - release code used so far
        - Questions
                - Spencer: thanks for doing this work and presenting it in
                PANRG, which is the right place to present it - Lucas: testing
                H3, with the same goal (large file transfer). Curl has two QUIC
                backends, which one? - Nicolas: just using default picoquic +
                H2. ngtcp2 backend in curl. - Jana: picoquic not violating
                spec, each tool matches what the client uses (in transport
                params). just an implementation difference example. question to
                consider: what is the cost of doing these things? you could
                have a 9kB max packet size, but has a cost in availability.
                Everything done here (also CC) has to work on Internet paths
                that don't have a satellite subpath on them. Implementations
                moving rapidly, please publish commit IDs with results. Please
                keep doing these measurements. QUIC endpoints and network can't
                communicate about the presence of a satellite path; encourage
                to focus on endpoint behaviors that work both on satellite
                networks and the public Internet. - from Colin in Jabber: "It’d
                be nice to get a short draft explaining why it’s more critical
                to give precise version information with QUIC than with TCP,
                since I see a lot of papers/results lacking this detail." - in
                chat: Francois Michel: This does not need to be discussed here
                but: maybe you would be interested in comparing the maximum
                receive window of your QUIC client if you haven't done it
                already (maybe I missed it), this can also have an impact on
                the download speed. I know that picoquic's max receive window
                can grow and take the whole memory, I don't know for the others.

Classification Problems with Encrypted Paths
J. Border
        - Classification is primarily based on transport header and application
        header informations - The first Mile:
                - for network operators, traffic classification is important
                for meeting customer expectations - the last mile is really the
                first mile, when it comesto classification
                        - the network for which cladssifciation is most
                        important is the one that ned user is directly
                        connected to - prioritizing different traffic may event
                        need to be aware of multiple paths with different
                        characteristics
        - Encryption is a good thing, but makes some classification difficult
        - Signaling the path
                - Can end user device signal the "firtst mile" ?
                - DSCP one option. MASQUE-like technique is another option
        - Discussion/comments/questions/observations?
                - Gorry: please read my draft in TSVWG on encryption. I'm happy
                to work with you.
                        - John: can we make the path aware of the
                        classification where its needed, and then drop it -
                        Gorry: do we need to drop it? - John: DSCP is designed
                        to drop at the edge - Gorry: I think you should write a
                        draft
                - Spencer: I think you should write a draft, too. Please let me
                know if we can help Spencer: is evolving question of trust in
                scope of RG? are we aying it is ok to dig in this area?
                        - Brian: It's alluded to in the research-questions
                        draft, and in scope for the research group
                - Colin: issues about trusting endpoints that classify their
                traffic. Has the state of the art in traffic classification got
                good enough to be able to reliably tell if such endpoints are
                telling the truth? - Chris: PEARG is considering some things.
                Encourage you to go check it out. - Brian: would be good to get
                input from people in the security monitoring space, where lots
                of work over the past decade has gone into flow-level
                behavioral analysis, which would be useful in verifying
                trustworthiness of signaling. - John: wondering how ACK / ACK
                padding will affect attempts to pattern match flows in order to
                classify them. - Chris: expect to see more use of padding in
                the future. Can't say how painful that will be, because this is
                coming. - Jana: second what Chris said, a lot of movement in
                this area. Lots of things continue to use stuff like SNI but
                there is a push to reduce that. Classifiying using those hooks
                might be harder in future. - John: (agreeing nad identifying
                that this is a challenge) - Jana: perhaps that is something for
                the RG to consider


Application-aware Networking and Path Awareness
P. Liu

- APN6 wants to add application knowledge to network layer in order to enable
finer granularity. Augment programmability provided by IPv6/SRv6 - Challenges
for traditional differentiated service provising
        - packets can't carry enough information
        - network devices mainly rely on 5-tuple or DPI
        - SDN has challenges
- APN6 aims to convey the application information into the network
infrastructure and allow the network to quickly aapt and perform actions
necessary to meet SLA. - Overview of APN6 Elements and Framework - Overview of
advantages - Overview of use cases - Pverview of security concerns - Upcoming
BoF at IETF 108 - Relationship between PAN and APN and considerations -
Questions
        - Wes (from webex chat): essentially: what sort of application ids are
        you transmitting? It would seem to handle privacy better if you sent
        network requirements, rather than sending more specific information. -
        Brian: what are the semenatics? Is it like "this is web traffic", "this
        is video traffic"? What are the semantics of the application ID. Colin
        makes the point that many applicatiosn send different types of traffic.
        Knowing what the application is may not be enough to classify. - Peng
        Liu: ??? - Wes: asking what you need f the netwrok is hgeneraly better
        than saying "I am X, please help me"