 So, this is a joint work with Giorgio Urcaleri, who is an assistant professor at University of Lorraine. So, it's in France. Ben Mosley in CMU, I know where that is, everybody, Kim Thang, who is my host, I'm a host doc at every, and he's my host. He's also in, it's in France, and in Interestum. So, I've been looking for non-preemptive scheduling for a long time almost, and this is one of the latest result that we have come up with in a series of that work that we have been doing. So, start with the problem definition, which is brief, straightforward, very simple. So, you have M-related machines. Related machines means that you have speed for each machine. So, machine I here has speed SI. So, the faster the speed, the faster you execute the job or reprocess the job. And you have sets of jobs. So, the job has different characteristics. So, one is the processing requirement, it's noted by PJ. That means it takes that amount of time to execute on a machine where the speed is unit. If it is, the speed is twice, it says PJ over two. You have a release date, which means that job arrives at RJ. That means job is ready for execution only after RJ. So, before RJ, it's not available for execution. And you have weights, which is, gives the job important ways. So, the higher the weight, the higher the job is important for you. And the goal here is to design a non-preemptive schedule. So, the non-preemptive schedule would mean that you start at particular time and execute the job until it's completion. You can't, you know, stop in between, do context switch and then come back to it or resume it. It's not allowed. And the objective is you're trying to minimize the maximum weighted flow time. So, the maximum weighted flow time is basically the response time, how long the job remains in the system. So, assume that you have designed some kind of algorithm, which schedules the job at some point. And it's completion time when the execution completes the CJ. So, CJ minus RJ is basically the quantity the job remains in your system. So, this includes two things. It has weighting time and it has processing time. And you're trying to minimize the maximum, so it's L infinity norm, that's all. So, there's a one on L1 norm that we have done before and in general LP norm. And then specifically on this L infinity norm, because we can improve the results from using some techniques from previous works. OK. So, this is the problem. So, what's the model that we are looking into? So, one is that job arrives online. So, you don't know about the job's characteristics before it arrives. So, what is the RJ? What is the processing time and what is its weight? Nothing. So, you know when it arrives only. And we're looking at worst case, basically. And when the job arrives, you know it's processing time and its weight. So, this is called in scheduling as Clare-O-Ant. So, there's a non-Clare-O-Ant model where you don't know the processing time. So, you execute the job until it gets complete and then you know what the processing time was. But here we assume that we know the processing time. So, what we are going to look is something called as competitive ratio, just to increase everybody's not from online algorithms. So, here the objective value that you're trying to minimize with respect to the offline optimal. So, the offline optimal actually knows the instance beforehand. It knows what jobs are going to arrive, when it is going to arrive. It has all those properties beforehand and it decides the schedule, whereas you are trying to do online scheduling. So, you don't know anything about future. So, there's a huge, you can say, lack between what the optimal will look like. It has a lot of more power in some sense compared to you. So, given this, we are trying to find this ratio and trying to minimize it. So, what is known is that if your weights are equal or one, that is a vitically unweighted case, in that you can have simple first-come, first-serve and you can get a three-approximation, a three competitive ratio. Then there was a result which gives 13.5, which was later improved to 12.5, on a related set of machines. So, identical set of machine, it takes pj amount of time on each machine. It takes pj on machine with, so all the machines have same speed, basically. It's just a parallel set of machines that you're trying to execute. So, as I remember, this algorithm is basically for a preemptive algorithm. So, it's not non-preemptive. And when you have weights, it has been shown that there is a strong lower bound. So, the question is, what to do now? It has also been shown that a lot of work that people do in practical that they have shown, there are a lot of heuristics which work good. So, there should be somewhere that you should be able to say that certain algorithms are good and certain algorithms are bad. So, in this domain, something is used as a resource augmentation, which is pretty common. So, resource augmentation is that algorithms are allowed to use a little bit of extra resources. And so, you can think about you have having, so the first one is you have having a higher speed. So, basically, you can think about in each time unit, you're trying to execute one plus epsilon. So, it was, let's say, speed was one. Then, in one time unit, you execute one time unit of a job. But with higher speed, you will execute one plus epsilon unit of a job. So, just epsilon higher. And there's also, similarly, more number of machines. So, maybe, optimal algorithm has M machines. And you have M times one plus epsilon, a slightly higher number of machines. And it's very old work. But I can't tell you a number of papers that have come up on this area, at least 100 papers on this alone, how much you can use this kind of model to actually give different algorithms and show that they are good in this certain models. And in 2015, Chaudhary et al. they proposed a model. So, in this model, they said that you can actually reject certain number of jobs. So, instead of executing all the jobs, let's say in instance I, you take I into one minus epsilon. So, you don't execute or don't compute your object value on the epsilon factor of the jobs, but rest of them you compute. It's a kind of resource augmentation where you can think that you have certain number of more machines which can take these epsilon jobs and run them separately without worrying about the objective going very bad. And in this sense, now, the competitive ratios definition is redefined. So, now, you have algorithm solution using resource augmentation, whereas the optimal is not using resource augmentation. So, I'm going to talk about rejection mostly. Think about you are rejecting jobs, but your algorithm has to execute all the jobs. So, basically now, even though it knows entire instance beforehand, you have kind of taken certain, you know, power from it, in certain sense. Or you have given more power to your absorbance, some of your fairness. I said this is a lot of work has been done. So, some of the work which is currently, which is practically related to the problem that I'm talking about is, it's known as speed augmentation model. So, the first one is, talks about actually weighted problem, and it shows that, OK, if you get epsilon c, you can get a constant competitive ratio. And similarly, so there are multiple individuals, but all of them, as I remember, these are all in the settings where either you have weights equals to 1, or they are preemptive in nature. And the rejection paper that came itself proposed a competitive ratio, but they have done it on a preemptive problem, not on a non-preemptive problem. So, non-preemptible are much harder than preemptive. So, what do we show is that you can get a constant competitive ratio if you reject epsilon fractions of job. Basically, this theorem says, it's not exactly the statement of theorem, but it says that you can get a constant approximation, a constant competitive ratio if you don't execute epsilon fractions of job. So, first I'll try to talk about how the idea comes up, what is the intuition behind it, and then try to give, you know, something about the algorithm, but not the entire proof. So, nowhere you will find a lot of maths, at least from my perspective, it's not a lot of maths. So, assume all weights are 1, very simple problem. And you have a single machine, not multiple machines. So, what you know is that the maximum processing time is W, F, sorry. So, you're assuming that F is what the optimal looks like, the optimal quantity that you're trying to optimize. So, what you can do is, you can take a very large interval, a very huge interval, and think about all the jobs which are released during this interval. So, what happens? There are a lot number of jobs, because there are a lot number of, the interval is quite huge, and you're trying to pack all the jobs within this interval. So, all the jobs which are released in this interval, you pack them there itself. You really don't care about the jobs which are released here or here. And the idea is that, since you have a lot number of jobs, maybe you can reject one of the jobs, a certain number of jobs, and fit all the jobs within that interval. So, if you can do that, then you can take each interval separately, and schedule it independently kind of thing. So, the argument is that, if there is no space to schedule, that means there are at least one over epsilon jobs, because the maximum processing time is there, so you can just figure it out from there. So, huge number of jobs you have. You can reject this job. It's not really, you're rejecting very small fraction. But the assumption is that, here, is that, if the job is released here, you schedule it in the interval. If a job is released, let's say, at this point, red job, then also you schedule it before the time. So, this is not exactly trying to follow the release dates. So, how did you do that? It's pretty straightforward. You make an offline schedule, where you try to fit every job that is released during this interval, and then schedule it in the next interval. So, something along this line. You're actually delaying it only two times. So, first you collect the job in one interval, and then you schedule it in the next interval. That's the basic idea behind it. So, now, this is on a single machine. This is with just a single weight. So, the point is, how do we go from, to the multiple weights, and multiple machines? What do we do? So, this is just an idea. We classify jobs into multiple classes, according to weights. So, we say, OK, the weights are basically from one to two, around the time, and that's basically with each class. We're going to reject in each class some jobs to create the space, and then we're going to start designing an offline schedule, which is basically from max weight to main weight. So, first, we give priority to scheduling higher weight of jobs, because their objective value is higher. They have high weights. And then, use offline this assignment to figure out, in online, where to exactly schedule the job. And then, again, we'll do some more rejections, because they will be overlapped because of different weights. They will be overlapped in intervals. To compensate, you have to reject, again, certain number of jobs. And then, you're going to schedule the remaining jobs non-prematively. So, OK, I'll detail out at least some part of it, not the proof. So, again, the objective that you're trying to minimize is max this quantity. You have sets of machine. So, what you do is you index your machine according to their speed. So, S1 has a higher speed, where SM has a lower speed here. Assume that F is optimal. So, understand that the problem is online. So, even if you assume F is optimal, it's not sure that you can derive an algorithm, which can actually schedule it, because you don't know the future jobs. So, the only assumption is that you know optimal. And at some point, we will figure out how to remove that knowledge on F anyway. So, assume that you know the objective value F. Can you design a schedule? Now, the problem becomes like this. So, what we say that, OK, J is valid on some machine, where this objective is less than F. What it means exactly, if we pick the J and schedule on that machine, can the job be scheduled on that particular machine or not? So, if you look at the valid set of machines for a particular job, then optimal will also schedule the job on one of these machines. And so, now what we do, as I said, we are going to use rounding. So, we round the weights of each job to the form of 1 over epsilon to the k. So, we round down the jobs, basically. So, J belongs to class k, if its weight is between 1 over epsilon to the k, 1 over epsilon to the k plus 1. So, this will lose a factor of 1 over epsilon in the final final result. So, now what you do is, in a single machine case, for whenever weights were 1, we were trying to create intervals. So, now we are trying to create intervals for different weight classes. So, assume that you have a weight class this. So, basically, the job will have a weight 1 over epsilon to the k. And for this, you have different intervals. So, the idea would be that if a job is released in this interval, it will be scheduled somehow, to make some algorithm in that interval. Similarly, for this particular weight, which is smaller, and so on and so forth. What is also interesting is that these weight classes are nested. So, in this particular example, you can see that the interval size is f to the epsilon to the k over epsilon cube. So, you can think about this epsilon cube as epsilon to the c, any large value. The cube is there just because it fits in our example. But you can think about large, huge size of an interval. So, what does it say? If you look at it, so the maximum processing time of a job is basically f times epsilon to the k. This is the optimal quantity. It's w times pj. So, w is 1 over epsilon to the k. So, pj is going to be at most this quantity. This means if you have an interval of that size, they are going to be at least 1 over epsilon to the cube jobs, which can be scheduled in that interval particularly. And then we say that j belongs to certain type k l, when j is of type class k. So, it basically weights some weight. It is released in this interval. So, exactly if a job is released in this interval, we say that it belongs to this class k, which is basically depends on its weight, and at what time it is released. So, again, so what we do is we reject. As I said, we are going to reject small fractions of jobs and we execute everybody else. So, the idea is that, assume that j k l here denotes all the sets of jobs, a lot of type k l. And again, what does it mean of being a type k l? That means w j is in this form, and its release time is somewhere in this interval. Take all these jobs. Sort them in the descending order of the processing time. Once you have that, you reject first epsilon square fractions of jobs. So, the argument is that, since you are rejecting epsilon square heaviest, largest volume jobs, you are having, you are rejecting at least epsilon square by volume. So, you are creating that much of space. And since the weights are rounded, you are rejecting at most other epsilon total weights of jobs. So, weights are rounded down. So, you might have more rejections of, because of you are rejecting higher weights maybe. But still it is ok, because we are rejecting order of epsilon. Now, it might be that you do not have that many of jobs to reject in the first place. And this part is basically to ensure that actually you are rejecting something. Otherwise, you can have at every level 1 over epsilon minus 1 jobs, and you never reject any job. So, to ensure that you are actually rejecting some jobs, and you are creating space which we need in the argument, you make sure that if you happen to have one level higher, you reject one job for every 1 over epsilon jobs. And for every job that is 2 levels higher, you reject at least one job. Because when you take the weights, this is 1 over order of epsilon weights rejection. And this is again order of epsilon weight rejection, even less than that. So, it might look like that for the same job, we are rejecting at multiple level many jobs. But since they are rounded, when you sum it up, it's become a geometric, and it's at most 2 times the epsilon. So, what we can show is that your algorithm rejects at most all the epsilon fraction of total volume of job. So, we have created for an interval epsilon square volume of rejection. So, we have shown, OK, that you have rejected epsilon square of jobs for each interval somehow. And the argument, I am not sure to prove, but proof is based on, so you can make a KRA tree, talk about rejected jobs and the leaves. And you try to associate the rejected jobs with the leaf, and then argue that if you have that many of rejections at leaf itself, then you can talk about higher levels, because every time you give a higher level, you will reject that jobs anyway. So, it's OK. The proof is technical, but it's almost pretty straightforward. So, when we have done rejection, we have to schedule the jobs. So now, we have set of non-rejected jobs. And we have to schedule them. The schedule is simple. You take the J, non-rejected job, find out the sets of machine where it is scheduled. You already have this set with you. And you start from the slowest machine, and you go to the fastest machine. So you first try to fix on the slowest machine. And if you cannot, you're second slowest, third slowest, and to the fastest machine. So basically, again, the same thing is like you schedule each non-rejected job on machines where you have these free slots. So this will create a preemptive schedule, but we really don't care. Because this is an offline schedule. When we will convert to the real schedule, that's where we need to be non-preemptive. So here, just the volume argument is enough. So what can we show is that, OK, this will output a preemptive schedule that ensures that if a job is released in IKL, it is scheduled in IKL, within the IKL. And the proof is basically a volume argument. We have shown that we have rejected epsilon squared of jobs. If you're not able to schedule a job, that means the whole interval is busy. So basically, you have these many volumes of job. But Optimal has at most this amount of jobs. So this is the counter argument that somehow it doesn't fit into your thing. And you can show that, OK, J has enough space anyway. So now the question is how to convert it to offline, to online. So there is a problem of different weights. So figure out that, OK, assume that in offline case, the job was actually scheduled here. But in online case, you will schedule the job after this interval, when the interval actually ends. Similarly, when you have completed the offline case, you have completed using all these jobs. But when you're actually scheduling, you're actually scheduling it later. So there are jobs which don't fit together. Because there are certain jobs which are released here, and they might be scheduled here. This is not how you decided to schedule the jobs prior. So fitting might be a problem. But you can do the same trick here. Think about taking a large number of intervals itself, and then delete one of the complete intervals, epsilon fractions of jobs within that interval, create a space. So I'm not going to detail because it's the same thing that we have shown before. It's just same volume argument will go there also. You just reject more jobs, that's all. As I said, it basically delays the job by this quantity. So now you can take one over epsilon, one over epsilon cube, whatever, number of intervals, and delete all the jobs in one of these intervals that are released. So you have enough space to schedule the rest of the jobs. And you can show that all non-rejected jobs are scheduled in basically, for class case, scheduled basically in this size of interval. I think it's 2C, should be. So now the question is that when we are actually trying to schedule the job, our algorithm is you always pick the job with the highest weight class, and you schedule it, and then you go to the lower weight classes. It might be that these algorithms are non-primitive because you're scheduling a job, which is of lower weight at a particular point time interval, and there's a higher weight job available. So in that case, you can just reject the job. So what do you mean by that? If a job is running, a large job is running, so let's say that job j is running on some machine i, and one over epsilon jobs arrive of class k or k plus 1 or k. So you can reject the job. Yeah. You can reject, it should be one over epsilon square basically, but OK. You can reject the job j because you're rejecting one job over one over epsilon again, so it's epsilon factor. It's just a fitting argument. And what you show that for rest of the jobs, you can schedule it in f over 2 to the epsilon to the c. c is some constant, which is 3, I think, in our algorithm. So now the whole algorithm becomes non-primitive. Another question is that we assume that we know the f. So there's a standard technique in online algorithms when you're trying to remove the knowledge on f. It's usually a doubling trick. So start with the trivial assumption that f equals to 1. And every time you have to reject more than epsilon jobs, the proof has shown that if your assumption was right, you should have scheduled that many of jobs. So assumption was not there, you double it up. That means the optimal is also doubling up in a certain case. It's not, yeah, it is at most two factor away from you. And finally we can show that with all these tricks that you can get some constant factor approximation where f is the optimal solution. So you get 1 over epsilon to the 9. So yeah, so the concluding remarks, we've shown powers of rejection in a certain sense that prior to all these works, rejections were pretty focused on trying to handle cases where you have preemptions. But we've shown, OK, for non-preemptive we can get some good results, at least interesting. It has a scalability in the sense that it's not exactly what you mean. But scalability means you can reject more jobs and get closer to the optimal in a certain sense. Think like something like betas. You can have more time to run. So there are two open problems. So one is that we don't make immediate decisions. We let the job run. And then we reject at a certain point the job. The question is, can we make certain immediate decisions? And the second is, can we solve the problem on unrelated machines? So this work was actually, we were trying to solve this problem, which we were not able to solve, instead we solved this. So this problem is much harder, I think, because even in the preemptive, I think there is no results, which we often leverage to talk about in non-preemption also. So can you minimize unrelated machines? Unrelated machine basically means that for each machine, you have different processing time. So when the job arrives, you get a vector. And the pij, instead of pj, it becomes pij. So for each machine, you have different processing time. And they are unrelated. So maybe one job is faster on one machine, another job may be slower on that machine. So there is no relation whatsoever. So that's all. Thank you. So what was your design when you considered an N1 norm? Like here, you're considering N1, right? Yeah, N1 norm, you have 1 over epsilon to the cube. So you reject epsilon fractions of j, and you can get 1 over epsilon to the cube. Yeah, 1 over epsilon to the cube. You can tighten all these things, but it doesn't matter. Thanks.