[{"author": "Daniel King", "text": "We have an Etherpad I think for minutes.
", "time": "2022-06-21T14:58:17Z"}, {"author": "Daniel King", "text": "Or equivalent.
", "time": "2022-06-21T14:58:26Z"}, {"author": "cabo", "text": "https://notes.ietf.org/notes-ietf-interim-2022-rtgwg-01-rtgwg
", "time": "2022-06-21T14:59:07Z"}, {"author": "Daniel King", "text": "https://notes.ietf.org/notes-ietf-interim-2022-rtgwg-01-rtgwg
", "time": "2022-06-21T14:59:10Z"}, {"author": "Tony Przygienda", "text": "metaverse needs semantic routing ? huha, anyone let zuck know yet ;-) ?
", "time": "2022-06-21T15:02:10Z"}, {"author": "Lixia Zhang", "text": "Is the slides available online? The display a bit too small to view
", "time": "2022-06-21T15:05:01Z"}, {"author": "Dirk Trossen", "text": "@Lixia at https://datatracker.ietf.org/meeting/interim-2022-rtgwg-01/session/rtgwg
", "time": "2022-06-21T15:05:31Z"}, {"author": "Carsten Bormann", "text": "We could view the slides in slide deck mode.
", "time": "2022-06-21T15:05:55Z"}, {"author": "Carsten Bormann", "text": "Thanks
", "time": "2022-06-21T15:06:37Z"}, {"author": "Lixia Zhang", "text": "@DirkT thanks!
", "time": "2022-06-21T15:09:16Z"}, {"author": "Lixia Zhang", "text": "Thanks!
", "time": "2022-06-21T15:09:45Z"}, {"author": "Adrian Farrel", "text": "Slide not moved on
", "time": "2022-06-21T15:11:47Z"}, {"author": "Adrian Farrel", "text": "ok
", "time": "2022-06-21T15:12:01Z"}, {"author": "Adrian Farrel", "text": "I think Dan can't hear and talk at the same time :-) It's a device driver thing
", "time": "2022-06-21T15:20:34Z"}, {"author": "John Scudder", "text": "@JeffT, I believe Dan mentioned his audio setup is half-duplex so the not talking over eachother is a bit difficult I guess. :-(
", "time": "2022-06-21T15:20:36Z"}, {"author": "Jeff Tantsura", "text": "thanks!
", "time": "2022-06-21T15:20:51Z"}, {"author": "Tony Li", "text": "I'm getting some background noise.
", "time": "2022-06-21T15:25:34Z"}, {"author": "cabo", "text": "A lot.
", "time": "2022-06-21T15:25:46Z"}, {"author": "Anthony Somerset", "text": "Philip's background noise
", "time": "2022-06-21T15:26:08Z"}, {"author": "Adrian Farrel", "text": "Has his slide advanced?
", "time": "2022-06-21T15:26:33Z"}, {"author": "cabo", "text": "No.
", "time": "2022-06-21T15:26:45Z"}, {"author": "Roland Bless", "text": "I think that we do not see the correct view.
", "time": "2022-06-21T15:26:51Z"}, {"author": "Tony Li", "text": "Please go full screen too, thx.
", "time": "2022-06-21T15:27:11Z"}, {"author": "cabo", "text": "Please use meetecho's slide mode
", "time": "2022-06-21T15:27:13Z"}, {"author": "cabo", "text": "Do not screen share.
", "time": "2022-06-21T15:27:24Z"}, {"author": "Daniel King", "text": "Maybe sharing the wrong screen?
", "time": "2022-06-21T15:27:28Z"}, {"author": "Anthony Somerset", "text": "hide the ribbon by clicking the up arrow at bottom right of the ribbon
", "time": "2022-06-21T15:28:14Z"}, {"author": "Anthony Somerset", "text": "will at least give better zoom with more space
", "time": "2022-06-21T15:28:44Z"}, {"author": "Roland Bless", "text": "yep
", "time": "2022-06-21T15:28:49Z"}, {"author": "Yingzhen Qu", "text": "presenters, please use preloaded slides in meetecho, the icon next to \"join queue\"
", "time": "2022-06-21T15:29:54Z"}, {"author": "Carsten Bormann", "text": "+1
", "time": "2022-06-21T15:30:05Z"}, {"author": "cabo", "text": "This slide is true if you are short of capacity.  We usually are latency-limited
", "time": "2022-06-21T15:31:27Z"}, {"author": "Dirk Trossen", "text": "The background of a shared workspace, I would guess
", "time": "2022-06-21T15:31:57Z"}, {"author": "Greg Shepherd", "text": "QOS is used to determine who's packets to drop. - Peter Lothberg
", "time": "2022-06-21T15:32:34Z"}, {"author": "John Scudder", "text": "Oh, so I'm not the only one hearing Peter's voice in my head.
", "time": "2022-06-21T15:35:32Z"}, {"author": "Lars Eggert", "text": "i think the slides are not advancing again
", "time": "2022-06-21T15:36:25Z"}, {"author": "Stefano Salsano", "text": "yes slides are frozen
", "time": "2022-06-21T15:36:43Z"}, {"author": "Daniel King", "text": "Re: Slide Freeze - Indeed, same thing occurred in my presentation.
", "time": "2022-06-21T15:37:38Z"}, {"author": "Carsten Bormann", "text": "Please use slide presentation and not screen sharing.
", "time": "2022-06-21T15:38:29Z"}, {"author": "Yingzhen Qu", "text": "Please use preloaded slides instead of sharing screen.
", "time": "2022-06-21T15:38:36Z"}, {"author": "Roland Bless", "text": "I think that the full screen mode window is not shared, so one must start sharing after going to full screen maybe
", "time": "2022-06-21T15:38:45Z"}, {"author": "Carsten Bormann", "text": "Chairs: Please do not grant a screen share.
", "time": "2022-06-21T15:38:48Z"}, {"author": "Yingzhen Qu", "text": "got it. thanks, Carsten.
", "time": "2022-06-21T15:39:28Z"}, {"author": "Roland Bless", "text": "QoS support is mainly about managing resource scarcity
", "time": "2022-06-21T15:40:00Z"}, {"author": "cabo", "text": "And chairs can start the slide presentation, and then hand over controls (or not so the presenter has to say \"next slide\").
", "time": "2022-06-21T15:40:20Z"}, {"author": "Yingzhen Qu", "text": "I didn't know the \"hand over\" part. we can try it
", "time": "2022-06-21T15:41:42Z"}, {"author": "Dirk Trossen", "text": "@Roland isn't the 'managing scarcity' part that links into the pricing aspect outlined by Phil (although there is some body of work on differentiated pricing in networking)?
", "time": "2022-06-21T15:42:28Z"}, {"author": "cabo", "text": "Yingzhen Qu_web_861: Click on the person who should control the slides, and use the button to the side that says \"hand over\" or \"controls\" (sorry, don't remember)
", "time": "2022-06-21T15:43:28Z"}, {"author": "Roland Bless", "text": "@Dirk: sure, you need some policy in order to make decisions how to manage (like dropping which packets) the resources. If QoS support is for free, everyone wants the best policy and then we are back at the best-effort model.
", "time": "2022-06-21T15:44:39Z"}, {"author": "Yingzhen Qu", "text": "@cabo it works! thank you!
", "time": "2022-06-21T15:44:56Z"}, {"author": "Dirk Trossen", "text": "@Roland going back to seeing Peter Lohberg being quoted, if you decide (with QoS) who to drop, it is a differentiated action and thereby not a best effort throughout, is it not?
", "time": "2022-06-21T15:46:37Z"}, {"author": "Roland Bless", "text": "@Dirk: sorry, meant, \"everyone wants the best quality\". Within this best class etc. you cannot differentiate any further, so if you don't have admission control and policing in place to refuse new users of this class, you end up in the same fairness and resource sharing issues as in the best-effort class.
", "time": "2022-06-21T15:50:15Z"}, {"author": "Dirk Trossen", "text": "@Roland ah, thanks, got it now. Indeed, agree!
", "time": "2022-06-21T15:50:43Z"}, {"author": "John Scudder", "text": "\"If everyone is special, then nobody is special.\"
", "time": "2022-06-21T15:51:01Z"}, {"author": "Roland Bless", "text": "Yep
", "time": "2022-06-21T15:51:08Z"}, {"author": "cabo", "text": "Actually, you can be special in different ways.
", "time": "2022-06-21T15:51:41Z"}, {"author": "Dirk Trossen", "text": "@John but we do have user choice in pricing, e.g., in postal mail. I do not stick a priority mail sticker on all my mail at all. I do expect though a certain quality level still for 'normal mail'.
", "time": "2022-06-21T15:52:28Z"}, {"author": "John Scudder", "text": "Hence @Roland's point about admission control and policing.
", "time": "2022-06-21T15:53:24Z"}, {"author": "Roland Bless", "text": "w.r.t. \"semantic routing\": not clear to me whether we need really a per-packet decision or whether it is more a per-flow decision
", "time": "2022-06-21T15:53:31Z"}, {"author": "Dirk Trossen", "text": "Correct!
", "time": "2022-06-21T15:53:33Z"}, {"author": "Philip Eardley", "text": "so the postal example links to the commercial model - different stamp is recognised at the sorting office and handled differently
", "time": "2022-06-21T15:53:57Z"}, {"author": "Tony Li", "text": "If best effort is good enough, then how do you sell QoS? And if best effort starts dropping, then you lose best effort customers.
", "time": "2022-06-21T15:53:58Z"}, {"author": "Tony Li", "text": "So Peter is wrong, this is really about latency, not about drops.
", "time": "2022-06-21T15:54:35Z"}, {"author": "Philip Eardley", "text": "but if semantic routing is hop-by-hop, will you do the check of the \"stamp\" at every hop? or somehow only once at the ingress?
", "time": "2022-06-21T15:54:43Z"}, {"author": "Dirk Trossen", "text": "@Tony for most my mail, an expected 2 to 5 days is good enough but I do pay for the assured (more or less) next day delivery.
", "time": "2022-06-21T15:54:46Z"}, {"author": "Dirk Trossen", "text": "So yes, it is about latency, more than drops
", "time": "2022-06-21T15:55:07Z"}, {"author": "John Scudder", "text": "And jitter.
", "time": "2022-06-21T15:55:20Z"}, {"author": "Tony Li", "text": "Yup
", "time": "2022-06-21T15:55:30Z"}, {"author": "Roland Bless", "text": "However, in case there is no queue present, i.e., every packet sees only empty buffers on arrival, then there is no additional latency and no jitter if we assume that queuing delay is a dominant source of latency
", "time": "2022-06-21T15:58:52Z"}, {"author": "Tony Li", "text": "Queuing delay is the only variable part of latency. And the only fungible portion.
", "time": "2022-06-21T15:59:29Z"}, {"author": "Antoine Fressancourt", "text": "Except in test networks, we are very rarely in a situation wher eteh network queues are empty
", "time": "2022-06-21T15:59:50Z"}, {"author": "Adrian Farrel", "text": "@jgs \"if everyone is special, none is special\"
Welcome to the Internet where all the packets above average
", "time": "2022-06-21T15:59:53Z"}, {"author": "John Scudder", "text": ":-)
", "time": "2022-06-21T16:00:13Z"}, {"author": "Tony Li", "text": "That's the Woebegon Internet. :)
", "time": "2022-06-21T16:00:29Z"}, {"author": "Adrian Farrel", "text": "@tony Do microwave and satellite links vary latency? But also (obviously!) different paths have different latencies
", "time": "2022-06-21T16:01:00Z"}, {"author": "Tony Li", "text": "Microwave is fixed.
", "time": "2022-06-21T16:01:22Z"}, {"author": "Lixia Zhang", "text": "The first architectural question: it\u2019s not \u201csemantic\u201d or not semantic, but what the network namespace identifies.
", "time": "2022-06-21T16:01:26Z"}, {"author": "cabo", "text": "Adrian: On Sat, you can choose coding, which will give you better reliability or better latency
", "time": "2022-06-21T16:01:53Z"}, {"author": "Tony Li", "text": "Satellite varies because distances fluctuate.
", "time": "2022-06-21T16:01:53Z"}, {"author": "cabo", "text": "(And because it rains.)
", "time": "2022-06-21T16:02:39Z"}, {"author": "Tony Li", "text": "AFAIK, BE satellite is still an unsolved problem.
", "time": "2022-06-21T16:02:46Z"}, {"author": "Adrian Farrel", "text": "Is it only microwave b/w that varies? I should do some reading!
", "time": "2022-06-21T16:03:32Z"}, {"author": "Lixia Zhang", "text": "IP multicast address is not address per se (which identify network attachment points); multicast address identifies content sent to a group of interested recipients.
", "time": "2022-06-21T16:03:40Z"}, {"author": "cabo", "text": "Multicast is the original attempt as semantic routing.
", "time": "2022-06-21T16:04:32Z"}, {"author": "Lixia Zhang", "text": "We really need a writeup on \u201cLessons learned from IP multicast over the last 30 years\u201d
", "time": "2022-06-21T16:04:52Z"}, {"author": "cabo", "text": "It failed to capture the Internet for many reasons, but one was too much application state in the network.
", "time": "2022-06-21T16:04:55Z"}, {"author": "cabo", "text": "The other reason was bad deployment economy
", "time": "2022-06-21T16:05:13Z"}, {"author": "Tony Przygienda", "text": "they are addresses. An address is defined as providing information \"where\" something is. multicast addresses do that just as unicast do. they do not encode any further semantic of \"what\" is at this spot ...
", "time": "2022-06-21T16:05:14Z"}, {"author": "Adrian Farrel", "text": "@Lixia. That would be really helpful to the next generation
", "time": "2022-06-21T16:05:29Z"}, {"author": "Adrian Farrel", "text": "...and stop the reinvention
", "time": "2022-06-21T16:05:47Z"}, {"author": "Lixia Zhang", "text": "@cabo you need to first answer the question of what network identifiers identify first, before you know what/whose semantics one is talking about
", "time": "2022-06-21T16:05:51Z"}, {"author": "Tony Przygienda", "text": "and BIER solves the state and convergence speed/fluctuation problem.
", "time": "2022-06-21T16:06:01Z"}, {"author": "Roland Bless", "text": "To me, a multicast address is a logical address denoting \"the group of recipients\" (wherever they are sitting in the network).
", "time": "2022-06-21T16:06:25Z"}, {"author": "Daniel King", "text": "@Phil, this is a modified architecture that Dirk and I developed. I used several components and interfaces we discussed for NG-CDI.
", "time": "2022-06-21T16:06:52Z"}, {"author": "cabo", "text": "(Logical in this sense is a word for semantic)
", "time": "2022-06-21T16:07:04Z"}, {"author": "Tony Przygienda", "text": "as to still best defintiuon of what naming/addressing/routing is I suggest Schoh's '72 seminal paper. it's stilll unbeaten ...
", "time": "2022-06-21T16:07:05Z"}, {"author": "Roland Bless", "text": "@cabo: yes, it has a different semantic than a normal unicast destination address
", "time": "2022-06-21T16:08:18Z"}, {"author": "Lixia Zhang", "text": "@Roland multicast \u201caddress\u201d is not about a group of recipients\u2014this group can change. It really identifies the content associated with that \u201cmulticast address\u201d, so whoever interested may join the group.
", "time": "2022-06-21T16:08:42Z"}, {"author": "cabo", "text": "Well, that's the definition of a group \u2014 it can change.  Vs. xcast, where the set of recipients is encoded.
", "time": "2022-06-21T16:09:26Z"}, {"author": "Lixia Zhang", "text": "@cabo lets separate out the concept from a specific implementation (xcast)
", "time": "2022-06-21T16:10:21Z"}, {"author": "Antoine Fressancourt", "text": "@Tony, my personal favorite https://dl.acm.org/doi/10.1145/9760.9761
", "time": "2022-06-21T16:10:24Z"}, {"author": "Roland Bless", "text": "@Lixia: I guess that my definition did not exclude this and I always have in mind that the group is dynamic. Especially, intermediate routers do not need to know who is member of the group.
", "time": "2022-06-21T16:10:32Z"}, {"author": "Lixia Zhang", "text": "@Roland as I\u2019ve said more than once: the key question is what an identifier identifies, nodes or content.  Unfortunately \u201cboth\u201d is not a viable answe, as the history of mcast has shown
", "time": "2022-06-21T16:11:56Z"}, {"author": "Tony Przygienda", "text": "@Antoine, looking at the abstract it's basically Schoh's concepts repeated. One can actually derive this by looking at a simple postcard with a name/address and ask oneself what ZIP is ;-) and where the \"route\" comes from ;-)
", "time": "2022-06-21T16:12:03Z"}, {"author": "Tony Przygienda", "text": "oh, look ;-) https://www.rfc-editor.org/ien/ien19.txt
", "time": "2022-06-21T16:13:44Z"}, {"author": "Dirk Trossen", "text": "Phew, no questions asked but good discussions here on the chat. To @Lixia's point, I would agree that the semantic inherently impacts what the communication 'addresses' (in its information to facilitate the communication flow).
", "time": "2022-06-21T16:16:06Z"}, {"author": "Dirk Trossen", "text": "On this point, the aspect of what semantics one wants does go along with what you meant to address in the first place - but 15 mins was not enough to cover this aspect.
", "time": "2022-06-21T16:16:47Z"}, {"author": "Antoine Fressancourt", "text": "Address are tied with a sense of topology. Regarding the elements shared today, we might consider topologies that suit a variety of concepts or use cases
", "time": "2022-06-21T16:17:49Z"}, {"author": "Daniel King", "text": "As an FYI, this discussion will also continue at SIGCOMM this year. We have a dedicated workshop - 1st ACM SIGCOMM Workshop on Future of Internet Routing & Addressing (FIRA)
", "time": "2022-06-21T16:18:07Z"}, {"author": "Daniel King", "text": "https://conferences.sigcomm.org/sigcomm/2022/workshop-fira.html
", "time": "2022-06-21T16:18:16Z"}, {"author": "Daniel King", "text": "The CFP response was great, we took about 50% of the submissions and split into three sessions.
", "time": "2022-06-21T16:18:39Z"}, {"author": "Dirk Trossen", "text": "@Roland @Lixia the mentioned FRRM draft outlines indeed the ephemeral relationship nature of what constitutes the 'multicast address' in that semantic.
", "time": "2022-06-21T16:18:51Z"}, {"author": "Tony Przygienda", "text": "@Antoine. yes and no. in most extreme cases address is equivalent to route (hypercube). on irregular meshes that do not automatically summarize (like NSAPs) routing is strictly \"how you get to where the address is pointing\". nothing else. no correlation ...
", "time": "2022-06-21T16:19:01Z"}, {"author": "Daniel King", "text": "Good indication that routing research and development happening at the moment.
", "time": "2022-06-21T16:19:02Z"}, {"author": "Antoine Fressancourt", "text": "e.g. you don't take the train to a postal address
", "time": "2022-06-21T16:19:11Z"}, {"author": "Jeff Tantsura", "text": "@antoine - unless your address is a train station ;-)
", "time": "2022-06-21T16:19:54Z"}, {"author": "Antoine Fressancourt", "text": "I think that there is a lot of things we take for granted when considering addressing. In teh western world, we have an implicit background about how postal addresses are structured. I remeber the time I landed in Japan, and the fact that addresses point to building groups and not ways / streets was very disturbing (adding to the jet lag\"
", "time": "2022-06-21T16:21:27Z"}, {"author": "Tony Przygienda", "text": "@Antoine, yes, a finer point which I would however argue is semiotics, not semantics of those things ;-) In that sense the semiotics of an address on an IP network is _some_ kind of service behind it (unless we have honeypots [which are also service]). However, semiotics is in a sense orthogonal to the ontology of those things themselves (I hope it's all still parsable but it takes IME this kind of incisive distinction to not confuse everything for everything else)
", "time": "2022-06-21T16:21:33Z"}, {"author": "Lixia Zhang", "text": "@Antoine \"address\" (or network identifier) is NOT tied to topology per se: keep in mind that topology is created via routing announcements. So the question is really what one announces via routing.  A related, but separable, question is whetehr the identifier is aggregatable with regard to network connectivity.
", "time": "2022-06-21T16:21:48Z"}, {"author": "Tony Przygienda", "text": "yeah, I'm familiar with the Japanese system, medieval europe had similar things and I live in a place where routing still happens by landmarks and addresses partially encode them ;-)
", "time": "2022-06-21T16:22:31Z"}, {"author": "Lixia Zhang", "text": "but that is the same issue we've encounted with IP routing
", "time": "2022-06-21T16:22:33Z"}, {"author": "Antoine Fressancourt", "text": "@Lixia Indeed. making identifier aggregatable from a topology perspective puts a burden on the naming scheme
", "time": "2022-06-21T16:22:57Z"}, {"author": "Antoine Fressancourt", "text": "Adrian mentionned Privacy in his slides, I am of course biased by my interest in this context, but one fundamental goal of enforcing privacy in networks is to make sure that identifiers are not aggregatable whatsoever
", "time": "2022-06-21T16:24:47Z"}, {"author": "Lixia Zhang", "text": "@Antoine  Again the first question/decision is what network identifiers one wants; routing scalability has well understood solutions, even if the identifiers are not aggregatable (e.g. see LISP as one of, but definitely not the only, example)
", "time": "2022-06-21T16:25:00Z"}, {"author": "Tony Przygienda", "text": "Genesis 11:1\u20139  ;-) l8r e'one ...
", "time": "2022-06-21T16:26:43Z"}, {"author": "Dirk Trossen", "text": "@Antoine @Lixia \"So the question is really what one announces via routing\" - more specifically what of the announcement really eventually impacts the packet forwarding decision. Topological identifiers may be one such input but we know of systems where those inputs are of different kind.
", "time": "2022-06-21T16:26:55Z"}, {"author": "Roland Bless", "text": "@Lixia: at the Dagstuhl Workshop on Naming and Adressing in 2009 we picked up on the idea that an address could probably identify a particular network stack instead of interfaces as in IPv6
", "time": "2022-06-21T16:27:17Z"}, {"author": "Adrian Farrel", "text": "Precisely! SR is an underlay
", "time": "2022-06-21T16:28:29Z"}, {"author": "Antoine Fressancourt", "text": "@Roland I have been quite found of XIA's approach that gives you the possibility to give addresses as way to reach you depending on \"conceptual addressing approach\"
", "time": "2022-06-21T16:28:33Z"}, {"author": "Antoine Fressancourt", "text": "With a fallback to destination based routing
", "time": "2022-06-21T16:28:54Z"}, {"author": "Lixia Zhang", "text": "@Roland \"stack\" by itself does not answer the question of what *kind* of identifier it operates on
", "time": "2022-06-21T16:29:15Z"}, {"author": "cabo", "text": "\u2026 or use the arrow keys to move between slides.
", "time": "2022-06-21T16:29:49Z"}, {"author": "Antoine Fressancourt", "text": "@Lixia I don't care being identified as soon as I can be reached
", "time": "2022-06-21T16:29:56Z"}, {"author": "Daniel King", "text": "Thanks for mic questions, if you asked one could you just double check we captured the essence of the question/answer, so we have accurate minutes. Thanks in advance!
", "time": "2022-06-21T16:30:28Z"}, {"author": "cabo", "text": "We = https://notes.ietf.org/notes-ietf-interim-2022-rtgwg-01-rtgwg
", "time": "2022-06-21T16:30:59Z"}, {"author": "Lixia Zhang", "text": "@Antoine  Maybe you dont want to be directly reached by 2 millions viewers when you got an exciting video posted.
", "time": "2022-06-21T16:31:14Z"}, {"author": "Antoine Fressancourt", "text": "I am pretty sure many Youtube influencers would love to face this problem :-D
", "time": "2022-06-21T16:31:50Z"}, {"author": "Lixia Zhang", "text": "Youtube influencers dont get reached by viewers; viewers reaches Youtube instead
", "time": "2022-06-21T16:32:43Z"}, {"author": "Antoine Fressancourt", "text": "On a more serious note, yes, the way networking is done introduces this kind of contentions and issues
", "time": "2022-06-21T16:33:20Z"}, {"author": "Roland Bless", "text": "@Lixia: I guess that in my example the identifier would identify a logical node, e.g., a network stack inside a VM hosted on a physical node.
", "time": "2022-06-21T16:34:02Z"}, {"author": "Antoine Fressancourt", "text": "And the way CDNs tackle this issue is by associating an identity (the video I posted that is super fancy) with several locators carrying a copy of it
", "time": "2022-06-21T16:34:48Z"}, {"author": "Antoine Fressancourt", "text": "And the mapping from identity to locator is contextual
", "time": "2022-06-21T16:35:46Z"}, {"author": "Daniel Bernier", "text": "to me the question remains ... most set of use cases that would require \"semantics\" as per Daniel's intro are now at the application level.
Currently these apps mostly leverage 3 methods of knowing where to go a) DNS, b) hardcoded IP (uni or any) c) emergence of application routing through service meshes.
if you take the case of a mesh it can carry lots of \"labeled\" additionnal info and could still leverage any underlay/overlay protocol you
", "time": "2022-06-21T16:36:55Z"}, {"author": "Lixia Zhang", "text": "@Roland \"a logical node\" itself already departed from IP address semantics.  (e.g. it may no longer be aggregatable(
", "time": "2022-06-21T16:36:56Z"}, {"author": "Roland Bless", "text": "@Lixia: yes
", "time": "2022-06-21T16:37:22Z"}, {"author": "Adrian Farrel", "text": "@daniel  I'm not sure. There is clearly a \"routing at the application layer\" issue to be solved. The question asked here is whether the packet forwarding between the locations chosen in the application layer, needs to be influenced in some way.
", "time": "2022-06-21T16:38:18Z"}, {"author": "Dirk Trossen", "text": "@DanielB for the upcoming FIRA workshop (which Dan King mentioned in a previous chat), we looked at comparing on- vs off-path systems for making possibly high dynamic endpoint selection decisions (with DNS/GSLB being your classical off-path example), assuming the execution of the same compute-aware decision in both systems.
", "time": "2022-06-21T16:39:39Z"}, {"author": "Daniel Bernier", "text": "@adrian agreed. well in the case of SR it is the question of how to inform the data plane to convey the right \"path\" and what form of more application aware control-plane to use for it rather than add another SAFI to BGP
", "time": "2022-06-21T16:40:39Z"}, {"author": "Adrian Farrel", "text": "Yes
", "time": "2022-06-21T16:40:54Z"}, {"author": "Lixia Zhang", "text": "in academia there have been a number of papers on \"Computation and Computational Thinking\".  It seems that IETF might benefit from a conversation on \"Architecture and architectural thinking\" -- lots smart people have lots smart ideas, but there seem a mix/confusion between what can be done on a node (or small scale) versus what makes a viable network architecture.
", "time": "2022-06-21T16:41:19Z"}, {"author": "Dirk Trossen", "text": "Three main conclusions from that work: (1) off-path latency eventually limits your decision frequency (2) on-path smoothens latency variance and (3) improves on resilience in cases of partial or temporary endpoint failure (in a group of endpoint choices)
", "time": "2022-06-21T16:41:36Z"}, {"author": "Adrian Farrel", "text": "@daniel And is there flexibility to let the network make decisions based on rapidly changing environment? I.e., faster than could be done by a controller or head-end that would need to learn about the changes \"at a distance\" and instruct the packets to be marked differently.
And, anyway, is that desirable/safe?
", "time": "2022-06-21T16:42:29Z"}, {"author": "Roland Bless", "text": "I'm concerned with putting too much application-level state/knowledge/information into the network for semantic routing which makes the architecture much more fragile and less robust (see also the old e2e argument in systems design)
", "time": "2022-06-21T16:43:18Z"}, {"author": "Roland Bless", "text": "I have to leave now, sorry.
", "time": "2022-06-21T16:43:51Z"}, {"author": "Dirk Trossen", "text": "@Roland great concern; it is a balance that needs to be found. But what the semantic routing drafts show that such information is making it into the network already!
", "time": "2022-06-21T16:44:31Z"}, {"author": "cabo", "text": "Roland: Too much application state hindered multicast a lot.  But really, it was application state that needed to be handled by nodes that were not interesting handling that state.  If you can sneak the application info by the nodes that don't need it, you are one step further.
", "time": "2022-06-21T16:45:41Z"}, {"author": "cabo", "text": "*interested
", "time": "2022-06-21T16:46:13Z"}, {"author": "Daniel Bernier", "text": "@roland agreed there
", "time": "2022-06-21T16:47:04Z"}, {"author": "Daniel Bernier", "text": "@adrian also agreeing hence might be a change in on-path control-plane rather than 'controller'
", "time": "2022-06-21T16:47:58Z"}, {"author": "Daniel Bernier", "text": "begs to question also at what speed must this be acted upon ... going back to the limits a brain react to
", "time": "2022-06-21T16:48:42Z"}, {"author": "Dirk Trossen", "text": "@DanielB the on-path control plane is a good way to look at it, also when we compared both approaches in terms of their flexibility and impact on dynamic decision making. To me, it is the question on what an increased speed of action could bring in terms of performance and cost benefits.
", "time": "2022-06-21T16:50:26Z"}, {"author": "Jeff Tantsura", "text": "@roland - we need to decouple planes, what is presented in control plane != forwarding; MPLS as an abstraction is a great example of this, all the control plane complexity is flattened into a single (or double - context + actual value) very efficient forwarding construct
", "time": "2022-06-21T16:50:29Z"}, {"author": "Jeff Tantsura", "text": "my mike is stuck
", "time": "2022-06-21T16:52:52Z"}, {"author": "Nicola Rustignoli", "text": "At the beginning there were some questions about security (i.e. how to avoid that semantic routing gets misused, how to trust information in the packet). I did not really find an answer to this. Is this still an open question or is this out of scope?
Is semantic routing supposed to be deployed inter-domain? If so, IMHO security becomes much more relevant
", "time": "2022-06-21T16:53:52Z"}, {"author": "Adrian Farrel", "text": "@Nicoal: all questions are open
", "time": "2022-06-21T16:54:15Z"}, {"author": "Antoine Fressancourt", "text": "@Nicola I think it should be tackled
", "time": "2022-06-21T16:54:23Z"}, {"author": "Dirk Trossen", "text": "+1 on security
", "time": "2022-06-21T16:54:34Z"}, {"author": "Adrian Farrel", "text": "No specific solution is on the table yet, but security being, erm, secure, is important
", "time": "2022-06-21T16:55:20Z"}, {"author": "Antoine Fressancourt", "text": "\"What identifiers identify\" .. and how locators should be structured to follow the topology we need to route in
", "time": "2022-06-21T16:56:14Z"}, {"author": "Dirk Trossen", "text": "@Lixia good point - the nature (and ultimately structure) of the semantic header I suggested in my abstractions slide is key. It was not explicitly suggested in my slides that the semantic header was IP address based; it could be (for a number of reasons) but that is a (maybe THE) key open question!
", "time": "2022-06-21T16:57:45Z"}, {"author": "Dirk Trossen", "text": "Thank you for organizing this session and having had a very lively discussion!
", "time": "2022-06-21T17:00:07Z"}, {"author": "Daniel Bernier", "text": "same here ... looking forward for F2F in Philadelphia
", "time": "2022-06-21T17:04:28Z"}]