Minutes interim-2020-panrg-01: Wed 17:00
|Meeting Minutes||Path Aware Networking RG (panrg) RG|
|Title||Minutes interim-2020-panrg-01: Wed 17:00|
|Other versions||plain text|
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"