Skip to main content

Minutes IETF103: panrg
minutes-103-panrg-00

Meeting Minutes Path Aware Networking RG (panrg) RG
Date and time 2018-11-07 06:50
Title Minutes IETF103: panrg
State Active
Other versions plain text
Last updated 2018-11-18

minutes-103-panrg-00
Agenda bashing
--------------
Since last IETF, Brian posted updated version of open
questions draft. No major changes.  Discuss next meeting,
when Brian is back.

Spencer's document on what we should not be doing has been
adopted.

A Vocabulary of Path Properties
-------------------------------
draft-enghardt-panrg-path-properties

How are path properties defined and represented?  Draft
lists useful and relevant path properties and classify them
into three categories

Domain properties are properties that relate to
characteristics close and strongly influenced by the
endpoint (first few hops of a path, for example).  Tend to
have a high amount of information.

Backbone properties less influenced by endpoint.  Likely to
stay constant within the lifetime of a connection.  For
example, MTU, protocol availability, persence of certain
devices/ASes.  Change on order of hour or days.

Lars Eggert asked for definition of path (not in draft).  Is
scope of a path within the lifetime of a packet?  Each
packet has a path associated with it.  If a path is
associated with a single packet, it cannot be dynamic.

Dynamic properties:  mostly end-to-end, change frequently.

Rick Taylor asked about per-link technologies telling upper
layer what's going on.

Dynamic properties include available bandwidth, RTT, packet
loss, congestion, etc.

Lars Eggert said this is a shopping list of stuff to do with
path, needs more formalism.  If a path is something
associated with a single packet, what does "bandwidth" mean,
for example.  Theresa:  first step was to see what we have
and what is actually useful.  Next step is to introduce more
formalism.  Lars:  Start with your definition of "path."

Gorry Fairhurst:  I used to work on modems, and nearly
everything on that list can be changed.  All of these are
useful for knowing what happened last time but not for what
will happen next time.  This is quite ambitious but you may
need to be more abstract.  Use "capacity" rather than
"bandwidth"

Rick Taylor: I think this is valuable work but a lot of
these per-link properties can be represented at a higher
layer.  Recommend looking at some radio-related
specifications.  This is valuable but there's a lot of
engineering that has already happened.  This (link-layer
information) should be more abstract.

Adrian Farrell:  There's good stuff here, in the shopping
list sense.  There's work that needs to be done on how it's
collected.  There's IETF work on how to aggregate info.
There are also "connections" and "routes" and unless you
nail this right up front it's real soup.

Mirja Kuehlewind: For network metrics we have a lot of work
in IPPM.  Next step is bringing this on a flow level and
defining what a "flow" is.

Rick Taylor: RFC 8175 allows you to get per-QoS metrics

Questions:  1) anything missing, 2) categorization works, 3)
representation, 4) adoption

Gorry Fairhurst: What's the motivation for collecting the
data and does that change why you're collecting it?  A: for
path selection.  Gorry:  People like IPPM have very
different motivations - did my path work (satisfy SLA?).
You want to predict how the path will work - that's a
different set of data.

Jen Linkova: You (Gorry) mentioned a question from Brian's
questions draft

Brian Trammell: To answer Gorry's point, I think there is
indeed an element of predicting the future here.  Is there a
way we can get it within a certain degree of accuracy that
would be useful

Giovanni from TU Delft:  It would be useful to look at the
definition of path in ATM

Spencer Dawkins:  Adoption in a RG is adoption for an RG to
work on.  Adoption means responsibility to the RG and RG's
responsibility to the author.  The other thing to mention is
that it's helpful to think about is that this is going to
help us have a shared understanding when we start talking
about what to do and stop talking about what not to do.

Lars Eggert:  Gorry made excellent points.  When you don't
know what your units are you don't know what you're
measuring.  If your formalism is good enough they would just
fall out of it.  Ref. IETF alto working group.  If
alto couldn't do it, something more complex is daunting.
You can be worse than random if you're wrong.

(missed name) identify statistical properties.  If you
collect more information it will probably become obsolete
faster

Jen:  I am getting mixed feelings from the room about
adoption.  The draft needs to be edited for clarity


Obstacles to Deployment
-----------------------
Draft has been adopted by RG, led to name change.

Don't describe every idea, but capture every lesson

New summary of lessons learned.  Ones in red (see slides)
are ones added since previous meeting.

Gorry Fairhurst: some routers do process in-band signals in
hardware (disagreeing with slide).  Processing path is not
the same when you put hop-by-hop options on a packet

Colin Perkins: takes issue with *have* to trust each other.

Spencer: slide on summary of edits

Adrian:  the word you're looking for for RSVP is filterspec

Mirja: I think the lesson of those three protocols is the
lesson of ECN, which is that if the deployment is
complicated and the incentives are not clear, it's hard.
Also, Lars was kind of keen on writing something about alto

Lars: since alto came up ...  it was a pressing problem at
the time.  P2P was killing operator networks, so there were
incentives for everybody and we still couldn't deploy it.

Mirja:  That was my point.  It was not the incentives in
that case.  (Somebody has to write it down, still)

Spencer:  One goal for this draft is that we can use it to
spot proposals that might trip over known obstacles

Lars: With MPTCP, because it was using multiple paths in
parallel and coupling to control loops, operators were
concerned that users could do real-time comparisons and it
might make them look bad.

Theresa Enghardt: I find it interesting to know what
resistance MPTCP met, and I'm wondering what sort of draft
would this lesson belonging in.

Spencer:  People have been suggesting what-to-do ever since
he started his what-not-to-do draft.

Spencer's understanding of where the goalposts are:  I'd
like for this to useful advice from panrg to the IETF.
There's no reason to think the IETF will nto "learn these
lessons again". Have we learned things for which Brian does
not have an open question?

Theresa:  I just looked at the questions draft again.  We
want to do path selection on the endpoint so learning from
our mistakes is applicable to section 2.3 in the questions
draft

What next?  we could look at current path-aware proposals,
we could compare the draft to panrg-questions, we could
reasonably finish the draft and publish it.

Gorry:  I can see reasons why we might publish it for
another audience.  People keep saying we need to bring stuff
to the IETF.  It would be kind of useful to have a document
that would be completely informational explaining what
happened

Spencer: there was a HotRFC talk about LOOPS.  We talked
about it at their side meeting and I was pointing them at
this draft in its current form

Theresa:  If I remember correctly at the last panrg, this
group is very transport-focused and we could use more
routing people.  Are there routing people in the room?
(yes)

Mirja:  I agree with Gorry.  This has archival value -
there's institutional memory in the draft.

Markku Kojo: Draft written with Sally Floyd on cross-layer
considerations. 


Overlayed path segment forwarding problem statement
---------------------------------------------------

Motivation:  Leverage cloud router nodes for best path
selection (provide performance closer to leased lines).
Physical location matters but is not always the primary
factor.

Problem 1: Slow loss recovery over long haul

Problem 2: Inaccuracy in sending rate decrease at sender

Rick Taylor: what is the difference between a cloud internet
and a complex transit network?  A: the network transited by
the overlay we call a cloud network.

Alia:  It's a private network, only people can connect in
privately or via VPN.  Inside cloud provider they have their
own connectivity.  They're not providing transit but they
can look kind of like a transit network

Colin:  Is there also an assumption that you're doing
(packet) processing in the cloud or are you just using them
as a routing overlay?

Localized Optimizations on Path Segments (LOOPS) for better
reliability and throughput

Adrian: I want to poke again at the definition of the word
"path."  Your picture is fine, the labels on your picture
upset me.  Maybe what are labeled as path segments should be
"tunnels."

Three elements of a solution:  1) local recovery, 2)
congestion control interactions, and 3) traffic splitting
and recombination

Lars:  The presentation is way too broad. The key to this is
signaling in combination with transport

Rick:  Is LOOPS a signaling protocol between tunnels?  A:
it's an overlay-based mechanism.

Alia:  feedback loop between layers is interesting.  You're
saying that because it's a tunnel it takes only a single
path through the network.  That doesn't make sense to me.

Spencer:  focus on the path parts of this.  Whatever anybody
else can help you with, panrg can help you with the path
questions.

Future work includes architecture, and information model for
data encapsulation and measurement, congestion control, and
guidelines for interaction with e2e congestion control.