Agenda bashing--------------Since last IETF, Brian posted updated version of openquestions draft. No major changes.  Discuss next meeting,when Brian is back.Spencer's document on what we should not be doing has beenadopted.A Vocabulary of Path Properties-------------------------------draft-enghardt-panrg-path-propertiesHow are path properties defined and represented?  Draftlists useful and relevant path properties and classify theminto three categoriesDomain properties are properties that relate tocharacteristics close and strongly influenced by theendpoint (first few hops of a path, for example).  Tend tohave a high amount of information.Backbone properties less influenced by endpoint.  Likely tostay constant within the lifetime of a connection.  Forexample, MTU, protocol availability, persence of certaindevices/ASes.  Change on order of hour or days.Lars Eggert asked for definition of path (not in draft).  Isscope of a path within the lifetime of a packet?  Eachpacket has a path associated with it.  If a path isassociated with a single packet, it cannot be dynamic.Dynamic properties:  mostly end-to-end, change frequently.Rick Taylor asked about per-link technologies telling upperlayer what's going on.Dynamic properties include available bandwidth, RTT, packetloss, congestion, etc.Lars Eggert said this is a shopping list of stuff to do withpath, needs more formalism.  If a path is somethingassociated with a single packet, what does "bandwidth" mean,for example.  Theresa:  first step was to see what we haveand what is actually useful.  Next step is to introduce moreformalism.  Lars:  Start with your definition of "path."Gorry Fairhurst:  I used to work on modems, and nearlyeverything on that list can be changed.  All of these areuseful for knowing what happened last time but not for whatwill happen next time.  This is quite ambitious but you mayneed to be more abstract.  Use "capacity" rather than"bandwidth"Rick Taylor: I think this is valuable work but a lot ofthese per-link properties can be represented at a higherlayer.  Recommend looking at some radio-relatedspecifications.  This is valuable but there's a lot ofengineering that has already happened.  This (link-layerinformation) should be more abstract.Adrian Farrell:  There's good stuff here, in the shoppinglist sense.  There's work that needs to be done on how it'scollected.  There's IETF work on how to aggregate info.There are also "connections" and "routes" and unless younail this right up front it's real soup.Mirja Kuehlewind: For network metrics we have a lot of workin IPPM.  Next step is bringing this on a flow level anddefining what a "flow" is.Rick Taylor:RFC 8175 allows you to get per-QoS metricsQuestions:  1) anything missing, 2) categorization works, 3)representation, 4) adoptionGorry Fairhurst: What's the motivation for collecting thedata and does that change why you're collecting it?  A: forpath selection.  Gorry:  People like IPPM have verydifferent motivations - did my path work (satisfy SLA?).You want to predict how the path will work - that's adifferent set of data.Jen Linkova: You (Gorry) mentioned a question from Brian'squestions draftBrian Trammell: To answer Gorry's point, I think there isindeed an element of predicting the future here.  Is there away we can get it within a certain degree of accuracy thatwould be usefulGiovanni from TU Delft:  It would be useful to look at thedefinition of path in ATMSpencer Dawkins:  Adoption in a RG is adoption for an RG towork on.  Adoption means responsibility to the RG and RG'sresponsibility to the author.  The other thing to mention isthat it's helpful to think about is that this is going tohelp us have a shared understanding when we start talkingabout what to do and stop talking about what not to do.Lars Eggert:  Gorry made excellent points.  When you don'tknow what your units are you don't know what you'remeasuring.  If your formalism is good enough they would justfall out of it.  Ref. IETF alto working group.  Ifalto 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 youcollect more information it will probably become obsoletefasterJen:  I am getting mixed feelings from the room aboutadoption.  The draft needs to be edited for clarityObstacles to Deployment-----------------------Draft has been adopted by RG, led to name change.Don't describe every idea, but capture every lessonNew summary of lessons learned.  Ones in red (see slides)are ones added since previous meeting.Gorry Fairhurst: some routers do process in-band signals inhardware (disagreeing with slide).  Processing path is notthe same when you put hop-by-hop options on a packetColin Perkins: takes issue with *have* to trust each other.Spencer: slide on summary of editsAdrian:  the word you're looking for for RSVP is filterspecMirja: I think the lesson of those three protocols is thelesson of ECN, which is that if the deployment iscomplicated and the incentives are not clear, it's hard.Also, Lars was kind of keen on writing something about altoLars: since alto came up ...  it was a pressing problem atthe time.  P2P was killing operator networks, so there wereincentives for everybody and we still couldn't deploy it.Mirja:  That was my point.  It was not the incentives inthat case.  (Somebody has to write it down, still)Spencer:  One goal for this draft is that we can use it tospot proposals that might trip over known obstaclesLars: With MPTCP, because it was using multiple paths inparallel and coupling to control loops, operators wereconcerned that users could do real-time comparisons and itmight make them look bad.Theresa Enghardt: I find it interesting to know whatresistance MPTCP met, and I'm wondering what sort of draftwould this lesson belonging in.Spencer:  People have been suggesting what-to-do ever sincehe started his what-not-to-do draft.Spencer's understanding of where the goalposts are:  I'dlike for this to useful advice from panrg to the IETF.There's no reason to think the IETF will nto "learn theselessons again". Have we learned things for which Brian doesnot have an open question?Theresa:  I just looked at the questions draft again.  Wewant to do path selection on the endpoint so learning fromour mistakes is applicable to section 2.3 in the questionsdraftWhat next?  we could look at current path-aware proposals,we could compare the draft to panrg-questions, we couldreasonably finish the draft and publish it.Gorry:  I can see reasons why we might publish it foranother audience.  People keep saying we need to bring stuffto the IETF.  It would be kind of useful to have a documentthat would be completely informational explaining whathappenedSpencer: there was a HotRFC talk about LOOPS.  We talkedabout it at their side meeting and I was pointing them atthis draft in its current formTheresa:  If I remember correctly at the last panrg, thisgroup is very transport-focused and we could use morerouting 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-layerconsiderations. Overlayed path segment forwarding problem statement---------------------------------------------------Motivation:  Leverage cloud router nodes for best pathselection (provide performance closer to leased lines).Physical location matters but is not always the primaryfactor.Problem 1: Slow loss recovery over long haulProblem 2: Inaccuracy in sending rate decrease at senderRick Taylor: what is the difference between a cloud internetand a complex transit network?  A: the network transited bythe overlay we call a cloud network.Alia:  It's a private network, only people can connect inprivately or via VPN.  Inside cloud provider they have theirown connectivity.  They're not providing transit but theycan look kind of like a transit networkColin:  Is there also an assumption that you're doing(packet) processing in the cloud or are you just using themas a routing overlay?Localized Optimizations on Path Segments (LOOPS) for betterreliability and throughputAdrian: I want to poke again at the definition of the word"path."  Your picture is fine, the labels on your pictureupset 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 splittingand recombinationLars:  The presentation is way too broad. The key to this issignaling in combination with transportRick:  Is LOOPS a signaling protocol between tunnels?  A:it's an overlay-based mechanism.Alia:  feedback loop between layers is interesting.  You'resaying that because it's a tunnel it takes only a singlepath through the network.  That doesn't make sense to me.Spencer:  focus on the path parts of this.  Whatever anybodyelse can help you with, panrg can help you with the pathquestions.Future work includes architecture, and information model fordata encapsulation and measurement, congestion control, andguidelines for interaction with e2e congestion control.