Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

max_prob & ecn #2

Open
dtaht opened this issue Dec 5, 2018 · 5 comments
Open

max_prob & ecn #2

dtaht opened this issue Dec 5, 2018 · 5 comments

Comments

@dtaht
Copy link

dtaht commented Dec 5, 2018

if (!drop_early(sch, sel_flow, skb->len)) {
    enqueue = true;
} else if (q->params.ecn && (sel_flow->vars.prob <= MAX_PROB / 10) &&
          INET_ECN_set_ce(skb)) {

Although this ecn behavior "drop at 10%" for pie is what ended up in the standard... it was entirely a handwave!!!!!, It is not backed by any hard data whatsoever, and doesn't work well in practice! I was there... when we wrote the code we felt we needed some ecn support.I figured someone from the ecn crowd would leap all over it. They didn't.

Rather than replicate this mistake...

I'd really like to see this made configurable in the range 0-100. You can leverage the existing ecn variable to do this... you just need to express ecn_prob as an int. to userspace. e.g:

else if ((sel_flow->vars.prob <= q->params.ecn) &&
INET_ECN_set_ce(skb)) {

@mohittahiliani
Copy link
Collaborator

I agree, and thanks that you took out time to mention this. I'm relieved to know that there is no hard data to justify 'drop at 10%' in RFC 8033. Indeed, this was bothering us for quite some time and we thought, maybe we're not able to get to the right document which justifies the need for 'drop at 10%' logic. Thanks, again!

@gautamramk
Copy link
Owner

So would it be better to keep it default at 10% and then make it configurable?

@chromi
Copy link

chromi commented Dec 6, 2018

That seems reasonable for now, as at least it is then possible to experiment.

Another option I would consider is instead of using a threshold to abruptly switch from marking to dropping, have the dropping percentage merely lag behind the marking percentage by the configured amount. That is, if the marking percentage reaches 11%, then 10% of the packets are actually marked, and a further 1% are dropped.

@dtaht
Copy link
Author

dtaht commented Dec 11, 2018

Sure.

@gautamramk
Copy link
Owner

I have added this feature in the latest commit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants