DASH Behavioral Model WG, 5 May 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: DASH Behavioral Model WG weekly 20220505 (May 5, 2022)

Description

May 5, 2022 Behavioral Model WG Call
Demo by Marian

A

Will be used everywhere where flow is relevant.

B

Okay same same logic is what I'm guessing yes,.

A

Okay, I understood.

B

Thank you. I understood, and I have an unrelated question on the exception table for fragments and table entry creation, but I can hold on.

C

So, hey andy and just as you made a comment about this flag to say that you know should, should we not have some variable, which basically says how many bits are valid, as opposed to saying that, okay, whether it's v4 or v6,.

D

So I I didn't, if you're wondering, for example, in the flow tracking table, that if you have 120 bit source, address 120 bit dust address and it might be a v4 v6 address and if it's an exact match field with the kit is for the flow tracking table. Then yeah. You need either to say: okay, we're actually going to do lpm or ternary on that or we're going to say that the p4 program has to initialize the least.

D

You know like the 96 n bits used for v4 address to a known value like all zeros, so you can do exact match.

D

This is nitpicky level details that I'm talking about here, but if that's what you're asking about, then that's what I would that's one possibility.

C

Yeah I mean, although my use case was only in the lpm. Let's start with right, so you know, irrespective of that right, when we are basically constructing the key. Do we not need to really say that how many bits are valid.

D

For when you install prefixes yeah, you have to say what the prefix length is and it better not be longer than 32 for a v4 address.

C

Exactly perfect.

D

So don't do that: okay, thanks honey, but for exact match fields. There is this issue that you'll need to like we'll probably want to say zero out all the 96 bits that don't matter for v4 addressed.

C

E

But here we are talking about the vm lookup, not the connection tracking right, not the flow they go and.

C

Yeah for the yes for this routing scenario, for the ipv6 routing, uh outbound routing. Yes, it's lpm, not the connection. This is not the connection.

F

So can we consider this kind of closed and talked about and agreed.

C

Yes, for that comment, yes, you can. You can say that you can move on from here and then you can.

F

Move on from here, okay, great everyone's nodding, their heads. No, I can't see that um and someone else said they had something they wanted to bring up. um Was it then cut or.

B

Yeah maybe question for andy yeah, the before expert.

D

B

And then uh for the connection tracking, no sorry for the fragments right, uh the existing design existing you know, write up somewhere in in the documentation, says we'll be creating another table and we'll create entries and use that table as a way to make sure that the fragments all add up to right. That's that seems to be the design.

B

That means that one table might create a trigger entry creation in another table.

B

Or do you see it as you just you know, you have two separate tables both of them generate their outputs and you have extra logic on top later, so I'm contrasting between the p force match action tables versus a generic field in field out lookup tables, and later you could combine the output of two tables into a into some logic.

D

I I may be, I want to make sure I'm interpreting your question right. Are you asking what's a good way in p4 to represent the idea for how to imp how to do fragment handling.

B

um Okay, let me rephrase that that's like I just do my job, but so let me rephrase so today we don't have one table triggering a table entry creation in another table in p4 not today, so that means uh that you could have a regular connection tracking table and there could be another fragment tracking table. Yes, that could be. I I like that idea. That seems that seems workable to me to have a separate fragment tracking table yeah.

B

So that means I have a little bit of virus in my head right on how npl designs, uh where there are uh there's a lookup tables where there are no actions, it's more of a field in field out and then a disaggregated action that you could do it little later: separation of tables and logic right and uh whereas, if you just do the logic in the table, it has its own things and you don't want to go into the site track.

B

But I'm thinking if I have to go with p4 and implement two tables so first connection tracking table produces some results and the second fragment tracking table produces another result. And I look at both the results together in another separate logic and do what needs to happen.

D

So I mean- and here here's here's a thought that I have that I I don't know if this fits in with the whole dash data plane model, but imagine that you had a p4 table. That was the fragment tracking one. First and its whole job was to be add-on. Miss for the first fragment and the later fragments tell you that the l4 ports were over the first fragment and then now those l4 ports are carried down the connection tracking table and you look at there with the ports.

B

And then there are interconnections right with we, we said: if the flow ends, then you need to take the statistics added to the other table and there are complications there. That's why? Okay, so.

D

This I'm sorry I'm I was unaware of those complications and and the idea I've just presented may or may not be able to work for that. So.

B

I can, I can explain right so if you have, if you have a connection and then in between one of the packet got fragmented into four fragments and those four fragments are tracked in another fragment table and the statistics are there and they need to somehow come in and update the flow table later right and so sorry.

B

So when the connection when the fragment flow, if you allow me to phrase it that way, when the fragment flow ends, we need to connect that to the uh the flow table that the connection table. That comes later.

B

G

B

Can expand on my we need to look at, uh I mean I'm just thinking. Do we need to look at uh one table enabling entry creation in another table or not so, uh and then what is the current.

D

So so so let me, let me explain if there were a connection, a fragment tracking table. First, that just you know you add, on miss on the first fragment and then you later fragments just pick up what the l4 ports are you're still going to later, do the connection tracking table lookup and you can do full statistics on every fragment, live as the fragments arriving without waiting to combine the results later.

D

I think right, there's no reason to combine statistics from two tables ever they're, always in the flow tracking table, then uh the flow tracking table. If you update the flow tracking table, live on every fragment with the packet and by counts you want, then it's done no need to combine it from somewhere else later.

B

The the connect the fragment table passes those additional ports so that the connection table has the ports right, because the track connection.

D

Is already knows the ports, because the fragment you've already resolved it before you get to the connection tracking table.

B

D

B

D

I don't know if that answers all the questions, but I was trying to.

B

See do we need to go back, I mean I was just trying to evaluate. Is there a need for one table? Yeah yeah? I think I got enough answers to work on it. I don't mean to dump all my work for the design part. Okay,.

D

Understood yeah, thank you sure, yeah happy to brainstorm more offline. If you want yeah, definitely I always go for solutions that require less general capabilities in the language and libraries when possible.

B

Yeah so yeah I was trying to kind of maybe combine too many things in my head. One was when the same flow is tracked by multiple people like in shortcut switches, the routing and ha and the switching or the the cache in front track the flow separately, and we used to combine them with netflow data export version 7, and so I was kind of over engineering and trying to see do I have to do that. That was one second is.

B

I think I might be overlaying too much of my npl and npl way of designing things trying to see. Please ask the good ideas. Might.

D

Come out of it.

F

Right now, does it sound like we're pretty much waiting on connection tracking then for a couple of the other work items? Is that our dependency number 11 in here.

A

F

I hear a funny noise, okay, yep.

H

Connection rate limiting feature that depend on connection tracking implementation.

F

So should we focus on getting this piece done? First, then, since we have dependencies.

A

I don't think it's this piece, it's even one before that connection tracking in the simulator number 14, which will happen in like two weeks.

F

Okey-Dokey mention- and I did have a date written down for that- didn't I I have may 5th. um Should we bump that date out marian.

A

Yes, so this week we will have num the one that is after that number 15 right. Is it.

F

Translation runtime.

A

Yeah number 15 is this week and uh connection tracking and simulator is two weeks from now. Okay,.

H

uh Actually, I have a couple of questions uh regarding to the connection limiting part I have put in the issues uh where we uh we noted down like like.

F

Do you have a github id that I can add.

H

My github keshu gupta one is my github id.

F

H

F

Thank you, oh here it is got it.

H

So go ahead, go ahead with you yeah, so my uh so uh this connection rate, limiting is what we discussed. Last time like we can implement by whenever there is a miss in the connection tracking table, then we do implement by metering. So there were question last time whether metering uh is okay for the rate limiting part.

H

That was the first thing uh so uh andy. uh It was question to nd like uh whether a meeting is okay for this kind of scenario, and uh one more thing I have a question is like: when two packets comes for the same flow uh and when the and then the flow doesn't exist in the connection taking table so for in that case, the first packet will be always miss and the second will be like hit, or that could be case like for both could be a miss.

H

Then I think uh here, connection will meeting will will behave differently. Then.

D

Yeah, I think mario mentioned some ideas, some questions on that metering idea earlier and you're right. It might not account correctly for some of these cases and I don't have.

D

Unless that can be solved, some some way, which I don't have a solution for that it does sound like we might want some kind of thing built into the add-on miss table to do rate limiting inside of it. Somehow.

D

But unless somebody else has thought of a solution that avoids the correct account, I think remember quickly, mauro, you said: if you do a meter, then yeah. If we do a meter before they add on this table, to tend to prevent the atom it's going to be counting packets differently than yeah. I forgot the details, but it was. It sounded like something that basically, they need to be tied together. If you want accurate rate limiting that's my recollection, yeah.

G

I forgot basically, you need to count the mises, not the buckets in general.

D

You only want to update the token counts if you actually added an entry successfully.

G

Exactly not not even just the basis the the adding of the entry.

D

Night- and I didn't um I mean you- could imagine increasing the feedback loop a little bit by saying. Do the atomist first.

H

First thing like it can be do like. If I don't miss, we have a miss, then we go and implement indirect metering in this case.

H

Then, with indirect metering, we'll go to the metering index and increase.

G

But in a way you also want to when you know that you want to add the table.

D

I mean the overall goal of the just just to the functional requirements or desire is for eni. We want to specify some like rate limit, like a million per second or 500 000 ads per second kind of thing. Roughly, yes,.

A

Yes, functional.

D

Replacement is.

A

How many connections per second we are, this eni is allowed to.

D

Right open, it doesn't need to be hyper precise, like 500, 000, plus or minus one. It could be 5000 plus or minus a percent or something like that. But you know that's what any implementation is actually going to give you, but we probably don't want to be 5000 plus or minus 50. That's way too far off.

A

Yes, yes, usually it's plus some deviation.

D

Yeah yeah, but we want a few percent maximum deviation from the.

A

But in behavioral model I think it should be if we really want to express that it could be quite uh literal, like plus or minus one.

D

Yeah, sorry, I haven't thought about it much since last time and I don't have an answer.

D

I, if there's an answer using meters, I haven't come up with one and nor have I proved it can't be done, but I don't know a way to do it yet.

F

Okay, so do you think is: is this question answered to your satisfaction? uh Is it vincat.

H

F

Yes, chev, I'm sorry yeah.

H

So I find this meter right now, I'm not! We are not sure if we can go by meter andy to do the rate.

D

I'm not sure it can be done; maybe it can, but not in the way I've noticed or somebody's told me about.

F

Is that a question for the p4 um meeting on mondays or.

D

We could certainly discuss it. I know there was also discussion on this, of whether the reference model actually needs to do. We think the reference model should accurately let you specify these anonymous and enforce them in the reference model, or can tech, be it.

F

Do you want to join that meeting monday to ask the question or.

H

Actually, that meeting happens midnight I'm from india and that meeting happens maybe.

F

Somebody could proxy for keshav, then.

F

Maybe or I could try and go and try and proxy the question.

A

um Yeah christine, I think I will be there for the.

F

A

Ed on this stuff.

F

Okay, so you can you can bring it forth. Thank you thanks now how about this section uh down here? Let's see so did we did we cover this then, based on the what we just talked about.

D

I I think those are basically detailed reasons why I don't know how to solve it with meters. Okay,.

F

All right keshav, I'm gonna, update yours there, okay.

F

Okay, all right- and so um let's see I know, I know that costume was working on this one here. The support for this match type. So is he left on here?

F

I don't see him, but he was. He was asking some good questions and got answers from marion with respect to his work item, and um so anyone else have questions with respect to their work item.

B

In general, uh how do we test the behavioral model? We seem to be checking in code by compiling it, I'm okay, to do that. But is there any plan to at least add.

F

One that's a good question for marion, because I am not a developer.

A

uh Yes, so two things about that. First one uh this week we will have the infrastructure to uh to be able to program the software switch and we can actually add the test that what we discussed on wednesday- uh and uh we will- probably uh I don't know- maybe keysight- is going to define some test vectors uh for that. But also uh what chris proposed- and I think we should follow up on that in a couple of weeks- is um to add some uh automated pipelines into github, so that every.

G

A

We check in anything we we hit the automatic verifications. So this is what chris mentioned and I think we can revisit that in a couple of weeks.

I

Yeah, I think the timing's good. We already started internal discussions, um people above my pay grade, who make resource choices throughout this week, but in principle, I'd like to contribute in that area. Okay,.

F

And so I'm wondering too um if anyone wants to communicate something larger. Like you know, I believe my work item is finished and we'd like to test or something like that. I wonder if we could um send an email to sonic hyphen dash at google groups.com. That's what we use to manage all these notes and communicate with each other, because everyone is a member here. um Would that work for you guys um if you, rather than the the github notifications, because some of those get filtered.

F

I guess what I'm saying is: if you feel like you're done, or you have a question or if you want to test, maybe send it to to this dl here.

B

F

B

Yeah, I think that makes sense yeah. I.

F

Okay, great and um mario, unless you or I or chris, has anything else or you guys on the phone. um I guess we could give a little bit of time back. I only scheduled this for 45 minutes. So what do you think.

A

Yeah, I think we're good.

F

Okay, all right, I appreciate you guys and appreciate your time and thank you for everything and um sounds like after next week. We might be able to move forward as well. So thank you and I did record this meeting or I attempted to so I'll I'll post. It.

I

Thanks christina for running the meeting.

F

Oh yeah, no problem, you know it's always fun to hang out with the big thinkers. That's you guys get deep in the weeds of connection tracking. It's like so much.

I

Fun serious p4 sausage making.