Minutes interim-2020-panrg-01: Wed 17:00
minutes-interim-2020-panrg-01-202006031700-00
| Meeting Minutes | Path Aware Networking RG (panrg) RG | |
|---|---|---|
| Title | Minutes interim-2020-panrg-01: Wed 17:00 | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2020-06-08 |
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"