Hi Alberto :)
", "time": "2024-03-21T23:30:33Z"}, {"author": "Adam Wiethuechter", "text": "He is also terrible at it
", "time": "2024-03-21T23:36:58Z"}, {"author": "Sauli Kiviranta", "text": "Hi fellas!
", "time": "2024-03-21T23:39:01Z"}, {"author": "Scott Johnson", "text": "Good to see you, Sauli!
", "time": "2024-03-21T23:39:48Z"}, {"author": "Rick Taylor", "text": "@Meetecho - the video for speakers is pointing into the audience
", "time": "2024-03-21T23:39:52Z"}, {"author": "Sauli Kiviranta", "text": "You too!
", "time": "2024-03-21T23:40:04Z"}, {"author": "Lorenzo Miniero", "text": "@Rick Taylor fix, sorry for missing the speaker change!
", "time": "2024-03-21T23:41:11Z"}, {"author": "Rick Taylor", "text": "Thank you!
", "time": "2024-03-21T23:41:20Z"}, {"author": "Lorenzo Miniero", "text": "*fixed
", "time": "2024-03-21T23:41:25Z"}, {"author": "Brian Sipos", "text": "My audio not working unfortunately
", "time": "2024-03-21T23:44:02Z"}, {"author": "Marc Blanchet", "text": "Brian if you speak, we are not hearing you
", "time": "2024-03-21T23:44:18Z"}, {"author": "Rick Taylor", "text": "No worries - you have 25 mins to fix :)
", "time": "2024-03-21T23:44:19Z"}, {"author": "Lorenzo Miniero", "text": "@Brian Sipos if you click your avatar in the bottom bar, you'll have the option of revisiting your selected devices (same UI as when you join). You can check which audio device is used as a mic, and a bar will move if it detects audio from you: if it's not moving the browser is getting silence (hardware mute somewhere? wrong device?)
", "time": "2024-03-21T23:45:37Z"}, {"author": "Rick Taylor", "text": "@Ed - What, no Pluto?
", "time": "2024-03-22T00:07:00Z"}, {"author": "Adam Wiethuechter", "text": "Pluto is a lie
", "time": "2024-03-22T00:07:19Z"}, {"author": "Jim Reid", "text": "Why are there no numbers for the sun? :grinning:
", "time": "2024-03-22T00:08:43Z"}, {"author": "Joshua Deaton", "text": "If you're on the sun you have bigger issues than where are my coap messages XD
", "time": "2024-03-22T00:11:09Z"}, {"author": "Adam Wiethuechter", "text": "I want a status for the current temp tho...
", "time": "2024-03-22T00:14:22Z"}, {"author": "Adam Wiethuechter", "text": "Serious shoutout to Meetecho can we get them to take over the world with this software?
", "time": "2024-03-22T00:33:09Z"}, {"author": "Adam Wiethuechter", "text": "I may be naive and pessimistic; I am wary of encoding such things as \"priority\" into discrete values. Is there previous work in IETF with this concept?
", "time": "2024-03-22T00:43:27Z"}, {"author": "Erik Kline", "text": "there is a long history of attempts with DSCP, yes
", "time": "2024-03-22T00:44:28Z"}, {"author": "Adam Wiethuechter", "text": "Would this just be a lift from there into the extension block then?
", "time": "2024-03-22T00:44:49Z"}, {"author": "Rick Taylor", "text": "This lifts the \"spirit\" but not the detail
", "time": "2024-03-22T00:45:06Z"}, {"author": "Adam Wiethuechter", "text": "In the wise words of Bob M. -- document revisions are free!!
", "time": "2024-03-22T00:52:31Z"}, {"author": "Adam Wiethuechter", "text": "(inside joke as drip-auth is t 49 revs and was at 47 when through IESG telechat)
", "time": "2024-03-22T00:53:03Z"}, {"author": "Scott Burleigh", "text": "FWIW, I remain skeptical that anything beyond a user-asserted data label (or \"flow label\", or other species of label) needs to be carried in a QOS extension block. The idea being that each BPA can use some combination of source EID, destination EID, data label, bundle size, day of the week, whatever to select the QOS policy that it will want to use. That determination can be complex, it can be simple, but I think it's what nodes are going to do in practice anyway.
", "time": "2024-03-22T00:56:53Z"}, {"author": "Joshua Deaton", "text": "Do you think it would be easier or a moot point for in a constrained resource node to process an extension block or handle a potentially large policy map? It may be moot, but if it isn't it might be a convenient way to allow more or less lighter weight QOS on resource constrained nodes
", "time": "2024-03-22T01:00:24Z"}, {"author": "Adam Wiethuechter", "text": "Answer 1 is probably yes
", "time": "2024-03-22T01:02:17Z"}, {"author": "Scott Burleigh", "text": "I suspect that the implementation of complex policies is going to be much more resource-intensive than the the logic for selecting them.
", "time": "2024-03-22T01:02:22Z"}, {"author": "Teresa Algarra", "text": "Carrying a block adds minimal overhead and allows for all of this to be scalable, and to be used in constrained nodes
", "time": "2024-03-22T01:02:48Z"}, {"author": "Scott Burleigh", "text": "Certainly. But if the policy representation is, in effect, carried in the block you still end up invoking complex mechanisms if the policy indicated in the block is complex. I think all that is saved is the lookup. Maybe that's a compelling advantage, but I am skeptical.
", "time": "2024-03-22T01:05:25Z"}, {"author": "Brian Sipos", "text": "My connection is working now, can discuss
", "time": "2024-03-22T01:06:19Z"}, {"author": "Alberto Montilla", "text": "I think policies are a must. That's the only way you can protect a network from an attack or misbehaviors (or even node capability limitations). I don't think signaling helps on that.
", "time": "2024-03-22T01:06:42Z"}, {"author": "Teresa Algarra", "text": "That is one of the advantages of the Network block: the gateway node would do all the \"complex\" work and the middle nodes would just receive a simple set of instructions according to the network's requirements or needs
", "time": "2024-03-22T01:07:17Z"}, {"author": "Alberto Montilla", "text": "Thats a good advantage. Gateway Node enforces the policy it wants then signal it to other \"Network\" nodes.
", "time": "2024-03-22T01:09:05Z"}, {"author": "Koojana Kuladinithi", "text": "Further, this will also let the GW node to map its policies with regard to user defined set to its network nodes
", "time": "2024-03-22T01:09:26Z"}, {"author": "Joshua Deaton", "text": "Yeah I would agree with Teresa to the extent that could you do everything by policy only yes, but this provides a different way to do it in order to gain efficiency in certain scenarios
", "time": "2024-03-22T01:09:45Z"}, {"author": "Scott Burleigh", "text": "Right, the gateway node does the lookup to determine what policy to apply and encodes that policy in the extension block. Then every node (including the gateway node) executes the indicated policy. The interior nodes avoid the lookup. As I say, maybe that's a compelling advantage. I am not yet convinced.
", "time": "2024-03-22T01:10:13Z"}, {"author": "Rick Taylor", "text": "@Scott - that's how the Internet has ended up working in practice... seems to have scaled reasonably well
", "time": "2024-03-22T01:10:45Z"}, {"author": "Alberto Montilla", "text": "Rick, not sure I follow. How does the internet work today?
", "time": "2024-03-22T01:11:37Z"}, {"author": "Rick Taylor", "text": "Traffic shapers exist in key points between adminsitrative areas that perform the complex policy resolution, and then mark the packets so intermedita enodes can do fast packet processing
", "time": "2024-03-22T01:12:23Z"}, {"author": "Alberto Montilla", "text": ":+1:
", "time": "2024-03-22T01:12:52Z"}, {"author": "Koojana Kuladinithi", "text": "You mean like BGP and ASs interworking ?
", "time": "2024-03-22T01:13:04Z"}, {"author": "Rick Taylor", "text": "It's all about sclaing the policy management in effect
", "time": "2024-03-22T01:13:09Z"}, {"author": "Rick Taylor", "text": "*scaling
", "time": "2024-03-22T01:13:16Z"}, {"author": "Marc Blanchet", "text": "Rick's description of traffic shapers is accurate. I would add that often, within an administrative domain (aka provider domain), the marking is actually implemented as MPLS flows and then forwarded at layer 2.5 (MPLS)
", "time": "2024-03-22T01:14:58Z"}, {"author": "Scott Burleigh", "text": "Rick, I see your point, and maybe that's the answer; maybe avoiding the lookup really is that compelling. My suspicion is that the dimensions of QOS policy that will be adopted by nodes operated by different entities may be very different and potentially open-ended. Trying to encode all possibilities in a standard protocol that all nodes will be expected to implement seems daunting to me.
", "time": "2024-03-22T01:15:18Z"}, {"author": "Rick Taylor", "text": "It's not just avoiding the lookup, it's about the man-power cost of getting the policies all configured correctly. If you can do it only at critical places, your network works better.
\nThe dark side of this operational model, is that often these shapers rewrite IP QoS as in a heterogeneous network, the policies conflict. Hence having the \"Network QoS\" which is expected to be added and removed, as well as the \"Original User QoS\" is a great idea. A local network can apply a certain policy, without destroying the sources original intent
", "time": "2024-03-22T01:17:39Z"}, {"author": "Scott Burleigh", "text": "I would think you would use a protocol to distribute policy configuration, maybe using something like reliable multicast, so that the configuration labor would be manageable. But this isn't a problem I've had to solve, so I dunno.
", "time": "2024-03-22T01:20:59Z"}, {"author": "Brian Sipos", "text": "If the goal is to save a lookup, then the same kind of behavior used in security \"key ID\" could be taken here which is that a QOS label is \"an integer or a byte string\" and let the application or network figure out how that maps to some policy semantics. The encoding is then very simple and opaque.
", "time": "2024-03-22T01:21:37Z"}, {"author": "Joshua Deaton", "text": "@scott maybe even use Nack Oriented Reliable Multicast :stuck_out_tongue_wink:
", "time": "2024-03-22T01:22:26Z"}, {"author": "Brian Sipos", "text": "I should say a label along with the EID of the node which added the label, so that they can be distinguished and filtered.
", "time": "2024-03-22T01:22:40Z"}, {"author": "Alberto Montilla", "text": "BIBE CLA is our MPLS/VXLAN (aka tunneling) equivalent (saving its distance). Routing\\\\\\ inside the network has to be rather simple to achieve performance.
", "time": "2024-03-22T01:22:41Z"}, {"author": "Alberto Montilla", "text": "Change routing by forwarding ;-)
", "time": "2024-03-22T01:22:58Z"}, {"author": "Adam Wiethuechter", "text": "@Joshua Deaton you sound like Stu Card...
", "time": "2024-03-22T01:25:48Z"}, {"author": "Adam Wiethuechter", "text": "mentioning NORM
", "time": "2024-03-22T01:25:56Z"}, {"author": "Rick Taylor", "text": "After 20 years and $ billions spent, the Internet ops community have a number of solutions...
", "time": "2024-03-22T01:26:15Z"}, {"author": "Rick Taylor", "text": "Sorry - 50 years
", "time": "2024-03-22T01:26:50Z"}, {"author": "Scott Burleigh", "text": "Which we celebrate.
", "time": "2024-03-22T01:26:57Z"}, {"author": "Rick Taylor", "text": ":)
", "time": "2024-03-22T01:27:14Z"}, {"author": "Adam Wiethuechter", "text": "Need more solutions...
", "time": "2024-03-22T01:27:38Z"}, {"author": "Adam Wiethuechter", "text": "To celebrate more, thus more beer
", "time": "2024-03-22T01:27:49Z"}, {"author": "Erik Kline", "text": "there could also be new BPv7 URIs, e.g.: dns:<stuff>, ip:<repr>
", "time": "2024-03-22T01:31:00Z"}, {"author": "Erik Kline", "text": "IP packets meant for store-and-forward could be collected into bundles with ip:<dst>
", "time": "2024-03-22T01:31:45Z"}, {"author": "Erik Kline", "text": "and dns:* might be a suitable new URI type
", "time": "2024-03-22T01:32:01Z"}, {"author": "Sauli Kiviranta", "text": "Thank you all! Great work!
", "time": "2024-03-22T01:32:33Z"}, {"author": "Alberto Montilla", "text": "Thanks folks!
", "time": "2024-03-22T01:32:35Z"}, {"author": "Teresa Algarra", "text": "Thank you for your comments and feedback!
", "time": "2024-03-22T01:32:38Z"}, {"author": "Koojana Kuladinithi", "text": "thanks all
", "time": "2024-03-22T01:32:53Z"}]