This is Mark Neu from the Polytechnic University in Catalonia. Last year we tried to invite Mark, but he had over commitments, but we are very happy to have him this year. Mark works in graph theory, in combinatorics, and he focuses mostly on enumerative combinatorics, and what is very important for our community, he links combinatorics and graph theory with logic, so he published several papers on 01 laws and limiting distributions. And today, limiting probabilities, and today we'll hear, we'll listen to the talk co-authored by Alberto LaRauri and Tobias Müller on limiting probabilities of first order sentences in sparse random graphs. So please, Mark, the screen is yours. Okay, thank you very much. Well, first of all, I'm very grateful and very honored for this invitation. And my co-authors are Alberto LaRauri, he's a PhD student under my supervision and Tobias Müller from Groningen. Now, my main area of research is combinatorics, but since several years I've been interested in logical properties of random structures. So just to be sure that we are on the same language, of course, all of you know what is the first order logic, right, the classical first order logic. And in the case of graphs, we add an adjacency relation that this binary predicate we shortened to x adjacent to y. We assume this to be symmetric, so there are no directions and antireflexics, there are no loops. So what can you express in this first order logic of graphs? Well, maybe not too much, but you can express interesting things. Like, for instance, the graph contains a triangle, contains three mutually adjacent vertices. And if you think for a moment, you see that it can also express the existence of a fixed H as a subgraph. You use as many quantifiers as vertices in the graph, and you postulate the adjacencies between them. Now, even more complicated sentences, and this example will be of importance later, there are at most a cycles of length at most k, when a and k are fixed, 10, 50. Well, this would be a rather long sentence, a bit boring to write down, but if you can imagine, well, there are no more than eight plus one subsets of k vertices inducing a cycle. And probably it is very well known that you cannot express more global properties, like connectivity, planarity or three colorality, that you can indeed express in monadic second order logic. But today is only going to be about the first order logic. Good. If there are any questions you can ask, I have planned my slides to have plenty of time. So you are invited to ask or questions. Now, this is for the logic for the graphs, we are using the classical GNP model of random graphs. We fix some p between zero and one. The vertices are from one to end. So this means that the vertices are distinguishable. We will not care about automorphism. And then we put every edge ij in this random graph, independently with probability p. This is not the uniform distribution. The probability of a graph is p to the number of edges times one minus p to the number of non edges. So n to two is the total number of possible edges. So this distribution is not uniform, but this model has been very well studied for the last, I would say now, 60 years. The expected number of edges is the probability of an edge times the possible number of edges n to two. So you see it depends as p n square over two. If p is constant, then the number of edges is quadratic. And this is called dense graphs. But if p is proportional to one over n, then you see if p is one over n, then the number of edges in expectation is linear. And this is what I will call sparse graphs. And today we are going to concentrate only on sparse graphs. And sparse graphs, it's a regime in which the most interesting phenomena in this model of random graphs occur. So again, I just shortened g n to the random graph with the probability of an edge is c over n. Okay, I hope this is clear. And then maybe the most important thing here is the well-known phase transition. If c is below one, then all connected components in the random graph are either trees or have a unique cycle. The unique cycle is a unicyclic sample. And moreover, they are small. They are of size at most log n. But the important thing here is that all components are simple. Simple means that the number of edges is at most the number of vertices, either n or n minus one. And a complex component is a component in which the number of edges is larger than the number of vertices. But for c larger than one, a sudden change occurs. And then there is a unique component of linear size, which is called the giant component. Now, dc is the expected degree of a vertex. And now this phenomenon is very well understood. If you are starting at a vertex and then explore the neighbors and the neighbors, this is a branching process whose expected value is c. And if the branching process is subcritical with this condition, then it will die away very soon. And this is, let's say, the intuition behind this radical change of structure for the subcritical random graphs and for the subcritical. Now, one can say or we could say that first of the logic cannot capture this transition. Why? Because in first of the logic, we cannot express if a graph has a cycle or not, or if it has a unique cycle. We can express that it has a cycle of length eight or any constant. But we cannot express, and this is provable, that first of the logic is not powerful enough to express being a cyclic or not. But this intuition here was made precise, very precise in the following result. So again, gn will be this random graph. And given a property, a, given by a first order sentence, right, in which every variable is quantified, so that this express a graph property invariant and their isomorphism, we are interested, which is the probability that the random graph satisfies this property? For instance, that it contains a triangle or that it has four cycles of a given length or that it contains k4 as a component. And we are interested in the limited probability when the number of vertices goes to infinity. So we will always be talking about the asymptotic regime. Now, James Lynch, now maybe almost 30 years ago, he proved the following. For every property, this limit exists, or this limit will depend on the property and will depend on the value of c that we have taken. But here, I emphasize that I consider this as a function of c. And this function of c can be expressed only just basic sums and products and a set of constants and exponential. So it's not only a continuous function. It's a c-infinite function. It's an analytic function. There is no change, no nothing that happens when you go from c less than one to c larger than one. So in some technical sense, this says that this phase transition cannot be expressed, cannot be captured by properties that are satisfied asymptotically or not when the number of vertices goes to infinity. So you don't see any difference with c. You really don't see any difference with c. Can I ask a question? Yes. But you could potentially construct something like e to the x over one plus e to the x, like a function which goes from zero to one using the exponential sums and multiplications. No, no, no, no, no, no. These are not exponentials of exponentials, right? It's not every combination of this, right? So these exponentials are just parameters of Poisson distributions. And you just take linear combinations of this. It's not that you can use any combination of exponentials, Sergei. It is really analytic and well defined. So what does it mean when you say set of constants and exponentials, what does it actually mean? Well, maybe I should have been more precise. I should have been, these are the set of constants of certain distributions, parameters of Poisson distributions, and single exponentials and linear combinations of this or sums and products of this. Okay. Good. Now, Alberto, my student has recently generalized this result to sparse hypergraphs. And maybe I will say something at the end about hypergraphs, which is also an interesting line of research. So these are the limiting probabilities. And then the lesson is that first of the logic cannot distinguish between the two regimes. Now, what we did here is we consider not a single first order sentence or property, but we consider the set of all limiting probabilities for a given C. We consider the set of all limiting probabilities of first order properties. All of them. Well, this is a countable set because the number of sentences is countable, is symmetric with respect to one half just by negation. And we consider the closure inside the interval 01. And then we ask ourselves, how is this closure? When you take the closure of the set of limiting probabilities, what happens? And then we discover this rather unexpected thing. There is a constant, which is the 0.9 something. It is the unique positive root of a certain simple equation. And then the following happens. This closure is always a finite union of closed intervals. Secondly, if you are above C0 or you are exactly at C0, then it is dense. The closure is the whole interval. But if you are below, and of course positive, there is at least one gap. There is at least one sub-interval that is not covered by the closure. This was a bit of a surprise. We were looking for something that changed given value of C. And more or less, maybe we were expecting that this change would happen at C equals to 1, which is the phase transition, but it is not. And then, which I think is even more interesting, there is this constant, which by the way is below 1. And there is a sudden change into the, not the single limiting probabilities, but the set of all limiting probabilities. Good. So this is the statement. And the rest of my talk, besides some comments at the end and some extensions that we are working in, will be to give you an idea of how to prove this theorem. Okay. Good. Well, which is the motivation? Well, the motivation is that some years ago, with some Tobias Müller and other co-authors, we looked at random planar graphs. This is a different model. We take the set of all label planar graphs. We consider the uniform distribution with n vertices. So there are no independent probabilities. And then we ask ourselves the same question, what is the closure of the set of limiting probabilities? And then we saw it was a finite union of intervals. In fact, these many intervals, which are very short. For the class of random forest, the cyclic graphs, these are four intervals. And these are given numbers. For instance, this 0.6, it's e to the minus 1 half. And for every class which is close under minors, and well, this is a very natural concept in graph theory. And this is always a finite union of intervals. So our starting point was, well, we have seen this phenomenon. We know some techniques, how to prove these kind of results. What happens in this sparse class? Because minor close class are sparse. They have at most a linear number of edges. So this was the motivation. Now, what is the sketch of the proof? Again, here is the statement. You take the set of limiting probabilities of first-order properties. You take this special number, which is the unique root of this. And then these are the few statements we have to prove. And there will be three parts. When c is above 1, there is no gap, right? The closure is everything. When you are below c0, there is at least one gap. You miss at least one sub-interval. And then the last part, which is maybe a bit of more work, is that again, between c0 and 1, there is no gap. And if you put this together, you get these two statements. And along the proof, we'll see that this is always a finite union of intervals. So it's not a complicated set. It's a finite union of intervals. But the behavior depends on c. And we'll see which is the role, which is the combinatorial meaning of this constant. So we proceed with the first part, no gap. This is, in some sense, the simplest one. And what we do is we take in this random graph, we take a random variable, which is the number of cycles of length k, which is the number of k cycles. And in fact, it is well known that this random variable converges in distribution to a Poisson law, whose parameter is precisely c to the k divided by 2k. Well, if you are familiar with these kind of probabilistic statements, this is not difficult to prove by the method of moments. You compute the first moment, the second moment, and all factorial moments, and then using that this Poisson distribution is characterized by the moments you prove this. And moreover, if you fix k, let's say k up to 10 or 20, then the number of triangles, quadrangles, and cycles of the k are asymptotically independent. Now, we can see the this random variable, which is the number of cycles of length at most k. Right? And since they are independent, this converges to a Poisson law, whose parameter is the sum of these parameters. Now, I observe that this mu k, this is when k goes to infinity, this is the divergent. If c is larger than 1, well, this is an exponential. And if c is equal to 1, this is a harmonic series. But in any case, when c is either 1 or larger than 1, then this is divergent. Is this clear? Okay. Again, if you have questions, you can ask. Now, I recall, as I said at the beginning, that the probability that the number of k cycles is at most a constant, this is expressible in first order logic. This is a piece in the argument. Now, by the central limit theorem, since these are independent and asymptotically, and this is okay, then this converges to a normal law. So the probability that this is less than mu plus this deviation of order square root n, then this converges to the distribution function of the normal law. And this is a continuous distribution. So we have a sequence of discrete distributions. And by the central limit theorem, they converge to a continuous distribution. Now, we want to show that every number p can be approximated by limiting probabilities of first order properties. So I take my p and I take an epsilon, which will be the error. And I want to be more than this error. Because this is continuous and this function covers all the values between zero and one. There is an x such that the error function is equal to p. And then because of this convergence, we take mu zero such that this probability is closer to p than epsilon for mu greater than zero. This is what doesn't mean to be this limiting. And finally, we take a k such that mu k is above this mu zero. And this is guaranteed because the limit of mu k is equal to infinity. Now, this property here, okay, the property that this Poisson is less than this is the same that this random variable is less than this value. So this is first order expressible. And we have shown that every p between zero and one can be epsilon approximated by some limiting probability of a first order sentence. Hence, this is dense and the closure is the interval zero. Well, this is an easy argument. And you see, we are only using elementary tools. So if everyone is happy, then we move to the second part. Okay, we move to the second part. And we want to show that when we are below the C zero, there is at least one sub interval that is not covered. Now we have to do two things to go deeper into the structure of this random graph. And again, we have to explain what is the combinatorial meaning of this constant C zero. So what Erdos really proved in this subcritical, remember that here all components are either trees or unicycles, but even more is true. This is a union of trees, which is a forest, and age is a union of unicycline graphs. This is given by the result I just mentioned. But then something else happens. Every fixed tree appears in this forest as many times as you wish. For every fixed T and multiplicity, this random forest contains at least N copies of T. This means that if we restrict to this forest, to the forest part, and we forget about the unicyclic part, then there is a zero one law. The limiting probability that this forest satisfies a first-order property converges and it is either zero or one. Why is this? Well, FN contains arbitrarily many copies of each tree. So to these two random instances of these random forests cannot really be distinguished by all properties. If you know the Eremfeuchte Freiste games, then this is clear, because in this two-player game, duplicator can always win, because you can always find a copy of a tree where you can play your round on the game. If you are not familiar, I'm sure that in this community, many of you will be familiar with these combinatorial games, which is a basic ingredient of finite model theory, but this is the intuition behind if you are not familiar. So here, either the limiting probability when restricted to the forest, either it is zero, it's almost surely false or almost surely true. Now we go to this constant and I say the limiting probability, well, F is the property of this random graph being a cyclic. So is the limiting probability that this HN is empty, that you only have components which are trees? What is this limiting probability? It's relatively easy to show because of these asymptotic independence that this is infinite product given by the Poisson distribution. You do a little algebra and you find this function. Here is a plot of this function. When C goes to zero, the probability of being a cyclic goes to one. When you approach the critical point of the phase transition, the probability of being a cyclic goes to zero. And C zero is exactly the point, which is zero point nine something when the probability is one half. So C zero is this constant when the probability that the random graph is a cyclic is exactly one half. Now I take a first order property. What I'm going to write down here should be limiting probability of A when N goes to infinity, but then the screen would be too crowded. So I'm using this as limiting probabilities. And I just use this elementary law of total probabilities. The probability of A is the probability of A conditioned to F times the probability of F, the probability of F was this, and the probability of A conditioned to non F times the complementary probability one minus F. Now we have say that this probability of A conditioned to this random forest is either zero or one. If it is one, if this is one, then this probability is at least FC. But since we are here below, the probability is larger than one half because this function is decreasing. At C zero, the probability is exactly one half. So if you are below, this function is decreasing and then the probability will be larger. Good. And so you see if this happens, this probability is larger than one half. If on the other hand, the probability of A conditioned to the forest is zero and this is zero, then this probability is at most a probability times one minus F of C, which is larger, smaller than one half. So no probability, no probability can be between one minus F of C, which is less than one half and F of C, which is larger than one half. And this is a gap. Just by this property, well, I remark this is not a first order property. Okay. Being a cyclic, this is not a first order property. But if I take any first order property conditioning to F, it's either one or it's either zero by the arguments before. Good. Very good. So this is the second part. Any questions so far? Now, we have to show finally that in between this critical value here and one, again, there is no gap. And also we'll see that these limiting probabilities, the closure is a union of finding many intervals. Good. So the structure of the random graph here, since we are in the subcritical regime, actually, this should be less than one because the case C equals to one has already been covered here. So maybe this, I really should have put here less than one because we are in the subcritical regime and then there are only trees and unicyclic components. There is another piece that we need, that this part of the unicyclic components in expectation is bounded. So you have to imagine this random graph that has not a giant forest, a super giant forest, that with high probability contains everything except a constant number of vertices. And this constant number of vertices form the unicyclic components. Maybe I should have put a drawing. I hope everyone knows have the image of a unicyclic graph as a cycle in which we attach rooted trees to any of its vertices. Restricting to this forest, we have a zero one low. So this forest with respect to first order property, they always satisfy the same properties. So whether these random graphs satisfies a property depends only on HN that we call the fragment. Well, this notion of fragment was introduced by calling the army in a different context. And we find it convenient to use also the fragment. Okay, well, I'm making signs with my hands, but I realize you cannot see me because this is really my, my first online talk. So I will try to explain verbally. There is this huge forest contains almost everything. And there is a bounded part that is bounded in expectation that contains these unicyclic components. And we call the fragment. Now, what do we prove? And this takes some, well, this needs some work. The probability that the fragment is isomorphic to a given collection of unicyclic graphs converges as n goes to infinity. So the limiting probability that the fragment is isomorphic, let's say to one triangle with these trees attached one pentagon with these trees attached converges. And the limit depends only on this function F that we defined before on the constant C on the number of vertices, and on the number of automorphisms. The number of automorphisms is rather natural because this H is an unlabeled graph. And what is the probability that this label graph is isomorphic to this unlabeled graph? It is quite natural that the automorphisms of these play a role. Good. So the probability that the fragment is isomorphic to this fixed H converges to this constant. Now, what happens that the probability that a random graph satisfies a property, you have to sum over all fragments that together with the forest make the property whole. Because we just said that this property depends only on the fragment. So the probability that G n satisfies the property, you have to sum over all fragments that make this probability, this property whole. So this is a this is a sum, probably an infinite sum. But it is a subsum of this convergent series. Well, we have to show that this is a full probability. So if you sum this pH over all possible fragments, you get one. And then it follows that this closure we are interested is the collection of subsums of this series. It is not immediate. Okay. So when I say that this limiting probability is equal to the sum, then you need some work to show that actually the closure is the collection of subsums of this series. This is not difficult. You have to write it down. And this this is this is so in our paper, which is available in the as an archive file. But at least now we have a description of this set, which is the thing we are interested in. These pH are well defined for every fragment. You can compute these pH. You take this series, which is convergent, and the sum is equal to one. And then you consider all the subsums, either finite or infinite. These are non-negative terms. So even if you take infinite of them, this will always be convergent because this is an unconditional convergent series of non-negative terms. So this is what really makes the analysis possible, that we have characterized our set in terms of subsums of a series. Okay. Any questions before? No? Okay. I'm checking the time. I think I'm doing fine. Now there is this result. It was somehow mentioned by Kakeya, Kakeya, the famous Kakeya of Kakeya sets, about a century ago, but he really didn't prove it. But it was then there were some intermediate papers. This is just a result on analysis. Maybe I could say first year analysis. Well, for good students of first year. It says you take a convergent series of non-negative terms. Right? So the PN are non-negative and the series is convergence. And we are interested in the set of sums of this convergent series. If we have this condition that for every term of the series, the i-th term is less than the tail for every term in the series, then the set of subsums is the whole possible interval between zero and the sum of the series. So this is the empty sum. This is the sum consisting of all the terms. And if this condition holds, then the set of sums is precisely this. This is a very interesting paper because it says that if otherwise the term is larger than the tail, then this set is either a cantor set or a modification of a cantor set. So you have this really two extremes. Either it's a very simple set, which is a union, it's a whole interval, or it is a cantor set. And if you want to just check, take the geometric series of ratio one half, which follows into this. And if you take the geometric series of ratio one third, then you get exactly the cantor set because you are the triadic expression of the numbers between zero. Good. So what we do is the following. This is the sum we are considering. Well, this doesn't look like a series, but we can turn it into a series by ordering the limiting probabilities of the fragments. So we have all these possible infinite fragments. And then what we do is that these probabilities of the fragments here, we order in decreasing order. Let me tell you that always this ordering will depend on the constant C because since these probabilities depend on C, this ordering will change with C. What does not change is that the larger probability is always that the fragment is empty. And fragment empty, okay. Fragment empty means that the graph is a cyclic. Is that clear? Okay. Fragment empty, fragment empty means that the graph has no h n. So no unicyclic graphs. So it is a, it is a cyclic. Good. Now we have to check this condition here. That the term is less than the tail. And then we consider how many vertices has the fragment h. And we say, okay, if we sum the probabilities of the fragments for all vertices with k vertices, because of the previous formula, we get this. And then we show that this condition that the term is less than the tail. It's true for all the fragments of size, at least four. Because you can have enough h with very few automorphisms so that this sum grows very large. And you can prove that this sum is above the i-th term of the series. Now every fragment has size at least three. And the only fragment of size three is a triangle. And there you can complete the argument. And as I said before, p0 is the probability. Can you remind what is the pk? Oh, the pk are the limiting probabilities of the fragment ordered in decreasing order. But what does the index stand for? The index just stands here. The largest probability, which always is going to be the probability of being a cyclic, and then maybe the probability that the fragment is a triangle, all the possible fragments, each of them has a given probability. Okay, so what we do is just we order them in decreasing order, whatever it is. But here this is not a pk. This is the sum of all p i when the number of vertices in the fragment is k. Is that clear now? Okay, good. So this is true for all fragments of size at least four and for fragments of size three. But there is still one, which is the fragment, empty fragment. And here we have to show that p0, which is the large of them, the tail, because it is ordinarily is one minus p0. So we have to check this condition. But this condition means that p0 is about one-half. But p0 is about one-half precisely because c is about c0. Because when p is equal to c0, the probability of being a cyclic is one-half. When we are above, this probability is larger because this function was decreasing. When we are above this value, the probability is less than one-half. So really we have covered all the cases. And this completes the proof. Well, except that there is another companion of this theorem, if this condition and the term is less than the tail, not for all i, but for i large enough, then this set is a union of five and many intervals. And this is a condition that is already contained in this check that we did below. So summarizing, we have shown that this is always a union of intervals. Above or at c0, there are no gaps. And below c0, there is at least one gap. Good. There are more questions one could ask. How many gaps are depending on c? And if anyone is interested, you can ask in the questions about these things. Just to summarize, what do you call a fragment? The fragment is related to the sentence from the first order sentence or from the first structure. The fragment is the collection, I think it's defined here. What is the fragment? Yeah, the fragment is defined here. No, it is, where did I define the fragment? Here. The fragment is the union of unicyclic components. There is no logic. It's only combinatorics. The components are either trees or unicycles. The fragment is like a complex subgraph. It's not complex because they have complexity zero. The number of edges is equal to the number of vertices. There are no complex components. So union means non-overlapping? Yes, I mean the connected components are the joint, right? So you take those that are trees and the union forms a forest and the union of unicyclic graphs, it's the fragment, right? And then you numerate over all finite possibilities, like all possible shapes. Exactly. All possible fragments. Yes, exactly. All possible fragments. Well, these graphs are finite, so this has to be finite. Good. How do you deal with the automorphisms? Like they're almost surely one? No, the automorphisms are here. And this is an unlabeled graph. So it's a class of isomorphic graphs. And then these, in the GMP, the graphs are labeled. So the probability that this label graph is isomorphic to something depends on the size of the graph, on the constant that defines the probability model, and of course, on the number of automorphisms. This is the number of automorphisms of this unlabeled graph. Okay? I mean, this is something that you can check. You just write the probability of each unicyclic graph. You take the probability of all of them. This is a computation. And the number of automorphisms appears here. Well, now what I wanted to say are two things. We have generalized these to sparse hypergraphs. What is a hypergraph? Okay. What is this? Oh, no. Okay, now this is d-hypergraphs. Well, a hypergraph, this is a uniform hypergraph in which every edge has a d vertices. So ordinary graphs are two hypergraphs. And then we take every d-edge independently with probability p. Now, sparse means that we take the probability proportional to 1 over n to the d minus 1. Notice that it d is equal to 1, d is equal to 2, and this is 1 over n, which is what we had for graphs. The expected number of edges is the probability of any edge times the number of edges, so the number of d subsets. And sparse means that this is linear. And again, we have proved something similar, which is we take the unique possible root of this equation. Now, you see the d is here. So the root of this equation will depend on c. And then again, we prove that the limiting probabilities, the union and the closure from the union of intervals, and we have the same theorem as before. Well, it is not difficult. It is extending the things, but then you have to deal with automorphism of hypergraphs, and you need some more work. Good. And I think now my time is almost over. So this is my last slide. Just to mention that there are several variants that you can investigate. Okay, we have, I have worked on random planar graphs, random forests, random graphs from a minor close class. We have worked on GNP, and then we generalize to sparse hypergraphs. And this is a project that we have started with my student, and he's a colleague now in Barcelona. And then we consider random graphs with a given degree sequence. This is a model that has been very much studied in the last decades, because maybe it is closer to real work, real world networks than the GNP model. And then this DIN is the number of vertices of degree i. Right? So you consider for every n a sequence of numbers that give you the number of vertices of degree i. Well, this has to be a feasible degree distribution. It has to be sum to an even number, blah, blah, blah. But suppose this is the case. Well, the total number of vertices is n. And suppose that this holds that the proportion of vertices of degree i, among all vertices converges to a constant. So the proportion of vertices of degree i is asymptotically some lambda i. And you assume that the first and second moment are finite. So this is the expected degree. And this is the second moment of the degree distribution. Now there is a classical result. And this has been extended and refined, in particular by my colleague Guillem, that when there is a giant component in this model, well, this model are sparse graphs, because you see the expected degree is finite. So the number of edges with high probability is going to be linear at most. And then you take this combination, which is the second moment minus two times the first moment. And there is a giant component, even if this is larger than zero. And again, you can use a heuristic, exploring a graph from a first vertex by a branching process, and then studied when the process dies out with high probability. And we consider the same. We take the closure of the set of limiting probabilities of first-order properties for random graphs with this given degree sequence. Well, maybe you are aware that to study this model, you take what is called the configuration model, and then you take perfect matchings among half edges to produce a random graph with this distribution. And then the question is what is this? And we are trying to investigate this, because in fact, the GNP model at the end will be a kind of particular case of this, because in the GNP model, the degree distribution is a Poisson law with very high concentration. And we have found some partial results that I will not mention because this is working ongoing work. But we believe that probably, just depending on this first and second moment, we will be able to characterize this limiting probability, the set of limiting probabilities and the closure, and maybe to find some result which is similar to this. And that in particular implies this. So this is just to say that there are several interesting models that you can analyze. And we are not aware of other groups that have investigated not single limiting probabilities, but the set of all of them. And why do we study them? Because I think we believe it's a nice problem. Okay. So this is the end of my talk. And thank you for your attention. Thank you very much. I do find it really interesting and nice to work with. Yes, let's thank Mark for this nice talk. Are there any questions, comments, ideas for all the models? Okay, please. So maybe remark, because with graphs with given degree sequence, like I could suggest a straightforward generalization by taking graphs with degree constraints, which is like a Boltzmann relaxation for given degree sequence. And if you say that the threshold point is expressed as a probability of having no unicycles is equal to one-half, then like of course you could try to express very similar things. Like it's interesting because the point of phase transition in the model of graphs with degree set constraints is also shifting. So like to see how they both could shift or maybe overlap, like I think it's totally doable. And very interesting. Yeah. Because you mentioned your approach is not like pure analytic, but you're rather like, I think both can be done in this case. No, no, I think we have already obtained the limiting law for the number of cycles, but it's not so straightforward as in GNP. And this is why in the team we have Gilliam, which is the really expert, the real expert on this. For instance, Gilliam together with Reed, they have really extended the conditions for the existence of a giant component. And but there are some things that you can prove and about also if you are in the subcritical case, what is the shape of the components and all that, but it's too early to really to, but we are confident that we will be able to get to the end of this problem. Okay. Thanks, Sergei. Are there any other questions or comments? If not, I would like to ask a very general question which concerns hypergraphs. So I know about this face, face phenomenon that happens for regular graphs. Is it the same for hypergraphs? And that's why you take this P, which is of this order? Is it so that if P is less than of lower order, then there are no big components or? Yeah, yeah. It's the same. Yeah, there is a phase transition. There is a phase transition, which if I remember correctly, it's d minus two factorial over n above this probability, then you have a giant component and below you have the same structure of trees and unisactiles. Of course, in a cycle, in a hypergraph, I'm saying that I never remember is the title of the loose model in which the edges of the cycle intersect just at one vertex consecutively. But I don't remember who did this, maybe Karonsky or someone from the Poznan group. And again, there is a phase transition very similar to the one in random graphs. Okay, thanks. And one more question. Have you considered any monadic second order sentences in this setting? Yeah, for monadic second order just in GMP, there is not necessarily convergence. So this result of Lynch, there is a paper by Shella and Spencer, and they show already that in MSO, you don't necessarily have convergence. And yeah, but even though, and I believe that in this model, as we did for planar graphs, because for planar graphs, we work on MSO, I think it's the case that every MSO can be approximated by FO limiting probabilities. So very likely, the closure will be the same. But the main difference is already here, there are MSO properties that the limiting probability alternates between zero and one. This is this technique of Spencer that allows for construction of sentences that do not converge. Okay, Shella and Spencer is random structural algorithms, and you can find a discussion there. Yes, but this is a very good question in MSO. Yes. Thank you very much. And if there are no more questions, let's thank Mark again. Oh, yes. There's a question very much. I'm sorry, I didn't notice. Question in the chat. Yes. Oh, in the chat. Okay, I should be able to access the chat. Okay, so the question is, okay, I fear myself. I don't know why. Excuse me. Can you hear me twice or once on me? Okay, now it's okay. Some technical problems. So the question is, can the closure of LC is a finite union of intervals? Can be shown by using the fact that all what is are here? I'm sorry. Okay, this is this. I think this is how you construct exactly this set that you can, I don't know whether you see the question, the challenge will be much easier for you to understand. This is almost my first time we zoom. So I think, yeah, there is a chat. Oh, no, there is a chat. There is a chat here. Chat. Okay. Chat. And, okay, can these be shown by using the fact? Okay, my answer is I don't know, because I don't know what is an O minimal structure. Okay. So, I mean, I'm a relatively new comer to logic. So I cannot answer this question. But I would be happy to discuss this, because so real, real exponential, I guess this is the reals together with some product and taking exponentials. Yes. Yes. So the my question is that the set LC is the definable set in the first order logic with the language of Rx. No, I don't think so. I don't think so because these are the limiting probabilities. How are you going to express these limiting probabilities in first order? But according to Lynch's theorem, these limiting probability can be expressed by some finite combination of process. Well, yes, by some finite combination, right? So they exist and there is a finite combination. Yes. So the my question is that there is some so back to could you back to go back to the Lynch's result? I think it is here. Okay. So my question is that so I don't know, I don't know the proof of the Lynch's result, but can we obtain some? Okay, so it's a bit harder to explain. Maybe we can discuss later. Yes. Yes. Sorry. The proof actually depends on just taking, well, you take the quantifier depth of formula. Suppose it is L and then it is enough to look at cycles of length at most L of radios at most three to the L. This is a typical proof of this engagement result. And then you see that everything depends on this. And then there are finally a number of types and then you sum of the types essentially. Okay. But we can we can discuss later if you wish. Okay. But okay. So I understand that maybe the answer is no. Thank you. Okay. And I would be grateful if you tell me about these minimal models that I don't know. Okay. Okay. Thanks again for this question. It might be very inspiring. Are there any other comments or questions? Okay. I don't see and I don't hear anymore. So let's thank Mark again. And with this we end this session and we meet at


Awesome. Thank you so much for that intro. And I'm really looking forward to delivering this webinar. Although the topic of compliance to some can be pretty boring. Zero trust kind of a marketing buzzword these days. But some of the technologies that we're going to use to to implement or can use to implement a zero trust environment and solve for a lot of the compliance. The challenges that that we see certainly around networking. You know the technology itself is pretty exciting. And so we're going to start with kind of an overview of the landscape. What is, what is trust if we're going to talk about zero trust. And then we're going to, well, I know that. You know, webinars like this we're going to have a wide distribution of audience members some people who are interested in the advanced stuff some people who are brand new and just getting into this so we'll try to set the context for everyone and and and get into it. So my name is Christian Posta. I'm a global field CTO here at a company called solo.io. And what we work on is service mesh technology. And I've been involved with with the service mesh ecosystem for quite a long time now. I've been involved in working with customers and large organizations who are deploying things like microservices and containers and Kubernetes. My background is in connecting systems through integration and messaging and generally distributed systems. I've written a few books on the topics that we're going to be talking about today. Including Istio in action, which was published probably a year ago, still very relevant and up to date, mostly because the project has become very mature and you know things aren't changing very, very much. However, one area of the technology that is undergoing some innovation right now is in the in the data plane. And Lynn son and I recently co authored a book published back in October around basically the topic we're going to discuss today so I won't go into too much of that right now.  Our enterprises are not all that and all that all that cut and clean and nice. Right. There's, there's a lot of we do it here because that's how we've always done it. There's a lot of we have we're doing it this way because that's what security told us we have to do. Or, you know, just a whole whole combination of reasons but we what we do is we try to. We try to offer a solution to problems that have cropped up as people start to adopt modern platforms, certainly around services service connectivity around security, certainly and that's why we'll be talking about some of the topics today. And, you know, we based our platforms and our technology on open source projects, like Istio, for example, Istio is the service that we'll be talking about today. Like things like evpf that we can use to implement and improve the behavior of some of the networking technologies that that we're using. And so a solo, you know, we've been working with a large number of customers around the world, very successfully to solve challenges around observability and security and connectivity. And we're certainly leaders in some of these open source projects. And, you know, we have a lot of a lot of insight into how to be successful with these technologies. So let's go back to the meat of the webinar here. And that's around compliance, zero trust, and what technologies we might be able to use to implement and solve for some of these, these challenges. But if we're going to talk about zero trust or no trust, then we should talk about what what what is trust. It's a very stationary and look it up. It's fairly consistent from what we want to talk about here. But it's about representing yourself or some entity and credibly understanding what that entity is going to do that it says it's going to do that there's credibility in in that in that entity. And that, you know, they have, they might get access to certain data, certain services, resources, I guess we'll call them more generically, based on this trust. And in organizations today or maybe more classically. That type of that type of trust or over trusting leads to scenarios that are not very positive for those companies you see things like security breaches customer data, you know, financial data. And this happens quite a lot. Unfortunately, and a big part of how that that trust in a system, a distributed information system is created is through the classic approach to applying security to an organizational boundary. And oftentimes that's seen as or known as perimeter based security. If we just stand up these big walls around our organization and our network, then, you know, we'll keep the bad people are the bad actors out. And you'll probably see this is obviously a simplification but you'll see, you know, there is a path for traffic to come in into an organization through various firewalls, you know, perimeter based like demilitarized zones that might be facing the internet, corporate internal networks, maybe establishing VPNs into these corporate networks. And then if you're a developer, you're building services API is probably familiar with, we'll go into a little bit more the, the, some of the complexity that it takes to get access to data and databases and that's for, you know, the noble reason at least to try to secure and align with the clients, because we want to keep the bad actors from gaining access to this sensitive data, which is, you know, customer data internal financial data, and other sensitive information. What am I, you know, going a level deeper. I resonate with some folks, certainly, again, those that are working at large enterprises that rely on things like DMZ security that rely heavily on the firewalling appliances that most likely live in those environments, and how the network and the security has been constructed to align with things like compliance and regulatory oversight and so on. And I see things like gateways at the application layers API gateways that handle traffic coming in from the internet, or even just traffic internally inside the organization. What will you, what you see, what you see here is traffic is segmented. Right. The DMZ can't directly talk to, let's say, the core databases, or maybe mainframes, but certain layers can. But if you look at each individual layer, there is a lot of trust in each of those layers where we're assuming that if you're in one of those layers, that you might have access to other services or the components of the resources within those layers. And maybe if you can somehow impersonate being a resource in that layer, you can get to some of the other layers as well. And so that's where we kind of want to rethink, or at least understand what is the trust that we're giving to a particular part of the system, and what is the blast radius what can happen in those scenarios. Because it's not just the outside. Look, you know, trying to get in. There are things like configurations. There are things like policies. There are scenarios where is a perfectly running good API, but we're sharing too much information in those API's. There are certainly scenarios where bad actors don't breach or somehow overcome the firewall, they're invited in, and through phishing social engineering type attacks, and they're just there. So the question doesn't become, you know, how do we keep these bad actors out? It's once they get in, how do we limit the access and their lateral movement and the trust that's inherent in the system we need to scope down so that these bad actors can't take advantage of that. Now, that was that, you know, the last couple of diagrams we've looked at are kind of thinking about one organization and, you know, at its most simplistic form. But in reality, these organizations as they modernize their technology, they look for ways to move quicker and experiment with technology they adopt cloud services. They want to want to build a platform that allows them to go quicker. So they're using containers and cloud automation, CI CD built around it and so on. We'll see that there's a natural evolution of the technology stat, some running on premises, probably a lot running on premises, and, you know, things moving to a public cloud. And maybe multiple public clouds. And so the this idea of well here's the perimeter, and this is what makes up our corporate network is, is obviously is dissolving in this case. Because the applications are being deployed onto these cloud networks, and we don't own the organization doesn't own these cloud networks is somebody else's infrastructure that we're renting right. And so now that that corporate network is, is highly distributed, and is, you know, who owns it, what are the, what are the security, if you want to install firewalls and all this stuff. You know, there's a lot more that goes into making that work and a lot more areas for that can fall short. Well, you throw on top of it, that the the business functions that these these organizations are there for. And whether that's financial companies, whether that's health, you know, health insurance health, the health related those retail that are handling financial transactions and so on. And the federal agencies, like these are governed by, you know, regulations and laws and rules that they have to, and should, you know, hold closely and guard and secure the sensitive information that gets shared with them from whether it's customers or financial information or other. And there's various compliance and restrictions and, like I said, regulatory and and an audit that happened to ensure that this, these standards are upheld. And we can look at each, each one of them. They're not all that exciting. As I mentioned in the beginning, they all they all kind of boiled down to what would seem like common sense things but are not all that common. And that is maintaining a secure network, restricting access to sensitive information. And when there are vulnerabilities discovered tracking understanding that they exist the paying attention, potentially working with, with governing bodies or vendors or partners who can help with this and implement strong controls and and networking controls and access to this, this data, so that not just anyone can can access it. And what, what we've seen is, and, you know, the implementation and ends up sort of looking like this. But as I, as I also mentioned, you know, as we go to highly dynamic environments, like spinning up a VM on the fly, tearing it down spinning up containers on the fly scheduling them across multiple machines. Maybe across multiple clusters and multiple clouds. And just the fact that you're going to a public call all of all of these things make the, the classic way of looking at solving these problems by establishing boundaries and and parameters. So, a lot less, you know, impactful, because there's, there's, you know, we don't take into account inherent trust that gets placed in those boundaries. And so that's where this idea of zero trust comes into the picture. And what we want to do is we want to restrict down to the smallest possible scope where trust is granted. And we, we assume that just because you're in one of these parameters are in these boundaries.  In other words, we want to, we want to constantly assume that they're that, you know, basically just assume things are on the public internet. Everything's hostile. Everything's coming to get you. And that when services need to communicate with each other, or when an API or an application needs to share data that we should on demand we should we should prove that the the actor that's requesting that is trustworthy. And we want to continue to do that. We want to scrutinize all of the access and we want to log all of the access and we want to be able to go back and and see exactly what has happened. And so, and like I said, we want to we want to eliminate trust islands or, or, you know, we want to scope the, the, who we trust and where we trust them down as far as possible. So if we come back and look at that very simplified by oversimplified diagram. We want traffic as it comes in to be authenticated. We wanted to so we want to know who it is want to be authorized. So based on who it is and what services are being called, what are they allowed access to. And we want to do that dynamically. And we want, we want to do that in such a way that holds up. So you can see in this diagram where we're maybe in the, in the past we would have an API gateway that might be looking at and establishing some of those properties authentication authorization in one spot. We don't want to just trust that because the traffic makes to that gateway that it's all good. We don't want lateral movement. So what we want to do is we want to continuously and dynamically enforce the same security properties on any request on any service service access. If that means across multiple different clusters, different workload types, VMs containers, functions of service. We want to uphold these, these principles of zero trust, regardless of where the applications are running. Now there's quite a lot of literature on this that kind of kind of goes into some more, more detail things like the NIST standards around zero trust things like the Google cloud papers. There's some very early papers from, I think it's the Department of Defense that they discussed this even 20 years ago. And so there's a lot of good, I would call it, you know, academic papers on these things but when it comes down to how you actually implement this, there's a lot of opinions. And I would argue that until recently it's been kind of difficult to implement this consistently and in a performant way because the technology wasn't ready for it. But if we boil it down a little bit more and talk in specifics. What we want to establish is that communication in the network is to any resources is secured, regardless of what islands or firewall or boundary or perimeter is established. So all communication, even it's inside, especially if it's inside one of those permitters. The, the access is determined dynamically. It is determined per session or you can think that you can think more concretely for every request that's coming into a service and not just not just the open a connection. Firewalls typically are looking at can a layer three layer four connection be established. We want to go deeper than that. Can a request be sent. Can it be received and can it be serviced by a resource. And since we're determining this dynamically that can change. So, you know, from request to request, we have this fine grained control over our, you know, where and when we're establishing trust. All access is authenticated authorized. And this access is tracked it's logged audited, we can we can go back and review it. And based on, you know, we can dynamically also control access. So, if we're seeing that a particular user in the system is requesting a sensitive data. And it's unusual, let's say that it would, it would request this data, what a pick a number I don't have a certain number of times 20 times. Then, you know, after, after about 1015 20 we'll start to notice and the system can automatically reverse some of the, some of the access that had already been given. And if you look at the way at least abstractly that zero trust networking and these types of architectures are implemented. It's usually with some kind of coordination between a policy enforcement point that is handling traffic on behalf of a resource, and some policy engine. And then this engine together with some administrator that's the, you know, driving driving the policy changes that might be needed. So these these policy enforcement points that in line with the with the request and decisions are made in line and dynamically based on certain policies that have been set or different parameters that again could be dynamic. And various attributes and context of the request that can be evaluated. Now, again, this is a very abstract way of, of looking at a, how you would implement this. But this isn't certainly an area where service mesh, a technology that's specifically built for these types of dynamic environments can help service mesh. There's a lot of a lot of overlap with the, you know, in terms of implementation, a lot of overlap with with a model like this. And so from here what we're going to do is we take a look at how a service mesh might fit. But we also want to see how the evolution of service mesh, and how we can refine and improve the implementation of service mesh, so that we don't end up with these policy enforcement points scattered and littered all over the place unnecessarily. So we got to start with what is, what is a service mesh. I'll go through this kind of quickly but the, the idea behind the service mesh is to solve some of the challenges that come up when applications want to communicate with each other. Security is a big part of that. When services communicate with each other, usually we're looking at APIs, communicating services, services service, and we're thinking more along the lines of requests and messages that are being sent. You know, they have to solve for, you know, those, those networking challenges that we see in service to service communication, like service discovery, load balancing, resilience aspects. When services are not available. Can we fall back, can we retry, at least be thinking about things like timeouts. When you start building distributed systems we have to think quite a bit differently than if we were just building a, you know, monolithic type application, because the network is such a critical player in the implementation. So we go and solve for things like resilience, like telemetry collection, like security, and, and so on. If, if, especially if we have a lot of different programming languages, you know, we need to have a way to solve these problems consistently. And not worry about maintaining certain libraries or frameworks. Not worry about all the overhead of governance and making sure that developers use the right languages frameworks the correct way, patching, maintaining, patching CV ease, fixing bugs, etc. Across this becomes pretty, you know, there's a large, a large amount of investment that has to go into that. So with the service mesh, what we, what we see is we implement those networking challenges like connectivity security reliability, etc. As a agent that lives with the application and the application instance. And this agent gets deployed with the application instance handles these things on its behalf. And if you're, if you're, if you're insightful enough, you'll notice that this agent becomes or can become a enforcement point of certain networking and security policies. So in the service mesh, we have these little agents, they run with the, the applications they act as proxies, they act as policy enforcement points, and they are all remotely controlled and configured by a component we call the control plane. So the control plane is connecting to these various agents and it's giving the agents dynamically, it's, you know, what policies it's supposed to be enforcing. And those agents can reach back out to elements of the control plane to more dynamically determine, you know, what, what, what a policy should be and policies are usually should this request continue, or should it not continue. And that, that determination is based on who's calling the service on behalf of what user and other attributes like location, like time like claims that the user might have. And so on. So you can start to see that the service mesh has a lot of the elements and the architecture for implementing the zero trust networking principles that we're after. And here's maybe a more simplified example where they were an application wants to talk to another application. And so the request from the app on the left side, when it talks over the network will be, you know, will be forced through this agent or this proxy that then, you know, does things like service discovery load balancing timeouts retries telemetry collection. And also do things like originating TLS or expecting that the transport will require mutual TLS. So it can coordinate with the control plane get the correct certificates and, you know, start to encrypt and secure the channel for service to service communication. On the right hand side we can see the agent or the proxy on the app there can do the same thing. It can expect mutual TLS. It can enforce policies about whether the service on the left can even talk with this service. It can evaluate the requests that are coming through and dynamically determine whether those requests are allowed through. And fundamentally the service mesh here can also establish workload identity for each of these services. So we know without a doubt the service on the left let's say we call it food is the food service and the service on the right called bars is that service. So for identity, we can get networking policies based on identity, not on IP addresses and location of network and so on, but actually on on workload identity. And, and then we can get an encrypted trap tunnel between these services, we can't have man in the middle we can't have ease eavesdroppers and so on, trying to capture the traffic to replay it. And then we can write fine grain authorization policies about how that, how that traffic is allowed to continue. So I was generically describing a service mesh but we know at solo, at least we are heavily invested in Istio and the Istio community. We see that service mesh as the most dominant service mesh as the most mature service mesh. And that, that observation comes from, you know, first of all a period of neutrality because from about 2017 to say 2019 we were sitting and watching and seeing what what is happening in the service mesh space because it was a lot of different it wasn't clear who was going to take off was in around 2019 and a lot of work that we were doing in the community. You know we we saw that okay it's it's pretty clear now Istio is becoming very well adopted a lot of those those thorny edge cases and use cases that we would see in the enterprise were being. They were being, you know, softened and we were able to make it fit. And now now advanced use cases multi cluster VMS all of that stuff is very well capable of handling. And we saw last fall 2022 that Istio officially made it into the CNCF. And, you know, has has a regular deployment release has the a lot of contributions from the community, very diverse involvement and continuing to see massive adoption of this technology. But we talked a little bit about the model here that service mesh presents. We, you know, we can see that it has the components has the pieces in the right places to to implement a zero trust networking architecture. However, what we're going to talk about for the rest of this webinar now is, can this be improved. Are there are there some drawbacks to sending a bunch of different agents and proxies out out there. And, you know, can that be improved so the first thing I'll point you to is a blog that we've wrote a year and a half ago now. We represented where, where we were looking as we being here here at solo where we were looking in terms of service mesh. Some of the, some of the innovation that was possible. What were the challenges we were seeing our customers run into service mesh adoption is primarily led by some of these security and compliance requirements. But once you start operationalizing the mesh. What are what are some of the friction points. What are some of the, what are some of the issues that people will run into. And so we wrote this blog, and it kind of outlined for different for different areas that our customer base our user base was very interested in. And how we can, you know, get better resource overhead, or how we can isolate feature usage and configuration between different teams, a little better and and security and need to operations upgrading. These were the variables that we were looking through. And, and we after ourselves for some of the challenges that crop up. Is there a different model where we can get the same, or the good parts of the service mesh and alleviate some of the, the challenging parts. And so we looked at different models maybe side cars not the only approach, maybe using something like a shared agent or shared proxy. You know, this will get you much better resource overhead, and and potentially upgrade impact is upgrade easier to upgrade if there's only one. And but we saw these as almost two extremes one that is extremely fine grained and gets great feature isolation, you know, good good security granularity, a little bit more difficult to upgrade. And then the other side of the word we flip the benefits and the pros and cons there, but is there something in the middle. Is there is an approach we can take this kind of in the middle that will give us the best of both worlds. And so this is what we, what we, what we talked about back in that, in that paper in that blog, a year and a half ago. We were actually working on this. We were actually building it at the time. And then just through our work in the community, you know, it's solo is a prominent leader in the SDO community. A lot of us here at solo, or part of the founding of the SDO community. And, you know, we have positions on the technical oversight committee on the steering committee and the various working groups. You know, so that we have a dedicated engineering team working on this deal directly so I mean we we we saw and worked with our partners and understood kind of what's happening and we came across that Google was working on something very similar. And so we ended up collaborating together, kind of proving out the whether this even makes any sense. And then in September, 2022, we announced that we would be contributing this work, sort of the beginnings of this work to the SD open source community and what it is, is an approach to running this deal. It's a car list mode that allows you to take advantage of the capabilities of the service mesh, including some of the properties around zero trust that we don't want. And do that in a way that simplifies operations.  And we can some of the side benefits are things like reducing costs right now we run fewer proxies have to think a little bit less about allocating resources for those proxies proxies in certain areas where we can improve performance of the mesh, especially if you're just leveraging the mesh for workload identity and networking policy. So we don't have to take on the full capabilities of a layer seven proxy, which is what, which is what the SEO data plane does today. And in the sidecar approach so a handful of different. I would call them ancillary benefits, but then also a handful of extremely beneficial operational benefits that we can get out of out of a model like this. We end up working. We saw in previous diagrams that the service mesh is implemented in terms of an agent, or a proxy that gets co located with the application instances in the SEO ambient data plane. We take those proxies out of the application. We don't take them out of the request path. So they're still in the request path. But what we end up doing is using a little bit lower level networking control to force traffic through what we're calling the secure overlay layer, secure transport secure overlay layer. So this layer is made up of agents that work closely with the CNI to implement the zero trust networking behaviors that that we want from from the service mesh. So this component, these components of the Z tunnels in this diagram. They take on the responsibility of assigning workload identity to the workloads on the node, and doing things like originating and terminating TLS for mutual TLS and enforcing networking policies based on these identities. Now, a service mesh needs to be able to do more than just, you know, establishing or not establishing connections we need to be able to understand what's in the request, what tokens or headers or claims are part of the request. And so we need to have layer seven understanding of what's happening in the service mesh as well and so what we've done is separate that out. So if you look at a request path, if you just if you don't need any of the layer seven introspection, then the traffic can stay in this secure overlay layer. And that is quite a bit faster than having to use any layer seven proxies, so the sidecar approach included, and, and we get the properties of zero trust that that we would need. If you want to include more sophisticated layer seven policies, then that traffic will then first go through the secure overlay layer, and then make it to a workload specific layer seven proxy or a waypoint proxy that we call it here. And that handles any other sophisticated layer seven aware policies that need to apply to a particular workload. In this case, you know, a service a is talking to service B, and those, you know, maybe maybe we're checking for tokens for checking claims or other opaque tokens, we verify that they're there that they haven't been tampered with. And then we will make decisions about what API is what endpoints and so on can be reached for for service being. So is the ambient mesh is, you know, does bring a lot of optimizations a lot of benefits to the studio project. We release it in September. It is, it's probably and actually just Friday this, this last week. You know, it moved into the SDO mainline of the code so it will be in the next release. And as well on its way certainly here on the solo side we're working on making this production ready very soon. And, you know, it comes with a lot of benefits. So we don't need to alter our deployments and inject side cars, agents, whatever. And you, you kind of sidestep some of the challenges that come up when you do have to do that. Certainly the folks on the webinar here that are familiar with injecting a side car and Kubernetes know there's some challenges there. There's race conditions between the containers, you know, job resources are not that don't play very well with side car containers. If you have your own in it containers, there's some collisions possible there. So without if you don't need to inject side cars you alleviate some of those, some of those cases, things like upgrading and patching of the service mesh infrastructure itself are done out of band of the application now. There was always a little friction, when you take a piece of infrastructure and kind of jam it in with the application. Right because the the the platforms the infrastructure they need to be serviced, they need to be maintained they need to be patched, and they probably do that on a different cadence and what the applications are doing. So that they probably need to decouple that. And here in the ambient data plan for Istio we see that upgrading patching, all this is transparent to the application. And we can do that with much more minimal oversight and governance and focus on coordination which apps can be restarted and so on. Other other areas we maintain a lot of the foundations of zero trust for network security that we have with the sidecar based service mesh. And, and we do see areas of improved performance, especially when you're just adopting the service mesh for for security. So that is where I'll end the presentation I'll do a quick demo here. And then I'll come back and we should have a few minutes for questions. Okay, so the first thing that you'll see is we have a Kubernetes cluster that is running is running some some more clothes here. There we see, just keeping this about as basic as you can get it Hello World, we have a sleep application we have a couple of Hello World applications. Some of these, these Hello World applications are deployed on on different nodes in cluster. We can see that there are at least two different nodes here. And if we come into the sleep application. We can call Hello World on port 5000. And we see we get responses, and those responses are low balance across those two different instances of Hello World. On the bottom pane, you can see that we have our default namespace we have some of the cube specific cluster namespaces, but we don't have Istio installed here. So we haven't installed Istio yeah if we go into default we can see that that that's where our sleep and Hello World is. Now if we come here we're going to install Istio. And we're going to do that and set the profile, equal to ambient, because we want to enable the ambient data plane for for Istio. So here we're going to give that a few moments to install. And what this is going to do is it's going to install Istio that you're probably familiar with if you are things like the control plane will be installed. I believe it'll install an ingress gateway. Yes, it looks like it is, and it'll install the components that are necessary to run in the ambient mode. So if we give that a second. We come back here. We should see now of the namespaces listed here Istio system is is one of those. So Istio has been installed click into it. We can see the Istio D, which is our control plane component. You see the ingress gateway, and you know a few components that make up the secure overlay layer, including the Z Tom. Now if we make a few calls that's actually let's let's come here let's let's go into the default namespace. We're going to take a look at the sleep app. And the application here is running on the new ambient worker. Okay, so if we come back and look at our diagrams here for requests to go through the service match they will first go through the secure overlay layer which is the Z tunnel component, and then eventually to their destination. So what I'm going to do is let's take a look at the Z tunnel component that's running on this node ambient worker. If we come here, the Istio system namespace we find Z tunnel, and we'll find the Z tunnel that's running on the ambient worker node. We take a look at our logs will full screen that. And if we make some calls here. We'll see we're not not seeing any, any traffic go through. And because we haven't, we haven't told Istio that these applications should be part of the mesh. In the sidecar approach what you do is you install the sidecar, but we don't want to install the sidecar. What we want to do is we want to include those workloads in the match, but we'll do do it some some other way, dynamic way and the way we're going to do that is by labeling our workloads with with a particular label that says hey you're part of the service mesh, the ambient service mesh. If we do that. And we come back. And now, when we call hello world. We should see access logs going through the Z tunnel components and on the bottom pane here. And we should also see that the traffic is starting to use mutual TLS. And is is is verifying things like spiffy IDs and workload IDs and so on. And that the traffic is going to the Z tunnel so by click hello we should see down on the bottom access logging that confirms that indeed our traffic is going through the Z tunnel now. And then we can see based on some of what the logs look like that we are going through the components that require mutual TLS. So I'm doing a little bit short on time I could pull up the, you know, TCP down for wire shark to show you that it is mutual TLS. But I can lead I can point you to another, another demo that does that. Okay, so that's, that's good we get mutual TLS we can enforce traffic policies now because things are going through this service mesh. So what if we wanted to take advantage of some of the layer seven capabilities that a service mesh brings into the picture. Maybe we want to test what you know how our security posture changes or behaves when things start to fail. The golden path or the, you know, the expected path going, but when things start to become chaotic. How do you think how does how does our security posture behave there. And in service and the Istio and the service mesh what we can do is layer seven policies like checking for jot tokens, injecting faults, controlling traffic routing and so on. And in ambient mesh what we what we do is see we deploy the waypoint proxy. So we will, let's do that first I'll show you the deploy the waypoint proxy and that proxy is this right here. Because we want to see this we want to end up seeing traffic go through the waypoint proxy and have layer seven capabilities applied. And if we come here. We should see a waypoint proxy has now been deployed that represents hello world. It's been running for 23 seconds. And now what we want to do is create a layer seven policy. And that injects a delay, whenever we call the hello world service, and the delay is established for five seconds so if I add this. Come back to my applications and call hello world, cross our fingers, we should see traffic go through Z tunnel and we should see the traffic delayed by five seconds because it's now going to the waypoint proxy. One, two, three, four, five. Right. And so now we would get the full behavior of fault injection and layer seven that we expect from a service mesh. But again, if you come back and look at my workloads. I don't have any sidecar proxies running in fact these workloads have been running for, you know, quite a long time. It's been running for a very long time. It's been running for a very long time. It's been running for a very long time. And the only thing we've deployed is a single proxy that represents hello world, and still gives us the, the layer seven granularity that we need for enforcing certain networking policies or security policies. Now if we decide that we don't want service mesh anymore. We want to remove it, but then we will unlabel or label, remove the label, the data plane label, and then we will install Istio, using the normal, normal approach to uninstalling Istio. And then if we come back here we'll see the Istio system namespace should get.  I think I have a install this. And we'll see the Istio system namespace will go away. Our application work, you know workloads are still up and running, like they've been running, and we can still call Hello World. Now we don't take any advantage of any of the service mesh capabilities, but the applications haven't been touched. So that's the end of the demo there. Let me let me leave you with a few resources. We've, we've written a white paper that goes into more detail about how this all comes together, and specifically around Istio ambient mesh. We've built a few some other top some other content around how a how we mesh or a gateway and mesh technology together combined can provide a fairly sophisticated set of zero trust controls. And then the last bit I didn't go into what we, you know, the the products here at solar but we actually tie this in deeper into the into the CNI into the lower layer network. So you can think of solo as an enterprise service mesh that is built specifically to be more secure than than what people see in the community or any of our other competitors or anything like that. Take a look at academy.sola.io as a free resource for getting hands on with this technology. And obviously the, the blogs, the books, all the good stuff and then join us in the in the Istio community as well if you'd like to get involved. So that's all I all I have for for today. I know we've got a couple minutes left. Somebody asked about the slide deck. Yes, we will. So I will. I'll make these available to to the organizers here. I'll also tweet them from my, my Twitter account. It should be shown here, but I will make them available so I see a question here can the ambient mesh be integrated with a workload identity provider like fire. And the answer is yes, actually, we've done, we've done a lot of work with our customers to integrate spire for better workload attestation and identity issuing and Istio ambient is no different. We ambient actually the way the secure overlay layer works that works similarly enough to how the sidecars work to get workload identity. So being able to plug spire in would be, you know, it's fairly straightforward and something that we're working on. So definitely can ambient mesh function across clusters similar to a sidecar mesh so basically asking. I believe about multi cluster support potentially routing, failover that kind of stuff. And the answer is yes. That is something we are actively working on right now. And I think we do have some working working POC's around that. When we announced Istio back in September we knew that there were a couple gaps between what the, what the ambient approach could do and what the sidecar approach can do. And certainly here at solo we've been working on closing those gaps and we're almost there. We're actually very close to being there and multi cluster, cross cluster, failover, etc. So in most of those use cases are very core and near and dear to what we do here at solo so yes ambient mesh will definitely be supporting that. Thank you for your question. Another question that I so and I'm happy to take any others or we can do it offline to but another question that I get is, if you're already running sidecars. Introduce ambient. And along those lines, you know, going forward what will be the default for for Istio. And so the answer the first part of that question is definitely yes. The, the ambient approach and the sidecar approach are interoperable with each other. And this is a path that we can that we will, you know, continue to document and and show for kind of transitioning from a sidecar to a data sidecar list approach. The longer term is the ambient will likely be the default data plane in in Istio, and we would reserve the sidecar approach which is not going away for more for use cases where you need a little bit more control. You need dedicated resources and and policy enforcement. Usually those would be edge cases but we certainly don't expect the sidecar approach to go away. So I know that's, that's my time, and I don't want to overstay my welcome here. But certainly reach out to me. I'll post slides. I'll make them available to the organizers and I appreciate you all for for joining me on this webinar. Thank you so much Christian for your time today and thank you everyone for joining us as a reminder this recording will be on the Linux foundations YouTube page later today. We hope you join us for future webinars and have a wonderful day.


Mother's reaction after seeing what's under the blanket goes viral. Welcoming a newborn is a beautiful thing. Still, deliveries can be quite exhausting, both emotionally and physically. Lauren, the protagonist of our story, gave an extraordinary effort to deliver her daughter. Throughout the whole process, Chad McDevitt, who is her boyfriend and father of the child, was there to support her. By the time the newborn was delivered, Lauren was extremely drained yet happy that they just became parents. Although Lauren was going through a postpartum shock, Chad and her family were celebrating together, in the hospital, that Everly was successfully brought into the world. They had wanted to become parents again for some time, and now that it happened, both Chad and Lauren were filled with joy. According to the witnesses, they couldn't get enough of looking at how beautiful Everly is. Compared to the moments during the delivery, the minutes after the baby was born were extremely enjoyable, even though Lauren was utterly exhausted from the few hours of effort. With that in mind, no one expected that the main surprise was yet to come. Once Lauren removed the blanket from Everly, she couldn't believe her eyes. As we have mentioned above, Lauren and Chad already had parenting experience, as before Everly being born, they already had a son. It has been their greatest wish to parent another child and even better if it was a daughter. What they wanted came true as in November 2014, Lauren found out that they have conceived a baby. Absolutely hyped about the fact that he would become a father for the second time, Chad decided to invite friends and their family members to come over to the hospital and thus pay a visit to Lauren and Everly, who was just a day old at that time. The majority of invited people answered the call, which resulted in the hospital room being swarmed by visitors from all sides. Although tired, Lauren didn't have anything against this, and she was enjoying all the good wishes and congratulations that they got. Among all the visitors, it was Lauren's aunt that spent the most time caressing Everly and walking around with her. During this time, Lauren was able to take a break though she was completely awake, mostly due to the excitement and adrenaline that was rushing through her veins. Although more than several people were present, no one, including Lauren, had a clue about what was beneath the blanket. That makes this story even more surprising. Everyone was giggling, filled with joy and happiness with the opportunity to meet Everly, and congratulate Lauren and Chad. While excitement is common for post-deliveries, we are sure that the Kentucky hospital was pretty impressed with the number of people who paid a visit. During their playtime, Lauren's aunt noticed that something was different, apparently, Everly had a little accident. Of course, this was nothing to stress about. She was just 24 hours old at the time, and this was to be expected. They called in a nurse, and minutes later, Everly got taken care of. According to the nurses, she needed additional parental attention, which Chad and Lauren were glad to give. Sometime after the nurse was called over, they decided to pass the baby back to Lauren. The one who did it was Chad, her boyfriend, who couldn't hold his excitement and kissed Everly before putting her in Lauren's hands.  As soon as she got Everly into her arms, she had to comment about how the diaper work that the nurses did was pretty impressive. According to her, she was never too confident with the swaddles with her first baby. Chad was pretty entertained with Lauren's commentary, which is why he decided to post a YouTube video that became viral just a couple of days ago. The mother was happy to have the baby with her but couldn't sense what was happening underneath. At this moment, the only one who was aware of the shocking truth was Everly, and she didn't know how to let others know before they found out. Not only were they excited that they are all in a room with the newborn baby but also happy that the little accident was taken care of and no one was expecting another surprise. Yes, even the nurse that did such a great job swaddling the baby, at the end of the day, she has years of experience, was aware of what is yet to be revealed. While Lauren was the one who wanted to change the diaper, everyone in the room was pretty clear in saying that it should be done by someone who is more rested and experienced, that was the nurse. Putting a lot of trust in the staff of the Kentucky Hospital, Lauren didn't have anything against it. Frankly, she was craving to get that rest. When the baby was finally wrapped, some of the visitors wanted to take a closer look. No one of the friends and family, even Lauren and Chad, didn't get an opportunity to see more than just the head of the baby, mostly because Everly was perfectly swaddled. Still, after the diapers were changed, one of Lauren's friends requested that she be unveiled so they can take a full look at her. Everyone present, including Laura, felt a unique kind of excitement exactly because they didn't know what to expect. It was completely justified because what they saw underneath was pretty shocking. It is safe to say that Lauren went completely pale. While everyone else was excited with the opportunity to see Everly, Lauren didn't share their enthusiasm. She simply wanted to enjoy the time with her baby. We understand her. The first couple of days since the delivery are considered to be essential for strengthening the mutual bond between the mother and the child. Still, the fact that Lauren didn't want to spend a lot of time on particular acts is the main reason why she didn't protest against unveiling her baby. Both she and Chad were amazed by her looks, and they wanted to show to other visitors the full beauty that Everly holds. Little did they know that they will be the ones that are surprised. We already said that Lauren and Chad were incredibly excited to become parents for the second time. They were even more excited because it was a daughter, as they already had a son. However, life, as it is, comes with a lot of uncertainty which is why it is justified that they couldn't expect what was about to come. Although Lauren complimented the swaddle that the nurse created, she very soon found out that it was a bit too tight. This was a bit fishy to her, as she had a lot of issues with unwrapping and showing Everly to all the visitors. As things usually are, everything is done for a reason. With that in mind, the nurse apparently knew why she had to create a tight swaddle. But what was hidden? At this point, it was pretty clear to everyone that Everly wasn't feeling as comfortable in the tight swaddle. To everyone's relief, Lauren was able to unwrap her. Still, there was more than a single reason to be worried, and the mother was already sensing some kind of trouble. At the particular moment that Everly has unwrapped, everyone in the room was trying to hold their breath, hoping to admire the beauty of the newly born child. That was something that Lauren and Chad were expecting, but the second that she was unwrapped, everyone was pretty confused. Given that Lauren was the first one to be shocked, she wasn't sure whether she was hallucinating or things were simply off. The main reason why she was as confused was that the mother was well aware of her postpartum condition. Everyone understood that Laura paused for a moment and tried to figure out what she saw. Still, no one had the opportunity to take a look at Everly and try to make things more clear. That is when Laura shrieked, which startled all the visitors as they were sure that she might be feeling ill or that something disastrous happened. With every second of the silence, the mystery was even bigger, and everyone was worried about what is to come. Some visitors thought that the baby may have been replaced and that it was the reason for Lauren to shriek. Others were sure that Lauren was simply experiencing some postpartum symptoms, but no one could put a finger on what was the cause or how they could help. While under huge shock, Laura was present enough to call Chad for help. There wasn't anyone better who could help her understand what is underneath the blanket than the father of Everly. Still, as it seemed, Chad couldn't figure out what was happening either. By this time, everyone was pretty sure that the expectations the parents had for the baby were completely off, and the pure excitement was filled with uncertainty and sadness all across the room. Yes, Chad couldn't help Laura understand what was beneath the blanket, but contrary to her, he was completely calm. At no point did he shriek or startle, which contributed to the mystery. On the other side of the room, everyone looked directly at the nurse that changed the swaddle, now sure that she had to do something with the shocking discovery. As minutes went by, no one said anything, but everyone was simply looking at Lauren, who moved her hands back and forth, caressing Everly and trying to detect whether the shock was real. Finally, after a couple of visitors got a glimpse, they could determine that it was something related to her onesie. Lauren later suggested that if it wasn't for the number of people in the room, she probably wouldn't have been as confused, and the mystery would end much sooner. While Chad continued to stay calm and seem like he understands every bit of the situation, Lauren shouted, yes, and looked over to the nurse. Once again, everyone was sure that it was the nurse who knew what was going on with Everly's onesie and why Lauren was startled. The most confusing part was that the size of the onesie was completely the same as that of Everly's body. Additionally, there was something that no one could get their finger on but Chad. In the end, everything was carefully planned out by Chad and the nurse. To be honest, it has to be one of the most romantic proposals ever.  On the other hand, both Chad and Lauren were crying and enjoying the unforgettable moment. Guess what the ring was? At Everly's hands. While Lauren and everyone else present went through an emotional roller coaster, it was all worth it in the end. Most importantly, she said yes, and after years of being together, Chad and Lauren were about to marry. No one would have thought that just 24 hours after she had delivered a beautiful daughter, the mother will have something else to celebrate and be happy about.