flent-users &lt;notifications@github.com&gt; writes:<br>
<br>
&gt; HI Toke,<br>
&gt;<br>
&gt;<br>
&gt;&gt; On Sep 3, 2018, at 19:37, Toke Høiland-Jørgensen &lt;notifications@github.com&gt; wrote:<br>
&gt;&gt; <br>
&gt;&gt; flent-users &lt;notifications@github.com&gt; writes:<br>
&gt;&gt; <br>
&gt;&gt; &gt; Hi Dave,<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; On Sep 3, 2018, at 18:00, Dave Täht &lt;notifications@github.com&gt; wrote:<br>
&gt;&gt; &gt;&gt; vnv <br>
&gt;&gt; &gt;&gt; Another rrul_v2 issue would be to correctly end up in all the queues on wifi.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; So in theory rrul_cs8 should do that... (it aims to just use one<br>
&gt;&gt; &gt; dscp-marked flow per class selector for a total of 8 tcp flows per<br>
&gt;&gt; &gt; direction...) In practice I believe the mapping from dscps to ACs is<br>
&gt;&gt; &gt; highly non-linear...<br>
&gt;&gt; <br>
&gt;&gt; Well, not that non-linear:<br>
&gt;&gt; <br>
&gt;&gt; const int ieee802_1d_to_ac[8] = {<br>
&gt;&gt; IEEE80211_AC_BE,<br>
&gt;&gt; IEEE80211_AC_BK,<br>
&gt;&gt; IEEE80211_AC_BK,<br>
&gt;&gt; IEEE80211_AC_BE,<br>
&gt;&gt; IEEE80211_AC_VI,<br>
&gt;&gt; IEEE80211_AC_VI,<br>
&gt;&gt; IEEE80211_AC_VO,<br>
&gt;&gt; IEEE80211_AC_VO<br>
&gt;&gt; };<br>
&gt;<br>
&gt; Well, aren&#39;t these values according to IEEE P802.1p (https://en.wikipedia.org/wiki/IEEE_P802.1p)?<br>
&gt;<br>
&gt; PCP 	value		Priority	Acronym	Traffic types<br>
&gt; 1		0 (lowest)	BK		Background<br>
&gt; 0		1 (default)	BE		Best effort<br>
&gt; 2		2			EE		Excellent effort<br>
&gt; 3		3			CA		Critical applications<br>
&gt; 4		4			VI		Video, &lt; 100 ms latency and jitter<br>
&gt; 5		5			VO		Voice, &lt; 10 ms latency and jitter<br>
&gt; 6		6			IC		Internetwork control<br>
&gt; 7		7 (highest)	NC		Network control<br>
&gt;<br>
&gt; These map the 3 bit priority PCP values from VLAN tags to ACs, but<br>
&gt; note the dance with PCP 1 being lower than PCP 0, and more importantly<br>
&gt; the different interpretations about PCP 2, is it &quot;excellent effort&quot; or<br>
&gt; another BK code point?<br>
&gt;<br>
&gt; I guess the point I wanted to make is that mapping down from the 6bit<br>
&gt; DSCP to ACs is not very intuitive (with linear mapping being the &quot;most<br>
&gt; intuitive&quot;).<br>
&gt;<br>
&gt; Anyway, I am totally fine with just using 3 bits, this is still plenty<br>
&gt; for priority hierarchies that I can still understand ;)<br>
<br>
Oh, it&#39;s absolutely a mess. So much so that the IETF had to write a<br>
whole RFC on it: https://tools.ietf.org/html/rfc8325<br>
<br>
-Toke<br>


<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">&mdash;<br />You are receiving this because you commented.<br />Reply to this email directly, <a href="https://github.com/tohojo/flent/issues/148#issuecomment-418188201">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AerUv7PN0q0dp24Sn6PCQnZhguaD1BJkks5uXY_egaJpZM4WCoe6">mute the thread</a>.<img src="https://github.com/notifications/beacon/AerUv8t_hEFZUyWCm5PpOWol72NMoAIvks5uXY_egaJpZM4WCoe6.gif" height="1" width="1" alt="" /></p>
<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/tohojo/flent","title":"tohojo/flent","subtitle":"GitHub repository","main_image_url":"https://assets-cdn.github.com/images/email/message_cards/header.png","avatar_image_url":"https://assets-cdn.github.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/tohojo/flent"}},"updates":{"snippets":[{"icon":"PERSON","message":"@tohojo in #148: flent-users \u003cnotifications@github.com\u003e writes:\n\n\u003e HI Toke,\n\u003e\n\u003e\n\u003e\u003e On Sep 3, 2018, at 19:37, Toke Høiland-Jørgensen \u003cnotifications@github.com\u003e wrote:\n\u003e\u003e \n\u003e\u003e flent-users \u003cnotifications@github.com\u003e writes:\n\u003e\u003e \n\u003e\u003e \u003e Hi Dave,\n\u003e\u003e \u003e\n\u003e\u003e \u003e\n\u003e\u003e \u003e\u003e On Sep 3, 2018, at 18:00, Dave Täht \u003cnotifications@github.com\u003e wrote:\n\u003e\u003e \u003e\u003e vnv \n\u003e\u003e \u003e\u003e Another rrul_v2 issue would be to correctly end up in all the queues on wifi.\n\u003e\u003e \u003e\n\u003e\u003e \u003e So in theory rrul_cs8 should do that... (it aims to just use one\n\u003e\u003e \u003e dscp-marked flow per class selector for a total of 8 tcp flows per\n\u003e\u003e \u003e direction...) In practice I believe the mapping from dscps to ACs is\n\u003e\u003e \u003e highly non-linear...\n\u003e\u003e \n\u003e\u003e Well, not that non-linear:\n\u003e\u003e \n\u003e\u003e const int ieee802_1d_to_ac[8] = {\n\u003e\u003e IEEE80211_AC_BE,\n\u003e\u003e IEEE80211_AC_BK,\n\u003e\u003e IEEE80211_AC_BK,\n\u003e\u003e IEEE80211_AC_BE,\n\u003e\u003e IEEE80211_AC_VI,\n\u003e\u003e IEEE80211_AC_VI,\n\u003e\u003e IEEE80211_AC_VO,\n\u003e\u003e IEEE80211_AC_VO\n\u003e\u003e };\n\u003e\n\u003e Well, aren't these values according to IEEE P802.1p (https://en.wikipedia.org/wiki/IEEE_P802.1p)?\n\u003e\n\u003e PCP \tvalue\t\tPriority\tAcronym\tTraffic types\n\u003e 1\t\t0 (lowest)\tBK\t\tBackground\n\u003e 0\t\t1 (default)\tBE\t\tBest effort\n\u003e 2\t\t2\t\t\tEE\t\tExcellent effort\n\u003e 3\t\t3\t\t\tCA\t\tCritical applications\n\u003e 4\t\t4\t\t\tVI\t\tVideo, \u003c 100 ms latency and jitter\n\u003e 5\t\t5\t\t\tVO\t\tVoice, \u003c 10 ms latency and jitter\n\u003e 6\t\t6\t\t\tIC\t\tInternetwork control\n\u003e 7\t\t7 (highest)\tNC\t\tNetwork control\n\u003e\n\u003e These map the 3 bit priority PCP values from VLAN tags to ACs, but\n\u003e note the dance with PCP 1 being lower than PCP 0, and more importantly\n\u003e the different interpretations about PCP 2, is it \"excellent effort\" or\n\u003e another BK code point?\n\u003e\n\u003e I guess the point I wanted to make is that mapping down from the 6bit\n\u003e DSCP to ACs is not very intuitive (with linear mapping being the \"most\n\u003e intuitive\").\n\u003e\n\u003e Anyway, I am totally fine with just using 3 bits, this is still plenty\n\u003e for priority hierarchies that I can still understand ;)\n\nOh, it's absolutely a mess. So much so that the IETF had to write a\nwhole RFC on it: https://tools.ietf.org/html/rfc8325\n\n-Toke\n"}],"action":{"name":"View Issue","url":"https://github.com/tohojo/flent/issues/148#issuecomment-418188201"}}}</script>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/tohojo/flent/issues/148#issuecomment-418188201",
"url": "https://github.com/tohojo/flent/issues/148#issuecomment-418188201",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
},
{
"@type": "MessageCard",
"@context": "http://schema.org/extensions",
"hideOriginalBody": "false",
"originator": "AF6C5A86-E920-430C-9C59-A73278B5EFEB",
"title": "Re: [tohojo/flent] testing the behavior of small queue building non-ecn'd flows (#148)",
"sections": [
{
"text": "",
"activityTitle": "**Toke Høiland-Jørgensen**",
"activityImage": "https://assets-cdn.github.com/images/email/message_cards/avatar.png",
"activitySubtitle": "@tohojo",
"facts": [

]
}
],
"potentialAction": [
{
"name": "Add a comment",
"@type": "ActionCard",
"inputs": [
{
"isMultiLine": true,
"@type": "TextInput",
"id": "IssueComment",
"isRequired": false
}
],
"actions": [
{
"name": "Comment",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"IssueComment\",\n\"repositoryFullName\": \"tohojo/flent\",\n\"issueId\": 148,\n\"IssueComment\": \"{{IssueComment.value}}\"\n}"
}
]
},
{
"name": "Close issue",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"IssueClose\",\n\"repositoryFullName\": \"tohojo/flent\",\n\"issueId\": 148\n}"
},
{
"targets": [
{
"os": "default",
"uri": "https://github.com/tohojo/flent/issues/148#issuecomment-418188201"
}
],
"@type": "OpenUri",
"name": "View on GitHub"
},
{
"name": "Unsubscribe",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"MuteNotification\",\n\"threadId\": 369788858\n}"
}
],
"themeColor": "26292E"
}
]</script>