Hi everyone! My name is Paul Roisler and the paper that I present today is joint work together with Alexandra Bienstock and Jefgy Nydotis. The title of our paper is on the price of concurrency in group-rejecting protocols. Before I turn to concurrency and I explain what the price in this setting means, I will first give you an idea of what group-rejecting is. Group-rejecting protocols have the following core functionality. They enable members of a group to jointly establish group keys. With these group keys these users can then, for example, protect their conversations in group chats and instant messaging. As instant messaging is the core deployment scenario for group-rejecting protocols, we consider the following threat. Adversaries are able to expose the local secrets that users use to compute and establish their group keys. Thereby these adversaries of course also obtain the group keys for a while until, for example, these group members can recover from these exposures. Exposures are realistic mainly because on the one hand group chats and instant messaging often take a very long time and on the other hand users use their mobile devices for communicating in such chats. Thereby the accessibility of these adversaries to these secrets is potentially increased. Now these group members can recover from such exposures as soon as the adversary has no access to these secrets anymore. In the following way these group members can sample new secrets and with these new secrets they can derive public values that they can then share in the group and as soon as every group member who has been exposed recovered via such a sharing of new public values these group members should be able to compute a group secure group key again. Now as you can see here if these users recover in a sequential schedule this takes a very long time potentially even linear in the number of group members. On the one hand it can be very realistic in groups that if there is no scheduling algorithm that these users concurrently initiate their recovery. On the other hand if they can do so and if the protocol is able to process such in simultaneously initiated recoveries then also the time that is used for effective recovery is significantly decreased. So we think that a main target of such group ratcheting protocols should be on the one hand reaching post-compromise security meaning reaching recovery from such exposures and this very quickly ideally and also the shares that these users distribute in order to recover from these exposures should be minimal in order to keep the communication overhead small and finally as I already mentioned it would be helpful and desirable if these recovery can recoveries can be handed concurrently. I already mentioned the problems if protocols do not achieve these goals on the one hand the recovery takes a very long time and on the other hand if only recoveries in a sequential schedules a schedule can be processed then this needs some kind of a coordination mechanism and this often requires consensus protocols which are either either inapplicable or very inefficient for decentralized networks. Okay after sketching the ideas and goals of our work I will next give you an idea of why previous protocols were not able to both achieve post-compromise security and do this for concurrently initiated recovery attempts. After giving you an idea or an overview of a previous work I will look at onto our lower bound result. This result tells you that there is a minimal communication overhead that is necessary for users to concurrently recover from exposures. After looking at this lower bound I will introduce our construction of group budgeting that achieves a communication overhead that is very close to our lower bound and thereby we provide an upper bound that is almost optimal. I will close the talk with questions that we leave open for future work. Okay so let's look at what previous constructions for group budgeting did. Their main approach bases on dynamic group key exchange protocols which have a long history in the literature mainly from the 80s to the early 2000s. The main idea behind this is that users who have been exposed can be considered as unwanted identities who are members of a group. So in order to recover I for example could be an exposed user who has an unwanted identity and what I would do is I would remove my previous or current identity and then after the adversary ends the access to my device I would generate a fresh identity and add this identity to the group. It turns out that mainly tree-based dynamic group key exchange protocols fit well especially for the settings in instant messaging where we have asynchronous communication and where we want to reduce the communication overhead. So due to the tree-based structure we have essentially logarithmic overhead in the number of group members for recovering. And also what is very helpful is that these removes and addings of users in these tree-based protocols can be conducted non-interactively. So the main idea is that all the members of a group are structured and represented by the leaves in a tree. So all these users have secrets and public values and all the secrets and public values that these users have in their own leaf and on the path to the common root are stored on the devices of each member. So the joint group key who is then stored in all local states of the members can be considered and essentially is the joint group key. Now as you see here as I mentioned I store all the secrets that are on the path from my own leaf to the root. The main contributions of early works on group ratcheting are that they observe that this merging of adding and removing or vice versa adding of removing and adding can be used to realize group ratcheting. Another main contribution is that these works specifically by Karthik Bhagavan and Richard Barnes and Eric Raskola observed that you can generalize the idea of Diffie-Hellman trees to key encapsulation mechanism trees. So abstractly coming from this Diffie-Hellman specific way to the abstract public key encryption idea. Now I will give you an idea how these constructions work. If for example Charlie wants to recover from an exposure Charlie simply samples a new value XC prime and from this XC prime Charlie generates a new key pair for the only leaf. Charlie then also obtains and deterministically derives another secret as a seed for the parent of this leaf node of Charlie. Then from this new seed XC prime D Charlie generates a key pair for this parent node and Charlie continues to do this for all the remaining parents on the path from the leaf to the root. In order to let the other users know the nodes on their own paths Charlie will encrypt to the respective siblings on that path on to these respective public keys of these siblings. So essentially for letting Dave know the common parent with Charlie the seed that is then used for on the one hand to generate the new key pair of the parent of Charlie and Dave but also to generate the root key pair. Charlie simply encrypts this XC prime D to the public key of Dave. After doing this recovery all the secrets that Charlie previously knew are now updated and thereby the adversary when only exposing the secrets of Charlie does not have any or does not know any current secrets in this tree anymore. There are many more works that enhanced these ideas of updating these secrets in these trees for example increasing or enhancing the forward secrecy guarantees or keeping a balanced tree structure or even providing security against active adversaries. The main problem of all these ideas and strategies is that they do not achieve these goals that we are looking for namely concurrency for recovery. The main goal that I want or the main problem that I want to mention here is that if Charlie and Dave at the same time try to recover from exposures of their old secrets they would encrypt these newly generated secrets to the public keys of an old state. So these public keys remain to old secret keys and these users want to recover from these potentially old exposed secret keys but the problem is that they don't know of new public keys of the respective partner yet so what they would still do is they would encrypt the new secrets to the old secret keys and thereby they would not recover from these exposures effectively. So what you would essentially need is potentially multi-party non-interactive key exchange for which we do not have any efficient constructions yet. Okay so what you see here is that all of these protocols indeed achieve post-compromise security with very little overhead namely logarithmic in the number of group members but they all do not really achieve concurrency. There are some ways to circumvent the problems of concurrency but mostly all these circumventions do not achieve either good overhead so little overhead or do not achieve post-compromise security. For example the MLS draft the current version version 9 achieves concurrency and post-compromise security but in this case it degrades from a tree kind of to a linear structure and thereby a linear overhead and the number of group members is achieved which is not desirable. Similarly another approach to handle concurrency is to keep a tree structure but in this case post-compromise security similar to the way that I just sketched is not achieved. Okay there are other attempts and ways to achieve messaging and group-ratcheting for the purpose of establishing a group conversations. A group conversation for example WhatsApp simply uses forward secure deterministic hash chains to update the secrets in a group and thereby they achieve a minimal overhead of only constant in the number of group members and they can also handle concurrency but what they cannot do is they cannot achieve post-compromise security. Another approach is by Signal and this approach has very recently been analyzed formally and this approach is simply using the pairwise channels between each pair of group members and thereby on the one hand achieving post-compromise security as these pairwise channels are secure or post-compromise secure and also achieving concurrency as these pairwise channels are independent of each other but since every group message has then to be encrypted for n different pairwise channels the overhead is of course linear which we don't want to have. So the question that we ask in this work is is there a better way to achieve both post- compromise security and concurrency with a significantly better overhead than linear in the number of group members. Okay I will answer this question first with our minimal lower bound for the overhead. Okay so for analyzing the communication overhead in our work we introduce and develop a symbolic model. A symbolic model means that all the entities in this model use variables that are just abstract symbols so these symbols do not have any bit representation nor an algebraic structure so what algorithms can do with these variables are following fixed transition rules. So in our model we define these transition rules, transition rules I will give you some examples in a second and what we also model in our symbolic model is that group rotating protocols can only communicate in a round-based fashion but within this round-based session they can of course also be invoked concurrently and thereby what we analyze essentially is concurrency in this round-based execution model. Okay so group rotating constructions can use the following fixed set of building blocks. By fixing the set of building blocks we reduce our consideration to the relevant building blocks and essentially exclude exotic building blocks such as multi-linear maps, multi-party non-interactive key exchange or obfuscation or something similar which is neither efficient nor really realistic. So these building blocks are dual pseudo-random functions so for example you can derive from random coins, further random coins or you can derive from symmetric key, further symmetric keys and we consider key-updateable public key encryption and broadcast encryption. So our modeling of key-updateable public key encryption is essentially as strong and thereby captures hierarchical identity-based encryption. This is relevant as a very recent work on very strong group rotating also uses HIV. We also show that key-updateable public key encryption is necessary to realize two-party two-party rotating in our work that I will present at Azure Crypt this year. So what you see here are the different are the different transition rules that we use for example if you have a message and a public key you can derive a ciphertext from it or if you have a ciphertext with a fitting asymmetric key then you can derive a message from it or if you have an asymmetric key you can derive a fitting public key and you can update your public key to a new public key with key-updateable public key encryption or a secret key to a new secret key. So this is the way that these algorithms are restricted to compute only what we provide them to be able to compute. There are many more rules you can see the full details in our paper and what we want to emphasize here is that all these rules and thereby all these building blocks model everything that previous group rotating constructions already used. So we do not restrict these constructions further than necessary and not even further than what these previous constructions essentially used. Our approach is partially inspired by the very interesting from my perspective very important work by Michandra and Pandrani from EuroCrypt 2004 in which they prove a lower bound on the communication complexity for forward secure multicast encryption and their result shows that if requiring forward security from something that is similar to dynamic group key exchange is required to send logarithmic in the number of group members symbols to the group. So potentially since we consider post-compromise security and they consider forward secrecy our two results may additively apply to group budgeting. Okay so let's look at our proof idea. The proof idea starts as with what I just mentioned so group budgeting protocols are restricted to only use the symbolic building blocks and only follow our transition rules. And these group budgeting constructions are required to compute secure group keys whenever it is required by our definition and I will give you an or an idea of this definition in a second. So first of all secure or group keys are secure by definition if they cannot be derived by adversaries who also only follow the transition rules in our symbolic model. And thereby this means that the adversary can only on the one hand use the symbols that this adversary obtains by exposing the local secrets of users and thereby obtaining these secrets and computing and deriving other values via transition rules. And also the adversary sees all the symbols that are communicated via the public channel via which also the users recover. And the requirement is that as soon as every user who has been exposed once shared new information and afterwards one further user also shared some information then the next group key that is computed is required to be secure again. And in this case the group budgeting protocol has to compute such a key that is not derivable by the transition rules that we define by an adversary. Okay so these are the requirements and our proof statement is as follows. We prove that when establishing such secure group keys under key concurrency meaning that T users or T members simultaneously try to recover from their exporters then every message that these recovering members send is at least or contains at least T minus one symbols. So symbols in this case means distinct secrets or distinct public values that these users for recovering share. Then I will give you some further details on our proof idea for the full details again I refer you to our full paper. So our proof looks at three different rounds and these rounds begin with an exposure of group members in this case four members. So in this round I minus one these four members are exposed and you observe here that neither of these exposed members has any secure and undarrivable secrets in their state anymore. So the adversary can derive all the secrets that these users know. The second round is now or allows now these members who have previously been exposed to recover from this exporter. So what these users now do is since they still do not have any secrets in their state they sample and generate new secrets and from these secrets they can derive via the transition rules further values. Just specifically they can derive new public values that they can then share in the entire group. Essentially what happens here is that all these four users generate and sample distinct own secret values and from these secret values they derive distinct own other symbols. Specifically they all derive and share distinct public values. Observe and I will mention this in a second again that these public values cannot be merged somehow. Even if we allow would allow for non-interactive key exchange then an outsider can even with non-interactive key exchange not merge these public values and this is a key observation here. Now for recovering as I mentioned in the final round the users who sent in this round I help these previous users who want to recover to effectively recover and then all these users can compute a secure joint group key again. Now in this last round what senders can do is they can respond to the public values that have previously been shared in this round and essentially what a user has to do is sending to each public value that has been proposed in the previous round individually. Now as we may have multiple senders in this last round and they cannot coordinate because they are acting simultaneously and essentially concurrently each user who sends in round I has to send the same amount of information. Essentially as we have two senders in this example here each of these two senders has to send potentially even four values to the public keys from the last round. This is a very very high-level idea that I just sketch here for the full details that are potentially a little bit more complex. Please have a look into our paper. Now what you see here is of course the sender if helping his himself when recovering also in the last round so if a sender sends both in rounds I minus one and I the sender does not need to send to him or herself in round I again but to all remaining members and therefore what we see here is that I mentioned it already this user cannot merge these public values from the last round but what I wanted to say is that every member has to send T messages to the T recoveries from the last round and as we have potentially T concurrency so in every step in every round T senders we have T squared messages per round which which is an overhead of T per round per sender. OK so this is a very high-level idea of our lower bound let's look now onto our construction for the upper bound. Our construction basis on the idea of having a tree-based tree structure from the beginning of this talk that also other group-ratcheting protocols use. OK so now let's look at these four users what they do is for example if Charlie and Dave are exposed in this case then of course their paths are known or all the secrets that are linked to the nodes on the path from the leaf to the root are known to the adversary so these two users would need to update all the secrets on these paths. What these users however is effectively do is they only update the leaves their own leaves so in round i-1 if they know they have been exposed or if they want to recover in case they think they could have been exposed is they simply generate a new key pair and this is everything they do in this round i-1. Now in the final round the senders in this case Alice and Dave first repeat the step that also happens in round i-1 namely they generate new key pairs but then they also help the senders from the previous round to update the nodes on their paths from the leaf to the root which is they generate key pairs for the joint parent of Charlie and Dave and the joint group key. Now this works as follows as I mentioned this already they sample secret values XC prime D prime and they derive from these values both a secret key for the parent of Charlie and Dave and from this value again a seed value with which the root key pair is generated. Now in order to distribute all relevant information first of all Alice and Dave for sending this information to Charlie and Dave they encrypt to the new public keys of the new key pairs from round i-1 of Charlie and Dave this newly generated seed XC prime D prime with which these both users can derive all the secrets on their path from their leaves to the root. This has a size of ti-1 which is in our example here too. Now also all remaining users would need to know the secrets that they would need to have in order to derive all the secrets and public values from their siblings to the paths of the updated paths of Charlie and Dave. So in this case the common parent of Alice and Bob would need to obtain the information necessary to obtain the joint group key and this can be reduced to degree one notes in Steiner trees. So you can look at this if you want to know the details in our paper. Essentially the overhead or the communication complexity that is induced for encrypting information and distributing information to all siblings to the paths of the previously updating members from round i-1 is ti-1 times log of n over ti-1. Okay so summing these two results up gives us the following communication complexity t plus t times log n over t for t concurrency. So this generalizes or becomes specifically precise to the one concurrency case with log n and for the n concurrency case that can also be handled by for example the signal approach that I mentioned at the beginning of this talk to o of n. Okay so again this has only been a very high level sketch of our idea please look for the full details into our paper. Now we can observe here now that after we identify the problem that neither of previous protocols both achieved post-compromise security concurrency and a small overhead. With our lower bound we see and prove that there is actually a minimal communication complexity namely for t concurrency the overhead is t and with our upper bound we kind of confirm this lower bound or at least give a matching upper bound which is t times 1 plus log n over t. So this upper bound has only a logarithmic additional factor. So open questions that remain after our work is how to close the gap which is this logarithmic factor between our upper bound and our lower bound. Also we only consider a round-based execution schedule and therefore we do not really consider full asynchronous which future work can also solve. Another question that we do not entirely solve is which role noninteractive key exchange so not multi-party noninteractive key exchange but two-party noninteractive key exchange plays in this scenario. We assume that it doesn't really play a role and we give kind of arguments for this but this keeps an open question for future work. Also what one can consider is a delay for achieving post-compromise security which can potentially reduce the necessary overhead. Also we do not consider forward secrecy in our lower bound so potentially the lower bound is even higher if both forward secrecy and post-compromise security are required. And finally of course our results are applicable to the MLS draft as we solve this concurrency problem and issue much more efficient than the current version although of course our current idea and our construction has some drawbacks compared to the current idea of the MLS draft. Okay so the full details and the formal proofs for our work are available of course on E-Print and you can always contact me via email or via Twitter. Thank you very much for your attention.


All right, ladies and gentlemen, welcome again. My name is Dimitri Peroulis, and it's my pleasure to welcome you to the second part of our distinguished lecture series, the panel, the panel on the future of Microsoft Design. The panel is moderated by Professor Karl Handrecker, and I'll pass the mic to her in just a minute. Professor Handrecker is the Reinhardt-Sumann Junior Professor of Materials Engineering and Environmental and Ecological Engineering here at Purdue. She is a fellow of both the Mineralist Metals and Materials Society, as well as the Materials Research Society. Her research interests are in the areas of thermodynamic and kinetic theory and experiments of phase transformations and interface motion. So let's give a big welcome to Professor Handrecker. Thank you very much, Dimitri. So we have this wonderful panel here.  Professor Zhihang Chen, Professor of Electrical and Computer Engineering, and her specialty is in new interconnect designs back into the line processing, and she has as a leader of an SRC center. She might say a few words about that. The next is Anand Raghunathan. Anand is another Professor of Electrical and Computer Engineering, and his specialty is in design of semiconductors. He is the deputy director, co-director of an SRC center and neuromorphic computing. And our fourth panelist is Professor Ganesh Subarayan, Professor of Mechanical Engineering. His specialty is in all types of mechanics, including solving very complex fracture mechanics problems that Ravi mentioned before, but for electronic packaging and other systems. And he is the director of the SRC center in heterogeneous integration and advanced packaging. What we decided to do today was not just to have this simple panel discussion, we decided to also have a discussion with you about how they would tell you, how they got, where they got. Ravi, you've already talked a little bit about that, but how they got, where they got, what excited them. And so just to give you a little more guidance as graduate students and postdocs and in some cases undergraduates as you take your next steps. So we're going to start first with Ravi. Can you guys hear me OK? So you have a few slides. Yes, I have two slides. Though I cheated a little bit, I took one slide, made a photo out of it and added it to the first slide. So there's really three slides. But we'll count it as two. Personal background, married one child, that is the daughter. If you look closely, you will see her little finger that's around which I am wrapped. I'm an avid fan of cricket, which those of you who follow cricket are not very happy right now because of the way, you know, how miserably India is playing right now. I like Indian classical music. I have a deep and abiding interest in history. And this is where I really, really appreciate knowing Ganesh because he gives me a lot of insight in history when I talk to him. And some literature. I was born and brought up in Maximum City, wonderful book if you haven't read it, Mumbai. My father was a self-made engineer. He worked his way through and became an engineer through his own hard work. And my mother was a high school teacher who became a high school principal. Both of them are tremendous role models. They really influence the way I think. I am the middle of three brothers. Both my brothers are quite successful and they are successful because our parents sort of instilled discipline and more interestingly, the desire to learn, which I think is very, very useful. You see the pictures, I put all my brothers, my wife Poonam is over there and my daughter Ananya in between. My mother at age 70 went on a trip and reached up to Mount Kailash and was able to walk there.  She could click once. Now, how I got here, I got a bachelor's in mechanical engineering out of the University of Bombay. It is now Mumbai, if you click once, yeah. I came to the US in 1986. I got a master's degree in experimental fracture mechanics, working with Professor K. Ravich and who is now at UT Austin. We studied how cracks evolve by studying the evolution of light patterns at the edge of cracks. The problem I was trying to solve experimentally was, what is the direction a crack takes when it is under applied stress? The basic work that led to this question and which helped a lot of fracture mechanics was written by that person you see on the right hand side, Professor Fazil Erdogan, very, very famous fracture mechanist and just as great a person as he was an individual. I had written to him after my master's and I said, I'd love to do a PhD under you. And he was kind enough, even though I do not really have the intellectual capacity to be his student, he gave me a scholarship to come to Lehigh and I worked under him five best years of my life. And in terms of people who inspire and change your life, I'd point to my parents, my brothers, Professor Ravichandar and Professor Erdogan. Tremendous person, one of the best people I have known. And last slide. So I wrote a little bit about what this panel could discuss. As I said in my talk, I see H.I. as a very important vehicle for performance. I also see the need for a roadmap, a much better roadmap than where we are today, which clearly says here is the challenge, here is what we ought to do about the challenge. I see collaborative industry, academy of partnerships, not just topstone guidance, it doesn't have to be that somebody says, here is what has to happen. I think the intellectual strength or depth in universities is tremendous. I see, if we work together, we should have a clean path to generate ideas, evolve these ideas to a point where they are matured and then we bring them in to feed the next generation. We always look for ideas that can feed the next generation. And in addition, a systematic pathway for workforce generation. So slightly longer, but I hope. Thank you very much. So, Professor Chen. Okay, and can you forward the slide? So I have one slide prepared for the research areas that I'm interested, but just like what Ravichandar did, I'm going to tell you a little bit about myself. I don't have pictures about myself or my family here, but then my training actually was in physics for both of my bachelor and PhD studies. And then when I started physics, like that was the dream I had as a high school senior student, I wanted to become a physicist, but the dream was not about condensed matter physics. I was hoping for high energy for all these astrology or like studying the universe type of physics. But then after finishing the bachelor, I was still having that dream, but when I entered the PhD program, I noticed that nanotechnology, nanomaterials became really the hot, hot topic. And when I look at under the electron microscope pictures of all these materials and all these devices, they were just so fascinating that I couldn't resist joining one of the very nice carbon nanotubes groups back in University of Florida. So my advisor was working with one of the Nobel laureate, Dr. Smalley, back then synthesizing the carbon nanotubes and trying to figure out the chemical and the mechanical properties. And so I got very attracted to that project and trying to figure out how to make those nanotubes as pure as possible, as sorted as possible that we can use them in electronic applications. And because of that type of work, that was preparing the materials for industrial application. So I got the opportunity to actually join IBM T.J. Wilson Research Center as a post-doc. And where actually back then, Dr. Faden Varus was very famous in the carbon nanotube electronics field. And so I joined his group and we were working on not only the materials and really tried to integrate carbon nanotubes into microchips. That was one of the IBM's secret that trying to replace all silicon transistors with carbon nanotubes. And so we worked almost 15 years in IBM T.J. Wilson Center on nanotubes. To the end of my research staff member career in IBM there, I was appointed as manager. Actually we had about 15 engineers working on carbon nanotubes trying to push into really manufacturing and hoping that we can have a wafer scale integration of carbon nanotube electronics. And that was a tough path that so many of us working on materials issues, devices issues and trying to do the integration. And then after so many years of working on the materials problems and the device problems, I eventually felt the barrier to push a new material into industrial production is bar bar high. And I was not personally patient enough to wait for that to become a production. And so then I decided to leave for academia because I felt that I still want to explore new science, new materials instead of pushing the last bit for material to become production. And that's when I found the Purdue, this perfect home for me here. I joined Purdue in 2010. And then like here actually the slide shows on the left hand side, I show the cross-section SEM picture of a microchip. So my early career was focusing on the bottom of the chips. We try to look for the new channel materials for front and the line transistor implementation. So that was my old career path. And after I joined Purdue, I realized probably not that much can be done for the front end. So I decided to work on the back end. You see that there are almost 10 to 12 layers of metal interconnects that are embedded in dielectrics that we can have the innovation. And so like that's one of the SRC centers that Carol just mentioned, that I'm the director of the new limits, SRC Encore New Limit Center. And in that center, we are actually looking to new materials and the new connect, new devices to solve the back-end line problems. So what problems does back-end line have these days? When you look at this microchip here, we are trying to scale the transistors into tens of nanometers. And all the interconnects, all the vias on the top also need to be scaled together. But then even copper interconnects, copper is one of the best metals, the second most conductive metals. However, even for copper, when you scale copper into tens of nanometer scale, they even become very resistive. Even the resistivity of these materials start to increase. And that's how we actually look for solutions, how to save the back-end line performance through new material innovation. And so on the right-hand side, we have these cartoons of two-dimensional materials. These are many, like, thousands of materials choices. We are looking into these atomically thin materials, trying to insert them into back-end line so that we can solve the copper interconnects resistivity problem. We can solve all the copper diffusion leakage problem in the back-end line. So that's one of the major topics that we are exploring in the new limits center. But if you look at the ACM picture again, there is actually more room, plenty of room available in the back-end line. Especially above the M5, M6, like the fifth and sixth layer above, you can look at the structures, the interconnects and the vias. They are huge. So there is actually plenty of room to add something to these vias and interconnects. And that's what many people now in the fields are doing. You see on the bottom, like 2018 CEA Latte in France actually demonstrated they can insert RM, resistive RM into the vias. So now you can actually have memory units very close by to the logic units that you can have computing memory. And all like actually for a lot of neomorphic architecture, that's actually required to have memory close by to logic. And on the other hand, you can also insert new types of transistors like a thin film transistors to the back-end of line. You cannot do that to the front-end of line because the processes are too different. But for back-end of line, you can introduce the TFTs that can control the power, can actually be the IO for high voltage conversion or these different functionalities. So my personal belief is there is so much innovation can be done to the back-end of line. And if you can actually not only having the new materials and new devices to improve the performance, but even add new functionalities to the back-end of line, that's really going to define the success of all the future macro chips. Thank you. Thank you. So, Professor Ray Nathan. Okay, thank you. Carol, I'm sorry I missed the memo on introducing myself. You could go back one, are you able to go back? We'll just keep the slide empty while I introduce myself. Please. So, like Ravi, I also grew up in a warmer place. I'll come back to that in a moment, but I also owe a lot to my parents. I've come to think of it, never thought of it this way, but I think my brother and I are probably first-generation college graduates from our family, but really owe a lot to our parents who instill the desire to learn and the long-term commitment to us. So, after my undergraduate degree at the Indian Institute of Technology in Madras, I frankly had no clue what I wanted to do. I knew I wanted to go to grad school because everybody around me was doing it, but I actually nearly joined Johns Hopkins to do biomedical engineering until the last minute, change of mind, and saw me making my way to Princeton to study electrical engineering and specifically computer engineering there. And I think I'm glad looking back, I made that choice. Although, BME is a great area, nothing against. So, after I graduated, I joined NEC, like Professor Chen. I also spent some time in the industry almost 12 years, to be precise, leading a group that looked at various technologies, system-on-chip, architecture, embedded computing, and had the good fortune of seeing some of our technologies make it past the value of death, get transferred into products with extremely learning experience. And then, in the mid-2000s, when NEC semiconductor business was spun off, I figured I wanted to stay closer to my hardware roots and managed to find a home here at Purdue in the fall of 2008. I'll say that I actually followed my brother, or maybe he will say that, Vijay is sitting back there in the audience. He was here a year before I was. I still put his leg saying he's the professor in the family because I've spent more years in the industry, so I've just crossed 50% now. So, hopefully I still try to keep a blend of my background from industry to guide whatever I do. Maybe you could click. Now, getting to my message for the panel, this is the time of the year where we always look for a few warm days, so I find myself looking at the weather forecast, so I thought I would structure my message as a forecast of sorts. So, in my mind, the future of microchips, and this is very much from my perspective, shaped by what I do, is gonna be intelligent. Artificial intelligence already is setting the pace in terms of both creating new markets for microchips for computing and setting the demand for compute. The figure on the top here shows that, actually in the last five to eight years, the growth in compute demand from AI is 10x per year. That's way faster than Moore's law. So, AI can certainly soak up any compute we throw at it and more. This is a fertile ground for innovation. And so, the Seabrick Center that I serve as associate director for, funded by SRC and DARPA, is really, this is one of the core problems we are solving, the AI compute efficiency. And the figure on the bottom actually shows the different generations of hardware platforms, CPUs, GPUs, more specialized accelerators. And they take you to compute efficiencies in the order of tens of tera-ops per watt, trillions of operations per second per watt of power. That's one way of quantifying compute efficiency. But given the insatiable demand of AI, there's always this question of what's next. If you'd like to learn more, I'm happy to talk about it later. A click, please. And the future of microchips is also very challenging, okay? As we all know, Moore's law in the form of increased numbers of transistors integrated, continues and hopefully will, thanks to heterogeneous integration and other innovations. But for quite some time, metrics like single thread performance, clock frequency and power have tapered off, right? And so it's really an increase, designers like me are challenged to use these transistors and translate them into meaningful value that customers will pay for, right? One of the recent trends is that specialization is a key to improve performance, right? So today, if you open up your phone, the chip in there, or even the chip in a laptop or in the server, it is a system on chip. It is heterogeneous. It has different types of components that are specialized for different workloads. As a result of this and many other factors, the design complexity and design cost of these chips is growing up tremendously. So the graph on the bottom actually shows the design cost. And we all think of fabs as costing billions of dollars. The projected design cost for a state-of-the-art 5 nanometer chip is half a billion dollars, okay? So it costs the same to design 20 or 30 chips as it would to create a fab. So that's very mind-boggling and that needs to be addressed. That might be the eventual limiter, perhaps. One more click, please.  Because we see increasingly diverse workloads driving growth in the semiconductor market, right? This is really unprecedented, you know, in compared to any other aspect of technology or human endeavor to see the increase that Moore's law has enabled over the past five or six decades. And it shows no signs of stopping and driving economic value. And a big part in that is that microchips are not go not just into platforms that we think of as computers, which itself span a diverse spectrum from data centers, you know, down to computers you hold in your hand, but also all of these other things that we don't really think of as computers have computing embedded inside them. And so I think, therefore, the future of microelectronics is bright. Lovely, thank you very much. Yeah, Professor Subarayan. Working, I don't know if this is working. Okay, great, thank you. Thank you so much. And it's a real pleasure for me to be in this panel. And one unique thing that you'll notice about this panel is every one of us didn't start our career in academia. We started somewhere else and we transitioned to academia. I, too, didn't start my career in academia. I started my career working for IBM. And then after a few years, I transitioned to academia. Before I go there, I'll describe a little bit about what interested me as an undergrad. I was doing mechanical engineering at Indian Institute of Technology, Madras. And I was very excited by optimal design for whatever reason that I found that interesting. So I wanted to pursue graduate program in mechanical engineering. I thought I'd be focusing on optimal design. I started and then one good thing about doing a graduate school at Cornell is Cornell admits you directly into a PhD. So it's either MS or slash PhD. So you can pursue either. And I liked PhD enough that I wanted to pursue a PhD. And I chose to do a, and they also had minors, and this is more for the students. They allow you to take minors. You need to do two minors. And I chose to, my first minor was straightforward. I chose computer science as my first minor. But I know that seemed to line up with my interest in optimization theories, et cetera, et cetera. So numerical analysis was what I was doing. But then around after the first year, I took my first solid mechanics class. That really excited me. And so I said, well, maybe this is what I should be doing more of. And I did more solid mechanics classes. And I did another minor relating to solid mechanics and then computational mechanics. So I did all that. And then when I finished my PhD, I had two options. My computer science minor advisor offered me a postdoc to continue doing non-linear optimization. So I could have continued doing that. Or I could have gone to work for IBM. I ended up working for IBM because it paid me a little bit more. Maybe it's bad decision, but I ended up going to IBM. So I ended up doing failure mechanics. Most of what I did in IBM was, why do things fail? So a lot of what Dr. Mahajan talked about. So failure mechanics. And then when I started at IBM, IBM had a great lab or package technology development. I worked in a technology development lab, not in a research lab, technology development lab. And the projects that we were working on in my first year would become products maybe five, 10 years down the road. We were working on a really exciting supercomputer. A product on Teflon circuit boards with 32 layers stacked. Real state-of-the-art supercomputer that was going to become a supercomputer five, 10 years down the roads. And unfortunately that got canned. Then I was working on projects of this year. And in my third year at IBM, I was working on projects of last year. I mean products of last year. So at that point in time, I needed some more challenge. I moved to academia at that point in time and I've been in academia. So I should say my entry into academia is accidental. So that's about how I came to academia. And a lot of what I do is a mix of the interest in solid mechanics, optimization, all of the theories that you hear. That's about my background. And what I don't, usually students think that I teach them but what I don't tell them is I learn a lot more from them than I teach them. So most of the, every one of my PhD students taught me a lot more than I have taught them. So I'm very grateful to all the PhD students who I've worked with over the years. So with that I'm gonna move to this slide. Try to keep it short. I think Ravi did a wonderful job. And so this is meant to be a high level slide explaining the critical need for heterogeneous integration. And this is the package that Ravi showed, maybe very briefly. And this is a little blurb from Intel about their new heterogeneously integrated package and how this represents, in my view, a dramatic jump in the level of complexity in heterogeneously integrated packages. And what goes into these kinds of package, Ravi can address that. Dr. Mahajan can address it a lot better than I can in terms of what challenges they overcame to build this product. But a significant fraction of the challenges would be thermomechanical challenges in fabricating these kinds of packages. You need to be able to make sure that they don't warp. You need to be able to make sure that the sort of joints, for instance, are of the right material. They need to last for a long time. Those are the kinds of issues that I work on broadly. So with that I'm gonna. Great, thank you very much everyone. So I think you've heard how excited they are about the work they're doing. And some of the pathways that they've taken to get there. The other thing that's important is that they're each working at the cutting edge of these technologies. Whether you're at the university or at a company. And so one of the things we want to really discuss today is how we can work better together. What are the ways that we can become more efficient and more creative? And the other thing you saw from all of them, they were having fun telling you about what they were doing. So this is all very much part of this. So what ideas do you all have in how we can work in a way together that we don't become a service organization? We've had some so Ganesh and Ravi and I have had some discussions about well how can you be really important to the process and be involved but you've got these big companies like Intel that have these huge teams. And so we're universities, just how do we find the role that the best roles that we can play? So Ravi do you want to start? Yep, I have a suggestion. I don't believe I have an answer but I have a suggestion. If you look at what Moore's law is, it was a projection. What Gordon Moore very intelligently did was he projected doubling and then people extrapolated the doubling. In enabling that doubling and creating an engineering infrastructure to make it happen and an industry out of it, people kept asking to hit the next note what do I have to do? If suppose we look at this from a packaging perspective and this is not my idea by the way, my former boss and other people at Intel did this. They said thermals, let's pick thermal resistance as a number and let's say generation over generation what is the scaling trend of thermal resistance? And we plot this and we say okay if this is a trend line to hit the fifth point when the industry is working on points one, two, and three, four and five what do we have to do? What technologies do we have to be brought to bear? What meteorologies have to be brought? What materials have to be brought? If you just look at problems like this electrical is the same thing. Electromigration resistance, pitch shrink and things like that. And then say that these are quote unquote the hard problems and we say I cannot just do this with copper, I have to do something else. Chances are we will be wrong in all the solutions we pick but chances are we will also be right in a few of them and if we make them succeed and figure out what does not work I suspect will be better served instead of reacting to an engineering problem and engineer faces on the floor today and tell you what is in the back of their mind the problem disappears six months from now but the intrinsic value of the problem doesn't. Like I'll give you a classic example. Things delaminate in packaging and they have delaminated for years and years right? So every time something delaminates people find a way to stick it better and we solve this problem but modeling the fracture of that interface having a tool that predicts the existence and the formation of fracture. A tool of this nature would have helped not would have does help us quite a bit. I think that's where Ganesh's work comes in. Having a tool that you can put in a model and predict something. That is infrastructure in my mind and that is fundamental infrastructure that we need. Similarly a new class of materials for thermals is another infrastructure need. I believe something of this nature will change the way industry academia interact as a service model to a developer of building blocks model and that I think will be the difference. Ravi, so that's a great insight. As academics we like to focus in our disciplines. If you ask me would I rather develop a computational tool for fracture mechanics than to do something else? I would really enjoy developing a tool for fracture mechanics. The guys who are developing tools here. But is it better for academia to organize itself disciplinary or is it better to have a grand challenge problem? Maybe a device that academia should prototype and maybe a challenging problem that thermals are specified, reliability is specified and academia works together collectively on a prototyping activity. What would be a better? I believe a grand challenge synthesizes thought much better than individual areas. And you know like I, though I'm not a complete fan of this I'm quite a fan of the way DARPA addresses problems. You know they describe a hard problem. They say five years from now solve it or 10 years from now. Put targets. Once you have a synthesized then you say develop a prototype. While you develop it if you pay attention to the constituent elements and make good choices. I suspect we will do better. I suspect we'll do better. Instead of individual disciplines because individual disciplines will lead to expertise in individual disciplines not a combined solution. Exactly. Maybe because of my industry background so I personally I'm very excited about the translational research, right? I would like to do research on new materials or new devices that can be adopted by industry eventually. So that's what I call translational research. And then like in the past when I saw that the academia like did their own research, published papers and then industrial labs like IBM or Intel also like do their own research and even publish their own papers. And then we also have a really wonderful like mechanisms like a semi-data research corporation. We have the CEO Todd Young conducted Todd Young and I just sitting here like a semi-data research corporation actually is funding a lot of university groups to do research. And so like this is actually the mechanism to connect academia research with the industry with the real technology. But now it's entering a point that I see actually maybe there is another need actually to have the industry researchers and the academia researcher to even share a platform that you can have the knowledge transfer even faster than through SRC. Because we see that sometimes through SRC we are funded for five years to create a recipes or process or discover new materials. It will probably take another five years for the semi-data companies to really adopt them. So is there a platform that we can really talk in the same lab knowing what industry process needs that we can modify our recipes quickly for them that they can adopt? So that's what I think maybe is the next phase of the semi-data technology development. Ravi, do you want to comment on that? I actually very much I'm in sync with this thought process. I fully agree. If you have a platform you can work on that's the way to do it. We just have to define it right in my view. You know the definition requires thought I was talking to somebody earlier today and I thought if we have a way to organize a group discussion among people with very few barriers on what intellectual property are I believe we could collectively describe a vision of what we should do. And a few visions will help quite a bit. And I agree, entities like SRC do a very good job of bringing like-minded people together and strengthening these kind of institutions to do work at a broader level with greater discussion is probably the right way to do it. Anand? Yeah, I just wanted to chime in on the grand challenge and I saw Todd nodding meaningfully a few times. Well, yeah, I'll share my experience with it, right? So I've been part of the SRC DARPA center ecosystem or it'll be next year, it'll be for 10 years. I think it's a wonderful program by the way. I've tremendously benefited of course from the funding but from the additional value that comes with being part of the research and the value we get from feedback from the sponsors. When we started Sea Break, the Center for Brains by Computing, we felt we had a coherent vision and based on the feedback that we got from the sponsors and Todd was kind of the messenger, conveying that for the first couple of years, we realized there was still a gap and it wasn't easy. It was by no means easy but it was very much worth it. The experience of trying to further crystallize that vision and define very specific goals pushed us in ways that I think eventually were very productive. So I'm certainly a big believer in that grand challenge driven research. That's great. So we're going to get to the Q and A from the audience in just a moment but I'd like to give the other panelists an opportunity to ask questions of Ravi. Actually, I had one question. I didn't get a chance after your seminar because the audience was asking questions. For most law scaling, it was rather clearly defined that every company is competing for the size, the dimension scaling and competing about the time, every two years. And the winner will be announced, every company will say, okay, I can do technologies this node. So for the advanced packaging and the heterogeneous integration, is there a quantitative metrics that the companies are also competing on? Yeah, absolutely. Though you have to distill it by market segment. Once you distill it by market segment, let's talk about high performance computing, for instance. In interconnect, we have targets. We actually wrote a table down which I am convinced is not entirely right but it gives you a sort of a framework on which. So yes, for interconnects, there is one for physical interconnects. The thermals we are still getting there for power delivery, we have targets, materials targets and performance targets. For high speed IO, we have targets. We have link length targets, we have power efficiency targets, we have bandwidth targets. So I would say there is a partial response to what you asked for. Are there targets? Yes, absolutely, I believe so. And I keep emphasizing the roadmap for a very simple reason. It is a non-partisan, publicly available roadmap. There may be errors in it but almost everybody can look at it and say, you know, I can do better. I'll give you an example. I was at Georgia Tech a couple of years ago and I had five generations listed in my table. The Georgia Tech guys put three more generations beyond it. You know, wonderful. I mean, it just says if three years a generation and eight generations, 24 years of research. Ravi, I'd like to ask you a couple of questions actually but feel free to address them jointly. First is how do you see AI workloads driving packaging and heterogeneous integration? Do you see that? And if so, what are the major ways in which they are? And the second question is all the innovations in packaging, what upstream effect do you think it's gonna have on the way we design those chips or chiplets? So I use AI workloads as an example to say, you know, like if you were to look at technological advances, you have to take the most challenging problem and describe what technological, AI workloads today represent the most challenging demand. So in that sense, you know, some of your numbers are interesting. You notice I put in a roofline graph in my thing also. If they say this is the maximal, the only thing you have to be a little bit careful about is if you invest the bulk of your energy in making that manufacturer friendly, you have to ask how big is the market for this in terms of sheer volume and is there a scaled down version that you ought to focus on? In my mind, that is the kind of thinking that has to percolate, but you know, setting technology challenges and going after these so-called DARPA hard problems, that's the right way to do it. I'm sorry, I missed your second question. Oh, design, how do you think packaging and integration?  We don't define the cars that run on your highways. If we build them right, your cars will run better. I would have loved to co-design it so that if we build a highway that is able to deal with only a 16 ton truck, you don't drive a 20 ton truck kind of deal. In other words, we could co-design. You could describe here is what the future is and we could collaborate to define an infrastructure that meets your needs. And my belief is that we are kind of neck and neck on what the demand is versus what the supply is today. And the directions we pick will be very much defined by the dinner. It was great to see your talk and great to hear the progress in technology, packaging technology, and also, for instance, you ended with Foveros and Ponte Vecchio, which is fantastic technology, all demonstrated in this wonderful product. What is the challenge that Intel sees for the next generation? I see 47 tiles, it seems like a jump relative to the other products that I've seen from other companies with smaller number of tiles. So what is the challenge that Intel has set itself? It looks like you've proved a lot of technologies with the Ponte Vecchio. What is the challenge that you said? There's many that I did not talk about. For instance, if you take a very simple exponential model of yield being an exponential function or yield loss being an exponential, if you increase the number of chips, the yield loss will go up dramatically beyond a point. You'll say, why am I doing this kind of, but then you look at entities like cars, they have way more number of constituent components and they still manage to build them with reason. So the first, not first, but one of the most important areas is how do you test, how effectively do you test and when do you test? I did not touch on any of this in there, but to me, being able to get known good entities and not completely known, but as well known as you can is a very, very big part of this equation. The second in my mind is the materials that go into the manufacturing, which you have to use them to build high yielding processes is another. The third, which would be an ideal goal is can you by design predict what you expect functional or thermomechanical reliability of a part to be before you build a part so that you can design your test chip. That is a fairly big challenge. Then performance and interaction. You know, I showed it in my graph, but I didn't really talk about it. If you take components and you put them on the same package and you try to cool them, they talk to each other in thermal crosstalk. How do you design it so that, then there's the core design for electrical, thermal and mechanical, the design tools which have a common language that talk with each other. All of those are areas where we have done well, but we can do better, is my general view. Great, thank you very much. All right, so let's open the questioning for the audience here. Who has a question? Thanks. Hi, great panel and great talk for that. I'd like to offer a counterpoint to the first question that was answered, which is the industry academia collaboration. Ravi, I thought you put it beautifully when you asked, you know, what will I need to get to the next node? And the counterpoint I'd like to offer is that you need a ton of super smart people, right? And those are the people, and that's what has enabled you to get from one node to the next node. And there was a lot of Zihong when you talked about technology transfer, you know. I've sort of found that the best way to transfer my technology to industry is to get my students in there so that they can do the transfer of essentially the thought process and the technologies that we have inculcated into the companies. So can you talk a little bit perhaps about that aspect of industry getting involved in the university, you know, training of advanced graduate students and sort of almost creating that pipeline to suck talent in? So speaking as an Intel person, we do quite a bit. We have Intel fellowships. We, at various degrees, engage with universities as liaisons, talk to students. We even had a requirement for our liaisons to make sure that we keep an eye on liaisons, figure out ways to do internships, facilitate that research. Now, like everything else that is well-intentioned, we do it in degree. You know, some people do it really well and some people. But we try very hard to do stuff of this nature. We also try as best as we can to talk to students as frequently as we can. I don't claim to be very good at it, but I do claim to put in a lot of effort in talking to different people in all of this. So I believe handshakes of this kind. And then there's practical things. You know, can you do internships? Can you figure out ways by which you facilitate that research by pointing them in the right direction? It's a matter of degree, not matter of desire in my mind. I confirm this part of the interaction. We have a new limit center sponsored by SRC and also other Intel projects. We have monthly reports and monthly discussions with Intel researchers. So the interaction is very intense, I would say. So I just want to offer an anecdote, right?  You know, think of yourself as the people with machetes going out and clearing the jungle and telling us where not to go. It's okay, you know, if you have a few snake bites along the way. But in the process, just make sure you train a few good students who can come and work for us. So, you know, you can imagine how I felt. But over the years, I've come to embrace the fact that a lot of value taught us, I think a lot, that the sponsors see is with the students and, you know, we try to get out of the way. Of course, we learn a lot from the students. I'll second what Ganesh said and it's a blast working with them. But I completely agree. I think that, you know, I've come to see that as a very, you know, primary way of actually doing technology. Just a quick follow-up thought and I'll stop.  But just to continue that for a second. You know, I do wanted to just, you know, give a quick call out to, I know that at the time when the jump centers were being formed, there was a very strong push that, look, you know, x number of students, 85 students or whatever it is, right? And that has to happen.  So thank you. But there's, I point to one more quick anecdote. You know, UCLA has a center called CHIPS, where Professor Subbu Ayer, who's an ex-IBM fellow, is building what he calls SIF, Silicon Integrity.  I tell you that breakfast was fantastic because they asked me all kinds of questions. They explored and oftentimes, I would think the reason I'm saying this is because this is how it has been done, as opposed to having a rational argument for why it is done. Or I would say it is more expensive to do it this way. And I realized halfway through the breakfast that just because things are done in a certain way doesn't mean that this sort of pool of thinking that has been generated, if I could harness the power of their thinking, I'd be a much richer individual. So I think that kind of discussion with fresher perspectives on the same problem always helps. So that's a very important point that we actually have to spend the time to have these deep discussions. And you can tell that Xi Hong is very excited, is committed to implementing this back into the line technology that Xi and her center have created. And we work with Intel and low melting point solders and we talk with them at least every two weeks. And so they're implementing them right now, but they may not get implemented in the end. So it's an interesting discussion here where they're competing technology, some things will work, some things won't. And we've just got to keep moving forward. Yeah, I agree. I mean, even if it doesn't, I like the machete analogy, not the snake bite analogy. Exactly. But if you clear some paths where you will not progress, at least you cleared those paths, you don't go there kind of deal. So that's wonderful. All right, we had at least two other questions. Hi, thank you for the talk. My question was actually about thermal management aspects. So as students, I am a PhD student and when we work about thermal management, we always think that it comes as an afterthought like after the system architecture has been designed and then we talk about thermal management. And it comes back to your point about core design that there's a lot of challenges that have to be addressed in electrical thermal and a mechanical core design aspect. So can you give us more idea about that as to how challenging it is and what can we do in that aspect? First thing, you should not believe when somebody says it's a afterthought. It's not an afterthought. When you do 3D stacks, for instance, it has to be intrinsically part of it. Occasionally, what would be different is the language people speak. For instance, all thermal engineers consider heat generation as a steady-state time invariant problem. Do you really think it is a steady-state time invariant? I don't believe so. It's a transient problem. So the first question we have to ask is, are we just solving for an envelope and then claiming that something breaks and then we say, oh, there is a thermal problem? But it would be much better if we found the common language that says, when I'm running a code of this nature, what is the different operating model on the dye that I really understand the power? Then if we ask ourselves, how much variation is there? Because each chip is not made the same. There is intrinsic variation. There is design variation. There is structural variation. How do we figure out what the variation is? How do we encompass it? We talk about things like thermal temperature measurements. You know, temperature measurements, actually, if you really think about it are not that easy. My view is that we have not yet, though we have done a lot better now than in the past, we have not yet found a common language to talk this out. And the modeling tools use different methods and metrics kind of. That part I think we could do better, but I do not believe that thermals is an afterthought, at least for people like me. And not just me. I was here in 2004 when we were trying to do a thermal co-design ERC. Even at that point, it was evident that co-design was intrinsic. It cannot be ignored. So it's not an afterthought. Thank you. Wonderful. Professor Shukuri? Question. You know, one of the issues is always IP and how sensitive is in the short term. Could you give examples of, good advances have happened through industry working together. I don't know example from IMEC, from Albany. What will be some cases you say, this is a good case. We could work and we solve actually an important problem together. You know, that used to bother me quite a bit. Till we came to today, look at when we sign a standard SRA for university research. As speaking as an Intel employee, if the IP belongs to you and is background, I don't want to quote unquote, take it without paying for it. If IP is developed during the process, if we have a common handshake in the beginning, and then we work it out, I don't think IP should be a factor in all of this. In fact, I have, now it's, I have believed that if we negotiate this and do it right up front, we would not have to and should not worry about IP. That said, what are good examples? I don't have great examples to quote you, where intrinsic IP for my university has been transferred to industry in packaging. Though I do know that there are fields like computer science algorithms or different points where IP has been a factor. And I know there are material science inventions which have come from universities which have been a sore spot. But I don't know in packaging where IP, and I'll give you a positive example of IP. I was telling Carol in a conversation, Nick Chawla, Professor Nick Chawla had suggested that if you put minuscule amounts of rare earth elements in a solder, you change the shock resistance of this. And he had done all the intrinsic work with it. We worked out the IP deals with ASU really, really well. And we even got to a point where we took those configurations to send you metals and started developing manufacturable solutions out of these. So they have been good examples where we have worked this out reasonably well. Now I'm speaking from a very narrow perspective because I have focused myself on thermals and there's a much broader conversation to be had. But from my perspective, I think IP can be resolved. Additional questions? Ravi, so this is a question to you as the heterogeneous integration roadmap author. You talked about high performance computing. There's a proud tradition of space here, other things. Can you talk about some of the challenges in automotive power electronics or aerospace, please? Yeah, let me start the other way around, Todd, because if in aerospace we include space beyond aerospace, kind of the broad one, then there's quite a few very, very interesting questions. First, the level of reliability they expect is different and in a number of ways, quite a bit more challenging. One approach to doing this is to take commercial solutions and extend them up. It is possible that we haven't found it. There may be points where the technology envelope breaks and we may have to figure out ways to introduce new materials to solve specific problems. For instance, if you have to have a part that is say radiation hardened and you may not be able to, I don't know if that really exists, but if it happens that commercial solutions are not truly radiation hardened or there are other non-technical issues, what could we do? So that is one thing. Secondly, the size-weight, the swap challenges could be quite significant, especially, I think I was talking to Professor Grohl last night about how size matters and weight matters because it matters to payload. That could be a factor that we don't pay a lot of attention to in commercial electronics all the time, so that could be another challenge. Medical is always environments that you work in are very different than the environments it work in and safety, reliability, all those kind of, so I have a feeling that we ought to, we do the normal things quite well, take today's stuff and extrapolate it to the best as we can. I don't think we have done as good a job of taking those environments by themselves and extracting out a new class and then how to develop it. There is a lot of work needed there in my mind. Additional questions? Hello, thank you for sharing with us your wonderful backgrounds and on that note, given that you all had a transition, so to say, from academia to the industry and for some of you all back to the academia. As a PhD student, I guess my question is, we spent close to three to four years identifying a key critical research topic and getting into the depths of it, getting into the weeds of it and now, when we are looking forward to getting back to the industry and contributing, my question is, what is the scientific thought process that you're looking for in us? Especially given that we have a mindset of getting into the depth of a problem, but when we get into the industry, the expectation is a very fast, quick turnaround. So my question is in your thought process, what is the strategy that we should be looking forward to? If you carry a very simple mental model that says if it is not done in time, it carries no value, I think you will succeed very well. And I was at NIST for 21 years, so I was one of the leads in advanced packaging at NIST besides being chief of metallurgy. So one of the things that I learned early on was I came there as a postdoc and then I'd done my PhD in four years. Well, I had to do basically another PhD in a year and a half. And then I had to do another PhD every year plus mentor other people there and work with them in teams. So we're creating two PhD theses a year as a team. So I don't think it matters where you are.  Whereas in industry, we get, and in national labs, you propose the work and you get funded, but it's typically internal.  I'll just add a quote from a colleague, from a former colleague who's no very distinguished, he's the president of ASC Group, which is the largest packaging group. He was my colleague at IBM and I was discussing with him another fracture mechanics friend. So he said, if you give me, and he and I were discussing one day how we dealt with his customers, we had internal customers within IBM. So I asked him how he dealt with it.  If you give me one week, I'll give you a $10 solution. If you give me a year, I'll give you a $1 million solution. So I think the trick for many of us, the challenge for many of us is learning to develop this $1 solution. So not always look for a million dollar solution. And he was far more successful than I was. Thank you. Other questions? Well, I thank you all very much for participating and I'd like to thank the panel members for a really enlightening discussion. Thank you. Thank you. Thank you everyone.


Hey, everyone. Today I want to talk to you about Kubernetes, the community, and long-term support. But first, let's talk about how AI tools are making it easier to deal with complexity. Like this OpenAI QPCTL plugin that my co-worker Sirtash made. Large language models are helping us create new things we can create YAML to deploy applications. For example, we could say, QPCTL AI, create an engine X deployment with two replicas, and then we get the YAML. These tools are going to make all of our operational headaches go away. Cluster upgrades are going to be super easy, right? Let's use that plugin again and try to upgrade a cluster. Oh, well, that's kind of a bummer. Upgrading is a complicated process, and we can't just generate some YAML to do it. OK, so then how do we upgrade? Well, OpenAI says we should consult the Kubernetes docs. Shout out to SIG docs. The docs are pretty good. But I'm not ready to give up on AI assistance just yet. So let's ask Bing how we upgrade a cluster. OK, so there's some steps there. It seems like a lot, but I think it's pretty straightforward. We should be able to apply these to all of our clusters across our whole fleet and upgrade things, edit some YAMLs, and we'll be good to go, right? We'll do this pretty quickly. But the reality is that even in 2023, cluster upgrades can be pretty complicated and time consuming. And operational concerns, like maybe you're running bare metal servers and can't get new capacity, or you're in regulated environments that maybe have lockdowns or tight windows when you can do things, might make it difficult to upgrade each version, and suddenly you're upgrading it across four versions or more. Sadly, this isn't really a new problem. So let's take a trip back to 2018. Kubernetes 1.12 is just released. It's the very first release I got to work on. It seems like so long ago. And there's a discussion in the community about the frequency of releases. Are we doing it too quickly, too slowly? Maybe we should do more. How long should things be supported for? What about LTS? From those discussions comes a proposal to start up a new working group inside of Kubernetes called the Long Term Support Working Group. There were a lot of questions to answer, and a lot of people were involved. And over the next two years, a lot of data was gathered, a lot of discussions happened. And at the end of 2020, a new Kubernetes enhancement proposal, or a CEP, was submitted to change the support period from nine months to a year to better align with business cadences. Getting this kind of change approved involves a lot of work. So if you've ever done a CEP, let's give a shout out to these folks, because it takes a lot to do things across SIGs like that. Once this was complete, Working Group LTS had really run its course and was sunset. But change kept happening. A lot of work was done over those intervening years. And we've gone from having four releases a year to three. We've gone from having beta APIs by default to only having stable APIs by default. We also have production readiness reviews now that make things more stable. However, the question remains, is it easier to do upgrades and stay current on things? Seems like maybe there's more work to do. We hear from customers all the time that it is still hard to keep current on things. And it's a theme we see in community surveys as well. The production readiness team does a survey every year to kind of understand how that process is working for making clusters more operational. And this is the survey data from the most recent one done in May of 2023. And we can see that a large portion of people are still running unsupported clusters. So it seems like that's still a challenge. Where do we stand with LTS? Can that solve the problem for us? Let's ask Bing again. Bing is going to help us out. OK, so we see Kubernetes as a project still does not have LTS. But we see vendors are starting to bring that support forward. Oh, but Bing thinks we're going to have 128. We're super excited to have 127 in AKS. But we're not planning to do 128. But it brings up a great question. Which version should be LTS? Which versions? Can we align on that? And we wanted to discuss this with the community. So at the Contributor Summit in Amsterdam, we met with end users, vendors, and a number of other people to have a lively discussion about what blocker still exists. Can the project even afford this? There was an instant agreement that we should do LTS, but we agreed to restart the working group. And at the Contributor Summit, we came with a plan. And we have a new working group that's been founded, being led by individuals from Google, AWS, and Microsoft. Many other folks that were in the working group before, but most importantly, you. We started meeting in August, and we are on a path to determine if LTS is right for the project. But to get where we're going, we're going to need your help. You could help us today by answering our survey about friction of doing Kubernetes upgrades. We're going to collect a lot of that data to help us determine what path we need to take. If you'd like to talk more about this, you can talk to us at our maintainer track session tomorrow. And we'd love to talk to you more about Kubernetes, Cloud Native, and all things at the Azure booth. Thanks.


because now, you know, now this is six years ago that I heal myself and we have so many success stories and I hear them every day, people texting me different stories. We just had somebody who had cancer and he was on his, you can even say his death bed. He couldn't, he didn't even have the energy to walk 10 feet. He went from 200 pounds, 220 pounds down to 150 pounds. So you can imagine how skinny he was. He was a tall guy, he's like six feet. I'm 150 pounds. And okay, so now he had the cheek hole and then after a couple of weeks, he got out of the bed and he walked a mile. And now he's back to work. Now he's back to work. Here's a video of him telling a story on my website and on my social media. He went from being bedridden, couldn't walk 10 feet. He had to be on a walker. This is a, you know, 40 year old strong, he looked like a football player. He's a pretty big guy, muscular, right? And he lost all of that. But now he gained it back. He's back to 200 pounds, right? After three months. And he back to work. He's functioning normally. He doesn't need help from anybody.  So that's pretty incredible. What kind of cancer did he have? Lymphoma or something. Aggressive lymphoma. That's what you said. How? Yeah. How? And I just got news of another friend of mine. She's a realtor. She has cancer as well. And then she's been using my coil for the last four months. She just got her oncology report and the cancer went down 50%. She's so happy. It's crazy. I had an incredible how? Yeah. So we're doing some incredible things. But I'm not the person. I mean, my goal is to make a system that is easy to use and somebody can just flip a switch, press the button and then they can start using it.