- tor-commits - lists.torproject.org

[translation/bridgedb] https://gitweb.torproject.org/translation.git/commit/?h=bridgedb
by translation＠torproject.org 30 Aug '21

30 Aug '21

commit d4c9c9204aab4b3129ba5b450b2a36869f682f13 Author: Translation commit bot <translation(a)torproject.org> Date: Mon Aug 30 05:15:05 2021 +0000 https://gitweb.torproject.org/translation.git/commit/?h=bridgedb --- my/LC_MESSAGES/bridgedb.po | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/my/LC_MESSAGES/bridgedb.po b/my/LC_MESSAGES/bridgedb.po index 6f2757b948..a1e75fda26 100644 --- a/my/LC_MESSAGES/bridgedb.po +++ b/my/LC_MESSAGES/bridgedb.po @@ -11,7 +11,7 @@ msgstr "" "Project-Id-Version: Tor Project\n" "Report-Msgid-Bugs-To: 'https://trac.torproject.org/projects/tor/newticket?component=BridgeDB&keywo…'\n" "POT-Creation-Date: 2020-05-14 14:21-0700\n" -"PO-Revision-Date: 2021-08-30 04:37+0000\n" +"PO-Revision-Date: 2021-08-30 04:54+0000\n" "Last-Translator: Christine Ivy <christineivy19(a)gmail.com>\n" "Language-Team: Burmese (http://www.transifex.com/otf/torproject/language/my/)\n" "MIME-Version: 1.0\n" @@ -379,23 +379,23 @@ msgid "" " Manual explains how you can add your bridges to Tor Browser. If you are\n" " using Windows, Linux, or OS X, %sclick here%s to learn more. If you\n" " are using Android, %sclick here%s." -msgstr "" +msgstr "ပထမဦးစွာ သင်သည် %sTor Browser ကို ဒေါင်းလုဒ်လုပ်ရန်%s လိုအပ်ပါသည်။ ကျွန်ုပ်တို့၏ Tor Browser အသုံးပြုသူ လက်စွဲတွင် Tor Browser သို့ သင့်တံတားများကို မည်သို့ထည့်နိုင်ကြောင်း ရှင်းပြထားသည်။ သင်သည် Windows၊ Linux သို့မဟုတ် OS X ကို အသုံးပြုနေပါက ပိုမိုလေ့လာရန် %sဒီမှာနှိပ်ပါ%s။ သင်သည် Android ကို အသုံးပြုနေပါက %sဒီမှာနှိပ်ပါ%s။" #: bridgedb/strings.py:166 msgid "" "Add these bridges to your Tor Browser by opening your browser\n" "preferences, clicking on \"Tor\", and then adding them to the \"Provide a\n" "bridge\" field." -msgstr "" +msgstr "ဤတံတားများကို သင့် Tor Browser သို့ ထည့်ရန် သင်၏ ဘရောက်ဇာ အလေးပေး ရွေးချယ်မှုကို ဖွင့်ပါ၊ \"Tor\" ကို နှိပ်ပါ၊ ပြီးလျှင် ထိုတံတားများကို \"တံတား ပံ့ပိုးရန်\" အကွက်တွင် ထည့်ပါ။" #: bridgedb/strings.py:173 msgid "(Request unobfuscated Tor bridges.)" -msgstr "" +msgstr "(နားလည်ရခက်အောင် ပြောင်းမထားသော Tor တံတားများကို တောင်းဆိုပါ။)" #: bridgedb/strings.py:174 msgid "(Request IPv6 bridges.)" -msgstr "" +msgstr "(IPv6 တံတားများကို တောင်းဆိုပါ။)" #: bridgedb/strings.py:175 msgid "(Request obfs4 obfuscated bridges.)" -msgstr "" +msgstr "obfs4 နားလည်ရခက်သော တံတားများကို တောင်းဆိုပါ။)"

1 0

[translation/bridgedb] https://gitweb.torproject.org/translation.git/commit/?h=bridgedb
by translation＠torproject.org 30 Aug '21

30 Aug '21

commit e74285ddfc8356375e98ced17e9a24ffb91080b8 Author: Translation commit bot <translation(a)torproject.org> Date: Mon Aug 30 04:45:05 2021 +0000 https://gitweb.torproject.org/translation.git/commit/?h=bridgedb --- my/LC_MESSAGES/bridgedb.po | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/my/LC_MESSAGES/bridgedb.po b/my/LC_MESSAGES/bridgedb.po index 7f2f50104b..6f2757b948 100644 --- a/my/LC_MESSAGES/bridgedb.po +++ b/my/LC_MESSAGES/bridgedb.po @@ -11,7 +11,7 @@ msgstr "" "Project-Id-Version: Tor Project\n" "Report-Msgid-Bugs-To: 'https://trac.torproject.org/projects/tor/newticket?component=BridgeDB&keywo…'\n" "POT-Creation-Date: 2020-05-14 14:21-0700\n" -"PO-Revision-Date: 2021-08-30 04:07+0000\n" +"PO-Revision-Date: 2021-08-30 04:37+0000\n" "Last-Translator: Christine Ivy <christineivy19(a)gmail.com>\n" "Language-Team: Burmese (http://www.transifex.com/otf/torproject/language/my/)\n" "MIME-Version: 1.0\n" @@ -240,7 +240,7 @@ msgstr "áá¶áá¬ážááá¯áá¬ áá¬áá²á" #: bridgedb/strings.py:79 #, python-format msgid "%s Bridges %s are Tor relays that help you circumvent censorship." -msgstr "%sáá¶áá¬ážáá»á¬áž%sáááº áááááºááŒááºáá±á¬ááºááŸá¯ááá¯ áááºááŸá±á¬ááºááŸá¬ážááá¯ááºáááº áá°áá®ááá·áº Tor áááºáá¶áááºáá»á¬áž ááŒááºáááºá" +msgstr "%sáá¶áá¬ážáá»á¬áž%sáááº áááááºááŒááºáá±á¬ááºááŸá¯ááá¯ áááºááŸá±á¬ááºááŸá¬ážááá¯ááºáááº áá°áá®ááá·áº Tor ááŒá¬ážáá¶áááºáá»á¬áž ááŒááºáááºá" #: bridgedb/strings.py:84 msgid "I need an alternative way of getting bridges!" @@ -290,7 +290,7 @@ msgid "" "the pseudo-mechanism \"None\". The following list briefly explains how these\n" "mechanisms work and our %sBridgeDB metrics%s visualize how popular each of the\n" "mechanisms is." -msgstr "BridgeDB áááº áá¶áá¬ážáá»á¬ážááá¯ ááŒáá·áºáá±áááº ááá¹ááá¬ážáá±ážáá¯ááá¯ á¡áá¯á¶ážááŒá¯áááº- \"HTTPS\"á \"Moat\"á \"á¡á®ážáá±ážááº\" ááŸáá·áº \"áá»ááºáá¬ážáááº\" ááá¯á·ááŒááºáááºá BridgeDB ááá¯á¶ážáá² ááŒáá·áºáá±ááá·áº áá¶áá¬ážáá»á¬ážá¡ááœááº áá¯á¶áá¶áá°ááá¹ááá¬áž \"áá¬áá»áŸáááŸá\" ááá¯ áá¯á¶ážáááºá á€ááá¹ááá¬ážáá»á¬áž á¡áá¯ááºáá¯ááºáá¯á¶ááŸáá·áº ááá¹ááá¬ážáááºáá¯áá®ááá¯ áááºáá»áŸáá°ááŒáá¯ááºáá»á¬ážááŒá±á¬ááºáž áá»áœááºá¯ááºááá¯á·á %sBridgeDB áááºááááº%s á ááœááºáá»ááºáá¯á¶ááá¯ á¡á±á¬ááºáá«áá¬áááºážááœááº á¡áá»ááºážáá»á¯ááºá ááŸááºážááŒáá¬ážá ááºá" +msgstr "BridgeDB áááº áá¶áá¬ážáá»á¬ážááá¯ ááŒáá·áºáá±áááº ááá¹ááá¬ážáá±ážáá¯ááá¯ á¡áá¯á¶ážááŒá¯áááº- \"HTTPS\"á \"Moat\"á \"á¡á®ážáá±ážááº\" ááŸáá·áº \"áá»ááºáá¬ážáááº\" ááá¯á·ááŒááºáááºá BridgeDB ááá¯á¶ážáá² ááŒáá·áºáá±ááá·áº áá¶áá¬ážáá»á¬ážá¡ááœááº \"áá¬ááŸáááŸá\" áá¯ áá±á«áºááá·áº ááá¹ááá¬ážááá¯ áá¯á¶ážáááºá á€ááá¹ááá¬ážáá»á¬áž á¡áá¯ááºáá¯ááºáá¯á¶ááŸáá·áº ááá¹ááá¬ážáááºáá¯áá®ááá¯ áááºáá»áŸáá°ááŒáá¯ááºáá»á¬ážááŒá±á¬ááºáž áá»áœááºá¯ááºááá¯á·á %sBridgeDB áááºááááº%s á ááœááºáá»ááºáá¯á¶ááá¯ á¡á±á¬ááºáá«áá¬áááºážááœááº á¡áá»ááºážáá»á¯ááºá ááŸááºážááŒáá ¬ážáááºá" #: bridgedb/strings.py:115 #, python-format @@ -331,7 +331,7 @@ msgid "" "bridges. Bridges that are distributed over the \"Reserved\" mechanism may not\n" "see users for a long time. Note that the \"Reserved\" distribution mechanism is\n" "called \"Unallocated\" in %sbridge pool assignment%s files." -msgstr "" +msgstr "BridgeDB áááº á¡ááá¯á¡áá»á±á¬ááº áááŒáá·áºáá±ááá·áº áá¶áá¬ážá¡áááºážáááºááá¯ ááááºážááááºážáá¬ážááŒá®áž áá»áœááºá¯ááºááá¯á·á ááá¯áá¶áá¬ážáá»á¬ážááá¯ ááá¯ááºááá¯ááº ááŒáá·áºáá±áááº áá»ááºáá¬ážáááºá áááºážááá¯á·ááá¯ áá¶áá¬ážáá»á¬áž ááá¯á¡ááºááá·áº NGO áá»á¬ážá á¡ááŒá¬áž á¡ááœá²á·á¡áááºážáá»á¬ážááŸáá·áº áá¯áá¹ááá¯ááºáá»á¬ážáá¶ áá±ážáá±áááºá \"áá»ááºáá¬ážáááº\" ááá¹ááá¬ážááŒáá·áº ááŒáá·áºáá±áá±á¬ áá¶áá¬ážáá»á¬ážááá¯ á¡áá»áááºá¡áá±á¬áºááŒá¬á¡á±á¬ááº áá¯á¶ážááœá²áá°áááŸááá² ááŒááºáááºáááºá \"áá»ááºáá¬ážáááº\" ááŒáá·áºáá±ááŒááºáž áá á¹ááá¬ážááá¯ %sáá¶áá¬ážá¡á¯ááºáá¯ áá±ážá¡ááºááá·áº%s ááá¯ááºáá»á¬ážááœááº \"ááá±ážáá±ááá±áž\" áá¯ áá±á«áºáááºá" #: bridgedb/strings.py:137 msgid "None" @@ -344,7 +344,7 @@ msgid "" "users. Note that on Relay Search, a freshly set up bridge's distribution\n" "mechanism says \"None\" for up to approximately one day. Be a bit patient, and\n" "it will then change to the bridge's actual distribution mechanism.\n" -msgstr "" +msgstr "ááŒáá·áºáá±ááŒááºáž ááá¹ááá¬ážá¡ááŒááº \"áá¬ááŸáááŸá\" ááá¯áá¯á¶ážáá±á¬ áá¶áá¬ážáá»á¬ážááá¯ BridgeDB ááŒáá·áº áááŒáá·áºáá±áá«á\náá¯á¶ážááœá²áá°áá»á¬ážáá¶ ááá¯áá¶áá¬ážáá»á¬ážááá¯ ááŒáá·áºáá±áááºááŸá¬ áá¶áá¬áž áá®áá¶ááá·áºááœá²áá°á áá¬áááºááŒááºáááºá ááŒá¬ážáá¶áááº ááŸá¬ááœá±ááŸá¯ááœááº áá±á¬áá±á¬áááºáááº áááºáá®ážáá¬ážáá±á¬ áá¶áá¬ážá ááŒáá·áºáá±áá±áž ááá¹ááá¬ážááá¯ áááºáááºáá±á¬ááºá¡áá \"áá¬ááŸáááŸá\" áá¯ ááŒáááºáááºá ááááºááŸááºááœá¬ áá±á¬áá·áºááŒá®ážáá±á¬ááº áá¶áá¬ážá á¡ááŸááºááááº ááŒáá·áºáá±ááŒááºáž ááá¹ááá¬ážááá¯á· ááŒá±á¬ááºážááœá¬ážáááºááá¯ ááœá±á·áá«áááºá\n" #: bridgedb/strings.py:148 msgid "Please select options for bridge type:" @@ -357,7 +357,7 @@ msgstr "IPv6 ááááºáá¬áá»á¬ážááá¯á¡ááºáá«ááá¬áž" #: bridgedb/strings.py:150 #, python-format msgid "Do you need a %s?" -msgstr "" +msgstr "áááºáááº %s ááá¯á¡ááºáá«ááá¬ážá" #: bridgedb/strings.py:154 msgid "Your browser is not displaying images properly." @@ -365,7 +365,7 @@ msgstr "áááºáá²á·ááá±á¬ááºáá¬áááº áá¯á¶áá»á¬ #: bridgedb/strings.py:155 msgid "Enter the characters from the image above..." -msgstr "" +msgstr "á¡áááºáá«áá¯ááºáá¯á¶ááŸ áá¬áá¯á¶ážáá»á¬ážááá¯ ááá¯ááºááá·áºáá«..." #: bridgedb/strings.py:159 msgid "How to start using your bridges"

1 0

[translation/bridgedb] https://gitweb.torproject.org/translation.git/commit/?h=bridgedb
by translation＠torproject.org 30 Aug '21

30 Aug '21

commit 8ea7aaec7637a99f5b659fd7022403c7fb0c5fb6 Author: Translation commit bot <translation(a)torproject.org> Date: Mon Aug 30 04:15:05 2021 +0000 https://gitweb.torproject.org/translation.git/commit/?h=bridgedb --- my/LC_MESSAGES/bridgedb.po | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/my/LC_MESSAGES/bridgedb.po b/my/LC_MESSAGES/bridgedb.po index 225937ea88..7f2f50104b 100644 --- a/my/LC_MESSAGES/bridgedb.po +++ b/my/LC_MESSAGES/bridgedb.po @@ -11,7 +11,7 @@ msgstr "" "Project-Id-Version: Tor Project\n" "Report-Msgid-Bugs-To: 'https://trac.torproject.org/projects/tor/newticket?component=BridgeDB&keywo…'\n" "POT-Creation-Date: 2020-05-14 14:21-0700\n" -"PO-Revision-Date: 2021-08-30 03:41+0000\n" +"PO-Revision-Date: 2021-08-30 04:07+0000\n" "Last-Translator: Christine Ivy <christineivy19(a)gmail.com>\n" "Language-Team: Burmese (http://www.transifex.com/otf/torproject/language/my/)\n" "MIME-Version: 1.0\n" @@ -290,7 +290,7 @@ msgid "" "the pseudo-mechanism \"None\". The following list briefly explains how these\n" "mechanisms work and our %sBridgeDB metrics%s visualize how popular each of the\n" "mechanisms is." -msgstr "BridgeDB သည် တံတားများကို ဖြန့်ဝေရန် ယန္တရားလေးခုကို အသုံးပြုသည်- \"HTTPS\"၊ \"Moat\"၊ \"အီးမေးလ်\" နှင့် \"မှာယူထားပြီး\" တို့ဖြစ်သည်။ BridgeDB မသုံးဘဲ ဖြန့်ဝေသည့် တံတားများအတွက် ပုံစံတူယန္တရား \"ဘာမျှမရှိ\" ကို သုံးသည်။ ဤယန္တရားများ အလုပ်လုပ်ပုံနှင့် ယန္တရားတစ်ခုစီကို မည်မျှလူကြိုက်များကြောင်း ကျွန်ုပ်တို့၏ %sBridgeDB မက်ထရစ်%s က တွက်ချက်ပုံကို အောက်ပါစာရင်းတွင် အကျဉ်းချုပ်၍ ရှင်းပြထာ းသည်။" +msgstr "BridgeDB သည် တံတားများကို ဖြန့်ဝေရန် ယန္တရားလေးခုကို အသုံးပြုသည်- \"HTTPS\"၊ \"Moat\"၊ \"အီးမေးလ်\" နှင့် \"ချန်ထားသည်\" တို့ဖြစ်သည်။ BridgeDB မသုံးဘဲ ဖြန့်ဝေသည့် တံတားများအတွက် ပုံစံတူယန္တရား \"ဘာမျှမရှိ\" ကို သုံးသည်။ ဤယန္တရားများ အလုပ်လုပ်ပုံနှင့် ယန္တရားတစ်ခုစီကို မည်မျှလူကြိုက်များကြောင်း ကျွန်ုပ်တို့၏ %sBridgeDB မက်ထရစ်%s က တွက်ချက်ပုံကို အောက်ပါစာရင်းတွင် အကျဉ်းချုပ်၍ ရှင်းပြထားသ ည်။" #: bridgedb/strings.py:115 #, python-format @@ -298,7 +298,7 @@ msgid "" "The \"HTTPS\" distribution mechanism hands out bridges over this website. To get\n" "bridges, go to %sbridges.torproject.org%s, select your preferred options, and\n" "solve the subsequent CAPTCHA." -msgstr "" +msgstr "\"HTTPS\" ဖြန့်ဝေခြင်း ယန္တရားသည် ဤဝဘ်ဆိုက်တွင် တံတားများကို ပေးဝေသည်။ တံတားများကို ရယူရန် %sbridges.torproject.org%s သို့ သွားပြီး သင်နှစ်သက်ရာ ရွေးချယ်မှုများကို ရွေးချယ်ပါ။ ထို့နောက် ပေါ်လာသော CAPTCHA ကို ဖြေရှင်းပါ။" #: bridgedb/strings.py:119 #, python-format @@ -308,7 +308,7 @@ msgid "" "your Tor Browser's %sTor settings%s, click on \"request a new bridge\", solve the\n" "subsequent CAPTCHA, and Tor Browser will automatically add your new\n" "bridges." -msgstr "" +msgstr "\"Moat\" ဖြန့်ဝေခြင်း ယန္တရားသည် Tor ဘရောက်ဇာ၏ တစ်စိတ်တစ်ပိုင်းဖြစ်ပြီး သုံးစွဲသူများသည် ၎င်းတို့၏ Tor ဘရောက်ဇာရှိ ဆက်တင်များတွင် တံတားများကို တောင်းဆိုနိုင်သည်။ တံတားများကို ရယူရန် သင့် Tor ဘရောက်ဇာရှိ %sTor ဆက်တင်များ%s သို့ သွားပါ၊ \"တံတားအသစ် တောင်းဆိုရန်\" ကို နှိပ်ပြီးနောက် ပေါ်လာသော CAPTCHA ကို ဖြေရှင်းပါ။ Tor ဘရောက်ဇာက သင်၏ တံတားအသစ်များကို အလိုအလျောက် ထည့်ပါမည်။" #: bridgedb/strings.py:125 #, python-format @@ -316,7 +316,7 @@ msgid "" "Users can request bridges from the \"Email\" distribution mechanism by sending an\n" "email to %sbridges(a)torproject.org%s and writing \"get transport obfs4\" in the\n" "email body." -msgstr "" +msgstr "သုံးစွဲသူများသည် အီးမေးလ် စာကိုယ်တွင် \"get transport obfs4\" ဟုရေး၍ %sbridges(a)torproject.org%s သို့ အီးမေးလ်ပို့ပြီး \"အီးမေးလ်\" ဖြန့်ဝေခြင်း ယန္တရားထံမှ တံတားများကို တောင်းဆိုနိုင်သည်။" #: bridgedb/strings.py:129 msgid "Reserved"

1 0

[translation/bridgedb] https://gitweb.torproject.org/translation.git/commit/?h=bridgedb
by translation＠torproject.org 30 Aug '21

30 Aug '21

commit 7a107aeee8c5b5af10552e5bda52c1528922b9a3 Author: Translation commit bot <translation(a)torproject.org> Date: Mon Aug 30 03:45:06 2021 +0000 https://gitweb.torproject.org/translation.git/commit/?h=bridgedb --- my/LC_MESSAGES/bridgedb.po | 401 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 401 insertions(+) diff --git a/my/LC_MESSAGES/bridgedb.po b/my/LC_MESSAGES/bridgedb.po new file mode 100644 index 0000000000..225937ea88 --- /dev/null +++ b/my/LC_MESSAGES/bridgedb.po @@ -0,0 +1,401 @@ +# Translations template for bridgedb. +# Copyright (C) 2020 'The Tor Project, Inc.' +# This file is distributed under the same license as the bridgedb project. +# +# Translators: +# Christine Ivy <christineivy19(a)gmail.com>, 2021 +# deirae, 2021 +# Tun Tun Aung <tuntunaung(a)codingclassroom.org>, 2021 +msgid "" +msgstr "" +"Project-Id-Version: Tor Project\n" +"Report-Msgid-Bugs-To: 'https://trac.torproject.org/projects/tor/newticket?component=BridgeDB&keywo…'\n" +"POT-Creation-Date: 2020-05-14 14:21-0700\n" +"PO-Revision-Date: 2021-08-30 03:41+0000\n" +"Last-Translator: Christine Ivy <christineivy19(a)gmail.com>\n" +"Language-Team: Burmese (http://www.transifex.com/otf/torproject/language/my/)\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.8.0\n" +"Language: my\n" +"Plural-Forms: nplurals=1; plural=0;\n" + +#. -*- coding: utf-8 ; test-case-name: bridgedb.test.test_https_server -*- +#. This file is part of BridgeDB, a Tor bridge distribution system. +#. :authors: please see included AUTHORS file +#. :copyright: (c) 2007-2017, The Tor Project, Inc. +#. (c) 2013-2017, Isis Lovecruft +#. :license: see LICENSE for licensing information +#. : The path to the HTTPS distributor's web templates. (Should be the +#. : "templates" directory in the same directory as this file.) +#. Setting `filesystem_checks` to False is recommended for production servers, +#. due to potential speed increases. This means that the atimes of the Mako +#. template files aren't rechecked every time the template is requested +#. (otherwise, if they are checked, and the atime is newer, the template is +#. recompiled). `collection_size` sets the number of compiled templates which +#. are cached before the least recently used ones are removed. See: +#. http://docs.makotemplates.org/en/latest/usage.html#using-templatelookup +#. : A list of supported language tuples. Use getSortedLangList() to read this +#. variable. +#. We use our metrics singleton to keep track of BridgeDB metrics such as +#. "number of failed HTTPS bridge requests." +#. Convert all key/value pairs from bytes to str. +#. TRANSLATORS: Please DO NOT translate the following words and/or phrases in +#. any string (regardless of capitalization and/or punctuation): +#. "BridgeDB" +#. "pluggable transport" +#. "pluggable transports" +#. "obfs4" +#. "Tor" +#. "Tor Browser" +#: bridgedb/distributors/https/server.py:154 +msgid "Sorry! Something went wrong with your request." +msgstr "ဝမ်းနည်းပါတယ်။ သင့်တောင်းဆိုမှုမှာ တစ်ခုခုမှားသွားပါတယ်။" + +#: bridgedb/distributors/https/templates/base.html:42 +msgid "Language" +msgstr "ဘာသာစကား" + +#: bridgedb/distributors/https/templates/base.html:94 +msgid "Report a Bug" +msgstr "အမှားအယွင်းများ ကိုသတင်းပို့ပါ" + +#: bridgedb/distributors/https/templates/base.html:97 +msgid "Source Code" +msgstr "အရင်းအမြစ်ကုဒ်" + +#: bridgedb/distributors/https/templates/base.html:100 +msgid "Changelog" +msgstr "အပြောင်းအလဲစာရင်း" + +#: bridgedb/distributors/https/templates/bridges.html:35 +msgid "Select All" +msgstr "အားလုံးကို ရွေးရန်" + +#: bridgedb/distributors/https/templates/bridges.html:40 +msgid "Show QRCode" +msgstr "အမြန်တုံ့ပြန်မှုသင်္ကေတ (QRကုဒ်) ကိုပြပါ" + +#: bridgedb/distributors/https/templates/bridges.html:52 +msgid "QRCode for your bridge lines" +msgstr "သင့်ရဲ့ တံတား လိုင်းများ ၏ QR သင်္ကေတ" + +#: bridgedb/distributors/https/templates/bridges.html:63 +msgid "It seems there was an error getting your QRCode." +msgstr "သင့်ရဲ့ QR သင်္ကေတ ရယူ နေစဉ် အမှား တစ်ခု ရှိခဲ့သည်။" + +#: bridgedb/distributors/https/templates/bridges.html:68 +msgid "" +"This QRCode contains your bridge lines. Scan it with a QRCode reader to copy" +" your bridge lines onto mobile and other devices." +msgstr "ဤ QR ကုဒ်တွင် သင့်တံတားလိုင်းများ ပါဝင်သည်။ ၎င်းကို QR ကုဒ်ဖတ်စက်ဖြင့် စကန်ဖတ်၍ မိုဘိုင်းဖုန်းနှင့် အခြားစက်ပစ္စည်းများပေါ်သို့ သင့်တံတားလိုင်းများကို ကူးပါ။" + +#: bridgedb/distributors/https/templates/bridges.html:110 +msgid "BridgeDB encountered an error." +msgstr "တံတား ဒေတာဘေ့စ် (BridgeDB) အမှား တစ်ခု ကြုံတွေ့ ခဲ့ရသည်။" + +#: bridgedb/distributors/https/templates/bridges.html:116 +msgid "There currently aren't any bridges available..." +msgstr "လက်ရှိတွင် တံတားများ မရရှိနိုင်ပါ..." + +#: bridgedb/distributors/https/templates/bridges.html:118 +#: bridgedb/distributors/https/templates/bridges.html:122 +#, python-format +msgid "" +" Perhaps you should try %s going back %s and choosing a different bridge " +"type!" +msgstr "%sနောက်သို့ ပြန်သွားပြီး%s မတူညီသော တံတားအမျိုးအစားတစ်ခုကို ရွေးချယ်ကြည့်ပါ။‌" + +#: bridgedb/distributors/https/templates/index.html:11 +#, python-format +msgid "Step %s1%s" +msgstr "အဆင့် %s1%s" + +#: bridgedb/distributors/https/templates/index.html:13 +#, python-format +msgid "Download %s Tor Browser %s" +msgstr "ကူးဆွဲ %s Tor ဘရောက်ဇာ %s" + +#: bridgedb/distributors/https/templates/index.html:25 +#, python-format +msgid "Step %s2%s" +msgstr "အဆင့် %s2%s" + +#: bridgedb/distributors/https/templates/index.html:28 +#: bridgedb/distributors/https/templates/index.html:30 +#, python-format +msgid "Get %s bridges %s" +msgstr "ရယူ %s ပေါင်းကူး %s" + +#: bridgedb/distributors/https/templates/index.html:40 +#, python-format +msgid "Step %s3%s" +msgstr "အဆင့် %s3%s" + +#: bridgedb/distributors/https/templates/index.html:43 +#: bridgedb/distributors/https/templates/index.html:47 +#, python-format +msgid "Now %s add the bridges to Tor Browser %s" +msgstr "ယခု %s ပေါင်းကူးများကို Tor ဘရောက်ဇာထဲသို့ ထည့်ပါ %s" + +#. TRANSLATORS: Please make sure the '%s' surrounding single letters at the +#. beginning of words are present in your final translation. Thanks! +#. (These are used to insert HTML5 underlining tags, to mark accesskeys +#. for disabled users.) +#: bridgedb/distributors/https/templates/options.html:42 +#, python-format +msgid "%sJ%sust give me bridges!" +msgstr "ကျွန်ုပ်ကို တံတားများ%sသာ%sပေးပါ။ ‌ ‌" + +#: bridgedb/distributors/https/templates/options.html:55 +msgid "Advanced Options" +msgstr "အဆင့် မြင့် ရွေးချယ်စရာများ" + +#: bridgedb/distributors/https/templates/options.html:93 +msgid "No" +msgstr "လက်မခံ့ါ" + +#: bridgedb/distributors/https/templates/options.html:94 +msgid "none" +msgstr "မရှိ" + +#. TRANSLATORS: Please make sure the '%s' surrounding single letters at the +#. beginning of words are present in your final translation. Thanks! +#. TRANSLATORS: Translate "Yes!" as in "Yes! I do need IPv6 addresses." +#: bridgedb/distributors/https/templates/options.html:131 +#, python-format +msgid "%sY%ses!" +msgstr "%sလိုအပ်%sပါသည်။" + +#. TRANSLATORS: Please make sure the '%s' surrounding single letters at the +#. beginning of words are present in your final translation. Thanks! +#. TRANSLATORS: Please do NOT translate the word "bridge"! +#: bridgedb/distributors/https/templates/options.html:154 +#, python-format +msgid "%sG%set Bridges" +msgstr "Bridges %sရယူ%sရန်" + +#: bridgedb/strings.py:33 +msgid "[This is an automated email.]" +msgstr "[အလိုအလျောက်ပေးပို့သော အီးမေးလ် ဖြစ်ပါသည်။]" + +#: bridgedb/strings.py:35 +msgid "Here are your bridges:" +msgstr "သင့်တံတားများက ဒီမှာပါ-" + +#: bridgedb/strings.py:37 +#, python-format +msgid "" +"You have exceeded the rate limit. Please slow down! The minimum time between\n" +"emails is %s hours. All further emails during this time period will be ignored." +msgstr "သင်သည် နှုန်းကန့်သတ်ချက်ကို ကျော်သွားပါပြီ။ ကျေးဇူးပြုပြီး အလျင်မလိုပါနှင့်။ အီးမေးလ်တစ်စောင်နှင့်တစ်စောင်အကြား အနည်းဆုံး %s နာရီ ခြားရပါမည်။ ဤသတ်မှတ်ချိန်အတွင်း ထပ်မံပေးပို့သော အီးမေးလ်အားလုံးကို လျစ်လျူရှုပါမည်။" + +#: bridgedb/strings.py:40 +msgid "" +"If these bridges are not what you need, reply to this email with one of\n" +"the following commands in the message body:" +msgstr "ဤတံတားများကို သင်မလိုအပ်ပါက ကျေးဇူးပြု၍ မက်ဆေ့ချ်၏ စာကိုယ်တွင် အောက်ပါတို့မှ ညွှန်ကြားချက်တစ်ခု ထည့်ပြီး ဤအီးမေးလ်ကို စာပြန်ပါ။" + +#. TRANSLATORS: Please DO NOT translate "BridgeDB". +#. TRANSLATORS: Please DO NOT translate "Pluggable Transports". +#. TRANSLATORS: Please DO NOT translate "Tor". +#. TRANSLATORS: Please DO NOT translate "Tor Network". +#: bridgedb/strings.py:50 +#, python-format +msgid "" +"BridgeDB can provide bridges with several %stypes of Pluggable Transports%s,\n" +"which can help obfuscate your connections to the Tor Network, making it more\n" +"difficult for anyone watching your internet traffic to determine that you are\n" +"using Tor.\n" +"\n" +msgstr "BridgeDB သည် တံတားများကို %sPluggable Transports အမျိုးအစား%s အနည်းငယ်ဖြင့် ပံ့ပိုးသောကြောင့် Tor Network သို့ သင်၏ ချိတ်ဆက်မှုများကို လုံးဝနားမလည်နိုင်ပါ။ ထို့ကြောင့် သင့်အင်တာနက်အသွားအလာကို စောင့်ကြည့်နေသူက သင် Tor ကို အသုံးပြုနေကြောင်း သိရန် ပိုခက်ပါသည်။\n" + +#. TRANSLATORS: Please DO NOT translate "Pluggable Transports". +#: bridgedb/strings.py:57 +msgid "" +"Some bridges with IPv6 addresses are also available, though some Pluggable\n" +"Transports aren't IPv6 compatible.\n" +"\n" +msgstr "Pluggable Transports အချို့သည် IPv6 နှင့် မကိုက်ညီသော်လည်း IPv6 လိပ်စာများပါသော တံတားအချို့ကိုလည်း ရရှိနိုင်သည်။\n" + +#. TRANSLATORS: Please DO NOT translate "BridgeDB". +#. TRANSLATORS: The phrase "plain-ol'-vanilla" means "plain, boring, +#. regular, or unexciting". Like vanilla ice cream. It refers to bridges +#. which do not have Pluggable Transports, and only speak the regular, +#. boring Tor protocol. Translate it as you see fit. Have fun with it. +#: bridgedb/strings.py:66 +#, python-format +msgid "" +"Additionally, BridgeDB has plenty of plain-ol'-vanilla bridges %s without any\n" +"Pluggable Transports %s which maybe doesn't sound as cool, but they can still\n" +"help to circumvent internet censorship in many cases.\n" +"\n" +msgstr "ထို့ပြင် BridgeDB တွင် %sPluggable Transports မပါသော%s ရိုးရှင်းသည့် တံတားများစွာ ရှိသဖြင့် ခေတ်မီသည်ဟု မထင်ရပါ။ သို့သော် ၎င်းတို့က ကိစ္စရပ်များစွာတွင် အင်တာနက် စိစစ်ဖြတ်တောက်မှုကို ရှောင်ရှားရန် ကူညီနိုင်ပါသည်။\n" + +#: bridgedb/strings.py:78 bridgedb/test/test_https.py:356 +msgid "What are bridges?" +msgstr "တံတားဆိုတာ ဘာလဲ။" + +#: bridgedb/strings.py:79 +#, python-format +msgid "%s Bridges %s are Tor relays that help you circumvent censorship." +msgstr "%sတံတားများ%sသည် စိစစ်ဖြတ်တောက်မှုကို သင်ရှောင်ရှားနိုင်ရန် ကူညီသည့် Tor လက်ခံစက်များ ဖြစ်သည်။" + +#: bridgedb/strings.py:84 +msgid "I need an alternative way of getting bridges!" +msgstr "ကျွန်ုပ်တံတားများရဖို့ အခြားရွေးချယ်စရာလမ်း လိုအပ်ပါတယ်" + +#. TRANSLATORS: Please DO NOT translate "get transport obfs4". +#: bridgedb/strings.py:86 +#, python-format +msgid "" +"Another way to get bridges is to send an email to %s. Leave the email subject\n" +"empty and write \"get transport obfs4\" in the email's message body. Please note\n" +"that you must send the email using an address from one of the following email\n" +"providers: %s or %s." +msgstr "တံတားများ ရယူရန် အခြားနည်းလမ်းမှာ %s သို့ အီးမေးလ်ပို့ရန် ဖြစ်သည်။ အီးမေးလ် အကြောင်းအရာကို အလွတ်ချန်ထားပြီး အီးမေးလ်၏ မက်ဆေ့ချ် စာကိုယ်တွင် \"get transport obfs4\" ဟု ရေးပါ။ သင်သည် အောက်ပါအီးမေးလ်ဝန်ဆောင်မှုပံ့ပိုးသူများထံမှ လိပ်စာတစ်ခုကို သုံးပြီး အီးမေးလ်ပို့ရမည်ကို ကျေးဇူးပြု၍ သတိပြုပါ- %s သို့မဟုတ် %s။" + +#: bridgedb/strings.py:94 +msgid "My bridges don't work! I need help!" +msgstr "ကျွန်ုပ်ရဲ့တံတားများအလုပ်မလုပ်ဘူး၊ အကူအညီလိုအပ်တယ်" + +#. TRANSLATORS: Please DO NOT translate "Tor Browser". +#. TRANSLATORS: The two '%s' are substituted with "Tor Browser Manual" and +#. "Support Portal", respectively. +#: bridgedb/strings.py:98 +#, python-format +msgid "" +"If your Tor Browser cannot connect, please take a look at the %s and our %s." +msgstr "သင်၏ Tor Browser အလုပ်မလုပ်ပါက ကျေးဇူးပြု၍ %s နှင့် ကျွန်ုပ်တို့၏ %s ကို ကြည့်ပါ။" + +#: bridgedb/strings.py:102 +msgid "Here are your bridge lines:" +msgstr "သင့်တံတားလိုင်းများက ဒီမှာပါ-" + +#: bridgedb/strings.py:103 +msgid "Get Bridges!" +msgstr "တံတားများကို ရယူပါ" + +#: bridgedb/strings.py:107 +msgid "Bridge distribution mechanisms" +msgstr "တံတား ဖြန့်ဝေခြင်း ယန္တရားများ" + +#. TRANSLATORS: Please DO NOT translate "BridgeDB", "HTTPS", and "Moat". +#: bridgedb/strings.py:109 +#, python-format +msgid "" +"BridgeDB implements four mechanisms to distribute bridges: \"HTTPS\", \"Moat\",\n" +"\"Email\", and \"Reserved\". Bridges that are not distributed over BridgeDB use\n" +"the pseudo-mechanism \"None\". The following list briefly explains how these\n" +"mechanisms work and our %sBridgeDB metrics%s visualize how popular each of the\n" +"mechanisms is." +msgstr "BridgeDB သည် တံတားများကို ဖြန့်ဝေရန် ယန္တရားလေးခုကို အသုံးပြုသည်- \"HTTPS\"၊ \"Moat\"၊ \"အီးမေးလ်\" နှင့် \"မှာယူထားပြီး\" တို့ဖြစ်သည်။ BridgeDB မသုံးဘဲ ဖြန့်ဝေသည့် တံတားများအတွက် ပုံစံတူယန္တရား \"ဘာမျှမရှိ\" ကို သုံးသည်။ ဤယန္တရားများ အလုပ်လုပ်ပုံနှင့် ယန္တရားတစ်ခုစီကို မည်မျှလူကြိုက်များကြောင်း ကျွန်ုပ်တို့၏ %sBridgeDB မက်ထရစ်%s က တွက်ချက်ပုံကို အောက်ပါစာရင်းတွင် အကျဉ်းချုပ်၍ ရှင်းပြထာ းသည်။" + +#: bridgedb/strings.py:115 +#, python-format +msgid "" +"The \"HTTPS\" distribution mechanism hands out bridges over this website. To get\n" +"bridges, go to %sbridges.torproject.org%s, select your preferred options, and\n" +"solve the subsequent CAPTCHA." +msgstr "" + +#: bridgedb/strings.py:119 +#, python-format +msgid "" +"The \"Moat\" distribution mechanism is part of Tor Browser, allowing users to\n" +"request bridges from inside their Tor Browser settings. To get bridges, go to\n" +"your Tor Browser's %sTor settings%s, click on \"request a new bridge\", solve the\n" +"subsequent CAPTCHA, and Tor Browser will automatically add your new\n" +"bridges." +msgstr "" + +#: bridgedb/strings.py:125 +#, python-format +msgid "" +"Users can request bridges from the \"Email\" distribution mechanism by sending an\n" +"email to %sbridges(a)torproject.org%s and writing \"get transport obfs4\" in the\n" +"email body." +msgstr "" + +#: bridgedb/strings.py:129 +msgid "Reserved" +msgstr "ကြိုတင်ကာကွယ်ထားတယ်" + +#: bridgedb/strings.py:130 +#, python-format +msgid "" +"BridgeDB maintains a small number of bridges that are not distributed\n" +"automatically. Instead, we reserve these bridges for manual distribution and\n" +"hand them out to NGOs and other organizations and individuals that need\n" +"bridges. Bridges that are distributed over the \"Reserved\" mechanism may not\n" +"see users for a long time. Note that the \"Reserved\" distribution mechanism is\n" +"called \"Unallocated\" in %sbridge pool assignment%s files." +msgstr "" + +#: bridgedb/strings.py:137 +msgid "None" +msgstr "ဘာမှမရှိ" + +#: bridgedb/strings.py:138 +msgid "" +"Bridges whose distribution mechanism is \"None\" are not distributed by BridgeDB.\n" +"It is the bridge operator's responsibility to distribute their bridges to\n" +"users. Note that on Relay Search, a freshly set up bridge's distribution\n" +"mechanism says \"None\" for up to approximately one day. Be a bit patient, and\n" +"it will then change to the bridge's actual distribution mechanism.\n" +msgstr "" + +#: bridgedb/strings.py:148 +msgid "Please select options for bridge type:" +msgstr "ကျေးဇူးပြု၍ တံတားအမျိုးအစားအတွက်ရွေးချယ်ရန် - " + +#: bridgedb/strings.py:149 +msgid "Do you need IPv6 addresses?" +msgstr "IPv6 လိပ်စာများလိုအပ်ပါသလား" + +#: bridgedb/strings.py:150 +#, python-format +msgid "Do you need a %s?" +msgstr "" + +#: bridgedb/strings.py:154 +msgid "Your browser is not displaying images properly." +msgstr "သင်ရဲ့ဘရောင်ဇာသည် ပုံများကိုစနစ်တကျပြနေခြင်း မရှိပါ။" + +#: bridgedb/strings.py:155 +msgid "Enter the characters from the image above..." +msgstr "" + +#: bridgedb/strings.py:159 +msgid "How to start using your bridges" +msgstr "သင်ရဲ့တံတားများကို ဘယ်လိုစတင်သုံးစွဲမလဲ" + +#. TRANSLATORS: Please DO NOT translate "Tor Browser". +#: bridgedb/strings.py:161 +#, python-format +msgid "" +" First, you need to %sdownload Tor Browser%s. Our Tor Browser User\n" +" Manual explains how you can add your bridges to Tor Browser. If you are\n" +" using Windows, Linux, or OS X, %sclick here%s to learn more. If you\n" +" are using Android, %sclick here%s." +msgstr "" + +#: bridgedb/strings.py:166 +msgid "" +"Add these bridges to your Tor Browser by opening your browser\n" +"preferences, clicking on \"Tor\", and then adding them to the \"Provide a\n" +"bridge\" field." +msgstr "" + +#: bridgedb/strings.py:173 +msgid "(Request unobfuscated Tor bridges.)" +msgstr "" + +#: bridgedb/strings.py:174 +msgid "(Request IPv6 bridges.)" +msgstr "" + +#: bridgedb/strings.py:175 +msgid "(Request obfs4 obfuscated bridges.)" +msgstr ""

1 0

[torspec/main] Further Prop 324 Updates:
by nickm＠torproject.org 30 Aug '21

30 Aug '21

commit 89b9702cc75f2489993790f5bb8939d58d6b0a5a Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Tue Jul 27 23:38:59 2021 +0000 Further Prop 324 Updates: - Clarify what we learned in experimentation - Clarify N-EWMA and next_cc_event behavior - Clarify order of operations in BDP estimator - Clarify and expand on parameter tuning - Clarify Vegas and Nola descriptions - Mention that we need to test intermittent clients - Update old trac URLs --- proposals/324-rtt-congestion-control.txt | 247 +++++++++++++++++-------------- 1 file changed, 137 insertions(+), 110 deletions(-) diff --git a/proposals/324-rtt-congestion-control.txt b/proposals/324-rtt-congestion-control.txt index 14f4370..dddd362 100644 --- a/proposals/324-rtt-congestion-control.txt +++ b/proposals/324-rtt-congestion-control.txt @@ -121,7 +121,7 @@ immediately sends to ack that 100th cell. Circuits will record the current RTT measurement as a field in their circuit_t data structure. The current RTT is N-EWMA smoothed[27] over a -'cc_ewma_cwnd_cnt' multiple of congestion window worth. +'cc_ewma_cwnd_cnt' multiple of congestion window worth of sendme acks. Circuits will also record the minimum and maximum RTT seen so far. @@ -155,7 +155,9 @@ itself will count towards SENDME cell counts. The details behind how these cells are handled is addressed in section [SYSTEM_INTERACTIONS]. XXX: Hrmm, this is not strictly necessary for this proposal to function. - It may make conflux easier though, but we can defer it to then. + It may make conflux easier though, but we can defer it to then. The + current implementation only counts RELAY_COMMAND_DATA towards sendme + acks, which is the same behavior as the old fixed sendme implementation. Third, authenticated SENDMEs can remain as-is in terms of protocol behavior, but will require some implementation updates to account for @@ -191,7 +193,8 @@ sub-section, and three congestion window update algorithms in [TOR_WESTWOOD], Note that the congestion window update algorithms differ slightly from the background tor-dev mails[1,2], due to corrections and improvements. Hence they have been given different names than in those two mails. The third algorithm, -[TOR_NOLA], simply uses BDP estimate directly as its congestion window. +[TOR_NOLA], simply uses the latest BDP estimate directly as its congestion +window. These algorithms will be evaluated by running Shadow simulations, to help determine parameter ranges, but experimentation on the live network @@ -209,12 +212,15 @@ value CAN become negative in the case where the cwnd is reduced while packets are inflight. While these algorithms are in use, updates and checks of the current -'package_window' field are disabled. The 'deliver_window' field is still used -to decide when to send a SENDME. In C tor, the deliver window is initially set -at 1000, but it never gets below 900, because authenticated sendmes (Proposal -289) require that we must send only one SENDME at a time, and send it -immediately after 100 cells are received. This property turns out to be very -useful for [BDP_ESTIMATION]. +'package_window' field are disabled. Where a 'package_window' value is +still needed, for example by cell packaging schedulers, 'cwnd - inflight' is +used (with checks to return 0 in the event of negative values). + +The 'deliver_window' field is still used to decide when to send a SENDME. In C +tor, the deliver window is initially set at 1000, but it never gets below 900, +because authenticated sendmes (Proposal 289) require that we must send only +one SENDME at a time, and send it immediately after 100 cells are received. +This property turns out to be very useful for [BDP_ESTIMATION]. Implementation of different algorithms should be very simple - each algorithm should have a different update function depending on the selected algorithm, @@ -259,16 +265,26 @@ The SENDME arrival rate is the most accurate way to estimate BDP, but it requires averaging over multiple SENDME acks to do so. The congestion window and inflight estimates rely on the congestion algorithm more or less correctly tracking an approximation of the BDP, and then use current and minimum RTT to -compensate for overshoot. These estimators tend to be accurate once the -congestion window exceeds BDP. +compensate for overshoot. + +The SENDME estimator tends to be accurate after ~3-5 SENDME acks. The cwnd and +inflight estimators tend to be accurate once the congestion window exceeds +BDP. We specify all three because they are all useful in various cases. These cases are broken up and combined to form the Piecewise BDP estimator. -It is also useful to smooth these estimates through N-EWMA averaging on these -estimators[27], to smooth out temporary effects. The N parameter can be -modified by consensus parameter 'cc_ewma_cwnd_cnt', which specifies the number -of congestion windows worth of SENDME acks to compute an N-EWMA average over. +The SENDME estimator is smoothed through N-EWMA averaging on these +estimators[27], to smooth out temporary effects. This is accomplished by using +an EWMA function with alpha = 2/(N+1): + + N_EWMA = BDP*2/(N+1) + N_EWMA_prev*(N-1)/(N+1). + +N is specified in terms of the number of current congestion windows worth of +SENDMEs to average, via consensus parameter 'cc_ewma_cwnd_cnt'. + +The cwnd and inflight estimators also use N-EWMA smoothing in the same way, +but only smooth the current RTT estimate, not the congestion window value. 3.1.1. SENDME arrival BDP estimation @@ -296,6 +312,11 @@ With this, the calculation becomes: BWE = num_sendmes * cc_sendme_inc / num_sendme_timestamp_delta BDP = BWE * RTT_min +However, because the timestamps are microseconds, to avoid integer +truncation, we compute the BDP using multiplication first: + + BDP = num_sendmes * cc_sendme_inc * RTT_min / num_sendme_timestamp_delta + Note that the SENDME BDP estimation will only work after two (2) SENDME acks have been received. Additionally, it tends not to be stable unless at least five (5) num_sendme's are used, due to ack compression. This is controlled by @@ -303,7 +324,8 @@ the 'cc_bwe_min' consensus parameter. If all edge connections no longer have data available to send on a circuit and all circuit queues have drained without blocking the local orconn, we stop -updating this BDP estimate and discard old timestamps. +updating this BDP estimate and discard old timestamps. However, we retain the +actual estimator value. 3.1.2. Congestion Window BDP Estimation @@ -311,7 +333,7 @@ Assuming that the current congestion window is at or above the current BDP, the bandwidth estimate is the current congestion window size divided by the RTT estimate: - BWE = cwnd / RTT_current + BWE = cwnd / RTT_current_ewma The BDP estimate is computed by multiplying the Bandwidth estimate by the *minimum* circuit latency: @@ -320,7 +342,7 @@ the *minimum* circuit latency: Simplifying: - BDP = cwnd * RTT_min / RTT_current + BDP = cwnd * RTT_min / RTT_current_ewma The net effect of this estimation is to correct for any overshoot of the cwnd over the actual BDP. It will obviously underestimate BDP if cwnd @@ -333,7 +355,7 @@ uses the current inflight packet count to derive BDP. It also subtracts local circuit queue use from the inflight packet count. This means it will be strictly less than or equal to the cwnd version: - BDP = (inflight - circ.chan_cells.n) * RTT_min / RTT_current + BDP = (inflight - circ.chan_cells.n) * RTT_min / RTT_current_ewma If all edge connections no longer have data available to send on a circuit and all circuit queues have drained without blocking the local orconn, we stop @@ -354,18 +376,6 @@ When the SENDME estimator has not gathered enough data, or has cleared its estimates based on lack of edge connection use, this estimator uses the Congestion Window BDP estimator value. -3.1.5. N-EWMA Smoothing - -To further minimize the effects of ack compression and sudden ephemeral -changes in RTT, we create smoothed versions of all three BDP estimators using -N-EWMA[27]. - -This is accomplished by using an EWMA function with alpha = 2/(N+1): - - BDP_EWMA = BDP*2/(N+1) + BDP_EWMA*(N-1)/(N+1). - -N is specified in terms of the number of current congestion windows worth of -SENDMEs to average, via consensus parameter 'cc_ewma_cwnd_cnt'. 3.2. Tor Westwood: TCP Westwood using RTT signaling [TOR_WESTWOOD] http://intronetworks.cs.luc.edu/1/html/newtcps.html#tcp-westwood @@ -385,7 +395,8 @@ and RTT_current. These are measured using the time delta between every measured arbitrarily, so long as it is larger than what we would get from SENDME. -RTT_current is N-EWMA smoothed over a congestion window worth of SENDME acks. +RTT_current is N-EWMA smoothed over 'cc_ewma_cwnd_cnt' congestion windows +worth of SENDME acks. Recall that BOOTLEG_RTT_TOR emits a congestion signal when the current RTT falls below some fractional threshold ('cc_westwood_rtt_thresh') fraction @@ -400,7 +411,9 @@ arrival, this is treated as an immediate congestion signal. ideas/xxx-backward-ecn.txt, to exit Slow Start.) Congestion signals from RTT, blocked OR connections, or ECN are processed only -once per congestion window. +once per congestion window. This is achieved through the next_cc_event flag, +which is initialized to a cwnd worth of SENDME acks, and is decremented +each ack. Congestion signals are only evaluated when it reaches 0. Note that because the congestion signal threshold of TOR_WESTWOOD is a function of RTT_max, and excessive queuing can cause an increase in RTT_max, @@ -420,8 +433,8 @@ each time we get a SENDME (aka sendme_process_circuit_level()): if next_cc_event == 0: # BOOTLEG_RTT_TOR threshold; can also be BACKWARD_ECN check: if (RTT_current < - (1−cc_westwood_rtt_thresh)*RTT_min + cc_westwood_rtt_thresh*RTT_max) or - orconn_blocked: + (100−cc_westwood_rtt_thresh)*RTT_min/100 + + cc_westwood_rtt_thresh*RTT_max/100) or orconn_blocked: if in_slow_start: cwnd += cwnd * cc_cwnd_inc_pct_ss # Exponential growth else: @@ -446,34 +459,23 @@ each time we get a SENDME (aka sendme_process_circuit_level()): http://www.mathcs.richmond.edu/~lbarnett/cs332/assignments/brakmo_peterson_… ftp://ftp.cs.princeton.edu/techreports/2000/628.pdf -TCP Vegas control algorithm makes use of two RTT measurements: -RTT_current and RTT_min. Like TCP Westwood, it also maintains a -bandwidth estimate and a BDP estimate, but those can be simplified away -with algebra. - -RTT_current is N-EWMA smoothed over a congestion window worth of SENDME acks. - -The bandwidth estimate is the current congestion window size divided by -the RTT estimate: - - BWE = cwnd/RTT_current +TCP Vegas control algorithm estimates the queue lengths at relays by +subtracting the current BDP estimate from the current congestion window. -The extra queue use along a path can thus be estimated by first -estimating the path's bandwidth-delay product: +Assuming the BDP estimate is accurate, any amount by which the congestion +window exceeds the BDP will cause data to queue. - BDP = BWE*RTT_min - -TCP Vegas then estimates the queue use caused by congestion as: +Thus, Vegas estimates estimates the queue use caused by congestion as: queue_use = cwnd - BDP - = cwnd - cwnd*RTT_min/RTT_current - = cwnd * (1 - RTT_min/RTT_current) -However, because the SENDME BDP estimate is more accurate, and because -Piecewise BDP allows us to back off more when the local OR connection is -blocked, we parameterize this cwnd-based queue_use calculation as a tunable -weighted average between the cwnd-based estimate and the piecewise estimate -(consensus parameter 'cc_vegas_bdp_mix'). +Original TCP Vegas used a cwnd BDP estimator only. However, because the SENDME +BDP estimate is more accurate, and because Piecewise BDP allows us to back off +more when the local OR connection is blocked, we use Piecewise BDP here. + +For testing, we also parameterize this queue_use calculation as a tunable +weighted average between the cwnd-based BDP estimate and the piecewise +estimate (consensus parameter 'cc_vegas_bdp_mix'). Additionally, if the local OR connection is blocked at the time of SENDME ack arrival, this is treated as an immediate congestion signal. @@ -482,7 +484,9 @@ arrival, this is treated as an immediate congestion signal. ideas/xxx-backward-ecn.txt, to exit Slow Start.) Congestion signals from RTT, blocked OR connections, or ECN are processed only -once per congestion window. +once per congestion window. This is achieved through the next_cc_event flag, +which is initialized to a cwnd worth of SENDME acks, and is decremented +each ack. Congestion signals are only evaluated when it reaches 0. Here is the complete pseudocode for TOR_VEGAS, which is run once per SENDME ack: @@ -523,7 +527,7 @@ congestion window directly to its current BDP estimate, every SENDME ack. Such an algorithm would need to overshoot the BDP slightly, especially in the presence of competing algorithms. But other than that, it can be exceedingly -simple. Like Vegas, but without puttin' on airs. Just enough strung together. +simple. Like Vegas, but without putting on airs. Just enough strung together. After meditating on this for a while, it also occurred to me that no one has named a congestion control algorithm after New Orleans. We have Reno, Vegas, @@ -531,7 +535,11 @@ and scores of others. What's up with that? Here's the pseudocode for TOR_NOLA that runs on every SENDME ack: - cwnd = BDP + cc_nola_overshoot + if orconn_blocked: + cwnd = BDP + else: + cwnd = BDP + cc_nola_overshoot + cwnd = MAX(cwnd, cc_circwindow_min) @@ -751,31 +759,25 @@ tune to ensure optimal behavior. 6.1. Congestion Signal Experiments -Our first experiments will be to conduct client-side experiments to +Our first experiments were to conduct client-side experiments to determine how stable the RTT measurements of circuits are across the live Tor network, to determine if we need more frequent SENDMEs, and/or need to use any RTT smoothing or averaging. -Once we have a reliable way to measure RTT, we will need to test the -reliability and accuracy of the Bandwidth Estimation (BWE) and -Bandwidth-Delay-Product (BDP) measurements that are required for -[TOR_WESTWOOD] and [TOR_VEGAS]. These experiments can be conducted in -Shadow, with precise network topologies for which actual bandwidth and -latency (and thus BWE and BDP) are known parameters. We should use the -most accurate form of these estimators from Shadow experimentation to -run some client tests with custom Exits on the live network, to check -for high variability in these estimates, discrepancy with client -application throughput and application latency, and other surprises. - -Care will need to be taken to increase or alter Tor's circwindow during -these experiments in Shadow and on the custom Exits, so that the default -of 1000 does not impose an artificial ceiling on circuit bandwidth. + +These experiments were performed using onion service clients and services on +the live Tor network. From these experiments, we tuned the RTT and BDP +estimators, and arrived at reasonable values for EWMA smoothing and the +minimum number of SENDME acks required to estimate BDP. + +We should check small variations in the EWMA smoothing and minimum BDP ack +counts in Shadow experimentation, to check for high variability in these +estimates, and other surprises. 6.2. Congestion Algorithm Experiments -In order to evaluate performance of congestion control algorithms, we -will need to implement [TOR_WESTWOOD], [TOR_VEGAS], and also variants of -those without the Westwood BDP fast recovery backoff. We will need to +In order to evaluate performance of congestion control algorithms, we will +need to implement [TOR_WESTWOOD], [TOR_VEGAS], and [TOR_NOLA]. We will need to simulate their use in the Shadow Tor network simulator. Simulation runs will need to evaluate performance on networks that use @@ -786,10 +788,17 @@ flow control clients, more aggressive parameters of these algorithms may need to be set, but this will result in additional queueing as well as sub-optimal behavior once all clients upgrade. -If Tor's current flow control is too aggressive, we can experiment with -kneecapping these legacy flow control Tor clients by setting a low -'circwindow' consensus parameter for them. This will allow us to set more -reasonable parameter values, without waiting for all clients to upgrade. +In particular, during live onion service testing, we noticed that these +algorithms required particularly agressive default values to compete against +a network full of current clients. As more clients upgrade, we may be able +to lower these defaults. We should get a good idea of what values we can +choose at what upgrade point, from mixed Shadow simulation. + +If Tor's current flow control is so aggressive that it causes probelems with +any amount of remaining old clients, we can experiment with kneecapping these +legacy flow control Tor clients by setting a low 'circwindow' consensus +parameter for them. This will allow us to set more reasonable parameter +values, without waiting for all clients to upgrade. Because custom congestion control can be deployed by any Exit or onion service that desires better service, we will need to be particularly @@ -801,16 +810,10 @@ closes circuits that seriously abuse the congestion control algorithm, as per [SECURITY_ANALYSIS]. This may requiring tuning CircuitEWMAHalfLife, as well as the oomkiller cutoffs. -Additionally, we will need to experiment with reducing the cell queue -limits on OR conns before they are blocked, and study the interaction -of that with treating the or conn block as a congestion signal. - - TODO: We should make that into a consensus parameter - -Finally, we should determine if the [BACKWARD_ECN] cell_t.command -congestion signal is enough of an optimization to be worth the -complexity, especially if it is only used once, to exit slow start. This -can be determined in Shadow. +Additionally, we specified that the algorithms maintain previous congestion +window estimates in the event that a circuit goes idle, rather than revert +to slow start. We should experiment with intermittent idle/active clients +to make sure that this behavior is acceptable. 6.3. Flow Control Algorithm Experiments @@ -819,8 +822,16 @@ amount of edge connection buffering as well as XON/XOFF chatter for Exits. This can be done in simulation, but will require fine-tuning on the live network. -Relays will need to report these statistics in extra-info descriptor, -to help with monitoring the live network conditions. +Additionally, we will need to experiment with reducing the cell queue +limits on OR conns before they are blocked, and study the interaction +of that with treating the or conn block as a congestion signal. + + TODO: We should make the cell queue highwater value into a consensus + parameter in the flow control implementation. + +Relays may report these statistics in extra-info descriptor, to help with +monitoring the live network conditions, but this might also require +aggregation or minimization. 6.4. Performance Metrics [EVALUATION_METRICS] @@ -828,7 +839,7 @@ Because congestion control will affect so many aspects of performance, from throughput to RTT, to load balancing, queue length, overload, and other failure conditions, the full set of performance metrics will be required: - https://trac.torproject.org/projects/tor/wiki/org/roadmaps/CoreTor/Performa… + https://gitlab.torproject.org/legacy/trac/-/wikis/org/roadmaps/CoreTor/Perf… We will also need to monitor network health for relay queue lengths, relay overload, and other signs of network stress (and particularly the @@ -840,7 +851,7 @@ During Shadow simulation, we will determine reasonable default parameters for our consensus parameters for each algorithm. We will then re-run these tuning experiments on the live Tor network, as described in: - https://trac.torproject.org/projects/tor/wiki/org/roadmaps/CoreTor/Performa… + https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/Sponsor61/P… 6.5.1. Parameters common to all algorithms @@ -870,7 +881,26 @@ These are sorted in order of importance to tune, most important first. - Tuning Notes: The lower this value is, the sooner we can get an estimate of the true BDP of a circuit. Low values may lead to massive - over-estimation, due to ack compression. + over-estimation, due to ack compression. However, if this + value is above the number of acks that fit in cc_icw, then + we won't get a BDP estimate within the first use of the circuit. + Additionally, if this value is above the number of acks that + fit in cc_cwnd_min, we may not be able to estimate BDP + when the congestion window is small. If we need small congestion + windows, we should also lower cc_sendme_inc, which will get us more + frequent acks with less data. + + cc_sendme_inc: + - Description: Specifies how many cells a SENDME acks + - Range: [1, 5000] + - Default: 50 + - Tuning Values: 25,33,50 + - Tuning Notes: + Increasing this increases overhead, but also increases BDP + estimation accuracy. Since we only use circuit-level sendmes, + and the old code sent sendmes at both every 50 cells, and every + 100, we can set this as low as 33 to have the same amount of + overhead. cc_icw: - Description: Initial congestion window for new congestion @@ -882,8 +912,8 @@ These are sorted in order of importance to tune, most important first. - Tuning Values: 150,200,250,500 - Tuning Notes: Higher initial congestion windows allow the algorithms to - more accurately, but will lead to queue bursts and latency. - Ultimately, the ICW should be set to approximately + measure initial BDP more accurately, but will lead to queue bursts + and latency. Ultimately, the ICW should be set to approximately 'cc_bwe_min'*'cc_sendme_inc', but the presence of competing fixed window clients may require higher values. @@ -896,7 +926,7 @@ These are sorted in order of importance to tune, most important first. enough data to get any acks, and will stall. If it falls below cc_bwe_min*cc_sendme_inc, connections can't use SENDME BDP estimates. Likely we want to set this around - cc_bwe_min*cc_sendme_inc. + cc_bwe_min*cc_sendme_inc, but no lower than cc_sendme_inc. circwindow: - Description: Initial congestion window for legacy Tor clients @@ -949,6 +979,10 @@ These are sorted in order of importance to tune, most important first. by during slow start, every cwnd. - Range: [10, 300] - Tuning Values: 50,100,200 + - Tuning Notes: + On the current live network, the algorithms tended to exit slow + start early, so we did not exercise this much. This may not be the + case in Shadow, or once clients upgrade to the new algorithms. cc_bdp_alg: - Description: The BDP estimation algorithm to use. @@ -957,13 +991,6 @@ These are sorted in order of importance to tune, most important first. - Tuning Notes: We don't expect to need to tune this. - cc_sendme_inc: - - Description: Specifies how many cells a SENDME acks - - Range: [1, 5000] - - Default: 50 - - Tuning Notes: - We don't expect to need to tune this. - 6.5.2. Westwood parameters cc_westwood_rtt_thresh: @@ -1324,10 +1351,10 @@ as well as review of our versions of the algorithms. https://github.com/torproject/tor/blob/master/doc/HACKING/CircuitPaddingDev… 24. Plans for Tor Live Network Performance Experiments - https://trac.torproject.org/projects/tor/wiki/org/roadmaps/CoreTor/Performa… + https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/Sponsor61/P… 25. Tor Performance Metrics for Live Network Tuning - https://trac.torproject.org/projects/tor/wiki/org/roadmaps/CoreTor/Performa… + https://gitlab.torproject.org/legacy/trac/-/wikis/org/roadmaps/CoreTor/Perf… 26. Bandwidth-Delay Product https://en.wikipedia.org/wiki/Bandwidth-delay_product

1 0

[torspec/main] Update Prop 324 since prototype.
by nickm＠torproject.org 30 Aug '21

30 Aug '21

commit 9e704923e71dde08263bd3b79c2bb167b79f037d Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Thu Jul 1 23:10:57 2021 +0000 Update Prop 324 since prototype. - Correct algorithms to update once per cwnd - Clarify orconn blocking and edge connection checks - Mention Westwood RTT backoff, and a couple other fixes - Specify BDP estimators based on testing and bugfixing. - Specify BDP-based congestion algorithm (TOR_NOLA) - Update consensus parameters with tuning notes. --- proposals/324-rtt-congestion-control.txt | 729 ++++++++++++++++++++----------- 1 file changed, 463 insertions(+), 266 deletions(-) diff --git a/proposals/324-rtt-congestion-control.txt b/proposals/324-rtt-congestion-control.txt index 807471b..14f4370 100644 --- a/proposals/324-rtt-congestion-control.txt +++ b/proposals/324-rtt-congestion-control.txt @@ -120,8 +120,10 @@ and the arrival of the SENDME command that the other endpoint immediately sends to ack that 100th cell. Circuits will record the current RTT measurement as a field in their -circuit_t data structure. They will also record the minimum and maximum -RTT seen so far. +circuit_t data structure. The current RTT is N-EWMA smoothed[27] over a +'cc_ewma_cwnd_cnt' multiple of congestion window worth. + +Circuits will also record the minimum and maximum RTT seen so far. Algorithms that make use of this RTT measurement for congestion window update are specified in [CONTROL_ALGORITHMS]. @@ -137,7 +139,7 @@ algorithm mechanisms. We will need a similar announcement in the onion service descriptors of services that support congestion control. Second, we will turn CIRCWINDOW_INCREMENT into a consensus parameter -'circwindow_inc', instead of using a hardcoded value of 100 cells. It is +cc_sendme_inc, instead of using a hardcoded value of 100 cells. It is likely that more frequent SENDME cells will provide quicker reaction to congestion, since the RTT will be measured more often. If experimentation in Shadow shows that more frequent SENDMEs reduce @@ -145,26 +147,15 @@ congestion and improve performance but add significant overhead, we can reduce SENDME overhead by allowing SENDME cells to carry stream data, as well, using Proposal 325. - TODO: If two endpoints view different consensus parameters for - 'circwindow_inc', we will have complications measuring RTT, - as well as complications for authenticated SENDME hash - accounting. We need a way for endpoints to negotiate SENDME - pacing with eachother, perhaps during circuit setup. This will - require changes to the Onionskin/CREATE cell format (and - RELAY_COMMAND_EXTEND), as mentioned in Section [PROTOCOL_SPEC]. - This could be accomplished via hs-ntor's handshake, which - allows extra data fields in the circuit handshake. - - TODO: circwindow_inc's rate of change could be capped for safety - - TODO: As an optimization, 'circwindow_inc' could change as a function - of slow start vs AIMD. + TODO: Refer to or include final version of the negotiation proposal for + this: https://gitlab.torproject.org/tpo/core/tor/-/issues/40377 Second, all end-to-end relay cells except RELAY_COMMAND_DROP and SENDME itself will count towards SENDME cell counts. The details behind how these cells are handled is addressed in section [SYSTEM_INTERACTIONS]. - TODO: List any other exceptions. There probably are some more. + XXX: Hrmm, this is not strictly necessary for this proposal to function. + It may make conflux easier though, but we can defer it to then. Third, authenticated SENDMEs can remain as-is in terms of protocol behavior, but will require some implementation updates to account for @@ -184,14 +175,23 @@ streams and backpressure is covered in [FLOW_CONTROL]. 3. Congestion Window Update Algorithms [CONTROL_ALGORITHMS] -We specify two candidate window update algorithms. The specification -describes the update algorithms for the slow start phase and the -steady state phase separately, with some explanation. Then the -combined algorithm is given. +In general, the goal of congestion control is to ensure full and fair +utilization of the capacity of a network path -- in the case of Tor the spare +capacity of the circuit. This is accomplished by setting the congestion window +to target the Bandwidth-Delay Product[28] (BDP) of the circuit in one way or +another, so that the total data outstanding is roughly equal to the actual +transit capacity of the circuit. + +There are several ways to update a congestion window to target the BDP. Some +use direct BDP estimation, where as others use backoff properties to achieve +this. We specify three BDP estimation algorithms in the [BDP_ESTIMATION] +sub-section, and three congestion window update algorithms in [TOR_WESTWOOD], +[TOR_VEGAS], and [TOR_NOLA]. -Note that these algorithms differ slightly from the background tor-dev -mails[1,2], due to corrections and improvements. Hence they have been -given different names than in those two mails. +Note that the congestion window update algorithms differ slightly from the +background tor-dev mails[1,2], due to corrections and improvements. Hence they +have been given different names than in those two mails. The third algorithm, +[TOR_NOLA], simply uses BDP estimate directly as its congestion window. These algorithms will be evaluated by running Shadow simulations, to help determine parameter ranges, but experimentation on the live network @@ -200,24 +200,25 @@ when in competition with our current SENDME behavior, as used by real network traffic. This experimentation and tuning is detailed in section [EVALUATION]. -All of these algorithms have rules to update 'cwnd' - the current -congestion window max. They also change the meaning of 'package_window' -to be a positive count of the total number of sent cells that are awaiting -SENDME ack. Thus, 'package_window' is never allowed to exceed 'cwnd', and -the remaining cells that can be sent at any time is 'cwnd - package_window'. - -C Tor also maintains a 'deliver_window', which it uses to track how many cells -it has received, in order to send the appropriate number of SENDME acks. - - TODO: This 'deliver_window' count can be updated by the other - endpoint using the congestion control rules to watch for - cheating. Alternatively, it can be simplified just to count - the number of cells we get until we send a SENDME. +All of these algorithms have rules to update 'cwnd' - the current congestion +window, which starts out at a value controlled by consensus parameter +'cc_icw'. The algorithms also keep track of 'inflight', which is a count of +the number of cells currently not yet acked by a SENDME. The algorithm MUST +ensure that cells cease being sent if 'cwnd - inflight <= 0'. Note that this +value CAN become negative in the case where the cwnd is reduced while packets +are inflight. + +While these algorithms are in use, updates and checks of the current +'package_window' field are disabled. The 'deliver_window' field is still used +to decide when to send a SENDME. In C tor, the deliver window is initially set +at 1000, but it never gets below 900, because authenticated sendmes (Proposal +289) require that we must send only one SENDME at a time, and send it +immediately after 100 cells are received. This property turns out to be very +useful for [BDP_ESTIMATION]. Implementation of different algorithms should be very simple - each -algorithm should have a different set of package_window update functions -depending on the selected algorithm, as specified by consensus parameter -'cc_alg'. +algorithm should have a different update function depending on the selected algorithm, +as specified by consensus parameter 'cc_alg'. For C Tor's current flow control, these functions are defined in sendme.c, and are called by relay.c: @@ -240,165 +241,206 @@ after too many congestion signals. These are deliberate choices that simplify the algorithms and also should provide better performance for Tor workloads. - TODO: We may want to experiment with adding revert-to-slow-start back - in, but slow start is very expensive in a lot of ways, so let's - see if we can avoid falling back into it, if at all possible. +In all cases, variables in these sections are either consensus parameters +specified in [CONSENSUS_PARAMETERS], or scoped to the circuit. Consensus +parameters for congestion control are all prefixed by cc_. Everything else +is circuit-scoped. -For explanatory reasons, we present the slow start and the AIMD portions of -each algorithm separately, and then combine the two pieces to show the -full control algorithm, in each case. The full algorithms are considered -canonical (sections 3.1.3 and 3.2.3). -Note that these algorithms contain division in this shorthand. Division can be -elided with relocating those lines to update less often (ie: only once per -'cwnd', to avoid dividing by 'cwnd' every SENDME). +3.1. Estimating Bandwidth-Delay Product [BDP_ESTIMATION] -In all cases, variables in these sections are either consensus parameters -specified in [CONSENSUS_PARAMETERS], or scoped to the circuit. +At a high-level, there are three main ways to estimate the Bandwidth-Delay +Product: by using the current congestion window and RTT, by using the inflight +cells and RTT, and by measuring SENDME arrival rate. +All three estimators are updated every SENDME ack arrival. -3.1. Tor Westwood: TCP Westwood using RTT signaling [TOR_WESTWOOD] - http://intronetworks.cs.luc.edu/1/html/newtcps.html#tcp-westwood - http://nrlweb.cs.ucla.edu/nrlweb/publication/download/99/2001-mobicom-0.pdf - http://cpham.perso.univ-pau.fr/TCP/ccr_v31.pdf - https://c3lab.poliba.it/images/d/d7/Westwood_linux.pdf +The SENDME arrival rate is the most accurate way to estimate BDP, but it +requires averaging over multiple SENDME acks to do so. The congestion window +and inflight estimates rely on the congestion algorithm more or less correctly +tracking an approximation of the BDP, and then use current and minimum RTT to +compensate for overshoot. These estimators tend to be accurate once the +congestion window exceeds BDP. -Recall that TCP Westwood is basically TCP Reno, but it uses RTT to help -estimate the bandwidth-delay-product (BDP) of the link, and use that for -"Fast recovery" after a congestion signal arrives. +We specify all three because they are all useful in various cases. These cases +are broken up and combined to form the Piecewise BDP estimator. -We will also be using the RTT congestion signal as per BOOTLEG_RTT_TOR -here, from the Options mail[1] and Defenestrator paper[3]. +It is also useful to smooth these estimates through N-EWMA averaging on these +estimators[27], to smooth out temporary effects. The N parameter can be +modified by consensus parameter 'cc_ewma_cwnd_cnt', which specifies the number +of congestion windows worth of SENDME acks to compute an N-EWMA average over. -This system must keep track of two main measurements, per circuit: -RTT_min, and RTT_max. Both are measured using the time delta between -every 'circwindow_inc' relay cells and the SENDME response. The first RTT_min -can be measured arbitrarily, so long as it is larger than what we would get -from SENDME. +3.1.1. SENDME arrival BDP estimation -Recall that BOOTLEG_RTT_TOR emits a congestion signal when the current -RTT falls below some fractional threshold ('rtt_thresh') fraction -between RTT_min and RTT_max. This check is: - RTT_current < (1−rtt_thresh)*RTT_min + rtt_thresh*RTT_max +The most accurate way to estimate BDP is to measure the amount of time between +SENDME acks. In this period of time, we know that the endpoint successfully +received 'cc_sendme_inc' cells. -(We can also optionally use the ECN signal described in -ideas/xxx-backward-ecn.txt, to exit Slow Start.) +This means that the bandwidth of the circuit is then calculated as: -Tor Westwood will require each circuit endpoint to maintain a -Bandwidth-Delay-Product (BDP) and Bandwidth Estimate (BWE) variable. + BWE = cc_sendme_inc/sendme_ack_timestamp_delta -The bandwidth estimate is the current congestion window size divided by -the RTT estimate: +The bandwidth delay product of the circuit is calculated by multiplying this +bandwidth estimate by the *minimum* RTT time of the circuit (to avoid counting +queue time): + + BDP = BWE * RTT_min + +In order to minimize the effects of ack compression (aka SENDME responses +becoming close to one another due to queue delay on the return), we +maintain a history a full congestion window worth of previous SENDME +timestamps. + +With this, the calculation becomes: + + BWE = num_sendmes * cc_sendme_inc / num_sendme_timestamp_delta + BDP = BWE * RTT_min + +Note that the SENDME BDP estimation will only work after two (2) SENDME acks +have been received. Additionally, it tends not to be stable unless at least +five (5) num_sendme's are used, due to ack compression. This is controlled by +the 'cc_bwe_min' consensus parameter. + +If all edge connections no longer have data available to send on a circuit +and all circuit queues have drained without blocking the local orconn, we stop +updating this BDP estimate and discard old timestamps. + +3.1.2. Congestion Window BDP Estimation + +Assuming that the current congestion window is at or above the current BDP, +the bandwidth estimate is the current congestion window size divided by the +RTT estimate: BWE = cwnd / RTT_current The BDP estimate is computed by multiplying the Bandwidth estimate by -the circuit latency: +the *minimum* circuit latency: BDP = BWE * RTT_min -The BDP can also be measured directly using the peak package_window observed -on the circuit so far (though this may over-estimate if queues build up): +Simplifying: - BDP = max(package_window) + BDP = cwnd * RTT_min / RTT_current -This queue delay error may be reduced by using the RTT during the max -package_window to get BWE, and then computing BDP: +The net effect of this estimation is to correct for any overshoot of +the cwnd over the actual BDP. It will obviously underestimate BDP if cwnd +is below BDP. - BWE = max(package_window)/RTT_current # RTT during max package_window - BDP = BWE * RTT_min +3.1.3. Inflight BDP Estimation - TODO: Different papers on TCP Westwood and TCP Vegas recommend - different methods for estimating BWE and BDP. See citations for - details, but common options for BWE are 'package_window/RTT_current' - or 'circwindow_inc*sendme_arrival_rate'. They also recommend - averaging and filtering of the BWE, due to ack compression in - inbound queues. We will need to experiment to determine how to - best compute the BWE and BDP for Tor circuits. +Similar to the congestion window based estimation, the inflight estimation +uses the current inflight packet count to derive BDP. It also subtracts local +circuit queue use from the inflight packet count. This means it will be strictly +less than or equal to the cwnd version: -3.1.1. Tor Westwood: Slow Start + BDP = (inflight - circ.chan_cells.n) * RTT_min / RTT_current -Prior to the first congestion signal, Tor Westwood will update its -congestion window exponentially, as per Slow Start. +If all edge connections no longer have data available to send on a circuit +and all circuit queues have drained without blocking the local orconn, we stop +updating this BDP estimate, because there are not sufficient inflight cells +to properly estimate BDP. -Recall that this first congestion signal can be either BOOTLEG_RTT_TOR's -RTT threshold signal, or ideas/xxx-backward-ecn.txt cell command signal. +3.1.4. Piecewise BDP estimation -For simplicity, we will just write the BOOTLEG_RTT_TOR check, which -compares the current RTT measurement to the observed min and max RTT, -using the consensus parameter 'rtt_thresh'. +The piecewise BDP estimation is used to help respond more quickly in the event +the local OR connection is blocked, which indicates congestion somewhere along +the path from the client to the guard (or between Exit and Middle). In this +case, it takes the minimum of the inflight and SENDME estimators. -This section of the update algorithm is: +When the local OR connection is not blocked, this estimator uses the max of +the SENDME and cwnd estimator values. - package_window = package_window - circwindow_inc # For acked cells +When the SENDME estimator has not gathered enough data, or has cleared its +estimates based on lack of edge connection use, this estimator uses the +Congestion Window BDP estimator value. - # BOOTLEG_RTT_TOR threshold check: - if RTT_current < (1−rtt_thresh)*RTT_min + rtt_thresh*RTT_max: - cwnd = cwnd + circwindow_inc # Exponential growth - else: - BDP = BWE*RTT_min # Or other BDP estimate - cwnd = min(cwnd * cwnd_recovery_m, BDP) - in_slow_start = 0 +3.1.5. N-EWMA Smoothing -Increasing the congestion window by 100 *more* cells every SENDME allows -the sender to send 100 *more* cells every 100 cells. Thus, this is an -exponential function that causes cwnd to double every cwnd cells. +To further minimize the effects of ack compression and sudden ephemeral +changes in RTT, we create smoothed versions of all three BDP estimators using +N-EWMA[27]. -Once a congestion signal is experienced, Slow Start is exited, and the -Additive-Increase-Multiplicative-Decrease (AIMD) steady-state phase -begins. +This is accomplished by using an EWMA function with alpha = 2/(N+1): -3.1.2. Tor Westwood: Steady State AIMD + BDP_EWMA = BDP*2/(N+1) + BDP_EWMA*(N-1)/(N+1). -After slow start exits, in steady-state, after every SENDME response -without a congestion signal, the window is updated as: +N is specified in terms of the number of current congestion windows worth of +SENDMEs to average, via consensus parameter 'cc_ewma_cwnd_cnt'. - package_window = package_window - circwindow_inc # For acked cells - cwnd = cwnd + circwindow_inc/cwnd # Linear window growth +3.2. Tor Westwood: TCP Westwood using RTT signaling [TOR_WESTWOOD] + http://intronetworks.cs.luc.edu/1/html/newtcps.html#tcp-westwood + http://nrlweb.cs.ucla.edu/nrlweb/publication/download/99/2001-mobicom-0.pdf + http://cpham.perso.univ-pau.fr/TCP/ccr_v31.pdf + https://c3lab.poliba.it/images/d/d7/Westwood_linux.pdf + +Recall that TCP Westwood is basically TCP Reno, but it uses BDP estimates +for "Fast recovery" after a congestion signal arrives. + +We will also be using the RTT congestion signal as per BOOTLEG_RTT_TOR +here, from the Options mail[1] and Defenestrator paper[3]. -This comes out to increasing cwnd by 1, every time cwnd cells are -successfully sent without a congestion signal occurring. Thus this is -additive linear growth, not exponential growth. +This system must keep track of RTT measurements per circuit: RTT_min, RTT_max, +and RTT_current. These are measured using the time delta between every +'cc_sendme_inc' relay cells and the SENDME response. The first RTT_min can be +measured arbitrarily, so long as it is larger than what we would get from +SENDME. -If there is a congestion signal, cwnd is updated as: +RTT_current is N-EWMA smoothed over a congestion window worth of SENDME acks. - package_window = package_window - circwindow_inc # For acked cells - cwnd = min(cwnd * cwnd_recovery_m, BDP) # For window shrink +Recall that BOOTLEG_RTT_TOR emits a congestion signal when the current +RTT falls below some fractional threshold ('cc_westwood_rtt_thresh') fraction +between RTT_min and RTT_max. This check is: + RTT_current < (1−cc_westwood_rtt_thresh)*RTT_min + + cc_westwood_rtt_thresh*RTT_max -This is called "Fast Recovery". If you dig into the citations, actual -TCP Westwood has some additional details for responding to multiple -packet losses that in some cases can fall back into slow-start, as well -as some smoothing of the BDP to make up for dropped acks. Tor does not -need either of these aspects of complexity. +Additionally, if the local OR connection is blocked at the time of SENDME ack +arrival, this is treated as an immediate congestion signal. -3.1.3. Tor Westwood: Complete SENDME Update Algorithm +(We can also optionally use the ECN signal described in +ideas/xxx-backward-ecn.txt, to exit Slow Start.) -Here is the complete congestion window algorithm for Tor Westwood, using -only RTT signaling. +Congestion signals from RTT, blocked OR connections, or ECN are processed only +once per congestion window. -Recall that 'package_window' is not allowed to exceed 'cwnd' while sending. -'package_window' must also never become negative - this is a protocol error -that indicates a malicious endpoint. +Note that because the congestion signal threshold of TOR_WESTWOOD is a +function of RTT_max, and excessive queuing can cause an increase in RTT_max, +TOR_WESTWOOD may have a runaway condition. For this reason, we specify a +cc_westwodd_rtt_m backoff parameter, which can reduce RTT_max by a percentage +of the difference between RTT_min and RTT_max, in the event of congestion. -This will run each time we get a SENDME (aka sendme_process_circuit_level()): +Here is the complete congestion window algorithm for Tor Westwood. This will run +each time we get a SENDME (aka sendme_process_circuit_level()): - in_slow_start = 1 # Per-circuit indicator + # Update acked cells + inflight -= cc_sendme_inc - Every received SENDME ack, do: - package_window = package_window - circwindow_inc # Update acked cells + if next_cc_event: + next_cc_event-- - # BOOTLEG_RTT_TOR threshold; can also be BACKWARD_ECN check: - if RTT_current < (1−rtt_thresh)*RTT_min + rtt_thresh*RTT_max: - if in_slow_start: - cwnd = cwnd + circwindow_inc # Exponential growth - else: - cwnd = cwnd + circwindow_inc/cwnd # Linear growth + if next_cc_event == 0: + # BOOTLEG_RTT_TOR threshold; can also be BACKWARD_ECN check: + if (RTT_current < + (1−cc_westwood_rtt_thresh)*RTT_min + cc_westwood_rtt_thresh*RTT_max) or + orconn_blocked: + if in_slow_start: + cwnd += cwnd * cc_cwnd_inc_pct_ss # Exponential growth + else: + cwnd = cwnd + cc_cwnd_inc # Linear growth + else: + if cc_westwood_backoff_min: + cwnd = min(cwnd * cc_westwood_cwnd_m, BDP) # Window shrink else: - BDP = BWE*RTT_min - cwnd = min(cwnd * cwnd_recovery_m, BDP) # Window shrink - in_slow_start = 0 + cwnd = max(cwnd * cc_westwood_cwnd_m, BDP) # Window shrink + in_slow_start = 0 + + # Back off RTT_max (in case of runaway RTT_max) + RTT_max = RTT_min + cc_westwood_rtt_m * (RTT_max - RTT_min) + + cwnd = MAX(cwnd, cc_circwindow_min) + next_cc_event = cwnd / (cc_cwnd_inc_rate * cc_sendme_inc) -3.2. Tor Vegas: TCP Vegas with Aggressive Slow Start [TOR_VEGAS] + +3.3. Tor Vegas: TCP Vegas with Aggressive Slow Start [TOR_VEGAS] http://intronetworks.cs.luc.edu/1/html/newtcps.html#tcp-vegas http://pages.cs.wisc.edu/~akella/CS740/F08/740-Papers/BOP94.pdf http://www.mathcs.richmond.edu/~lbarnett/cs332/assignments/brakmo_peterson_… @@ -409,6 +451,8 @@ RTT_current and RTT_min. Like TCP Westwood, it also maintains a bandwidth estimate and a BDP estimate, but those can be simplified away with algebra. +RTT_current is N-EWMA smoothed over a congestion window worth of SENDME acks. + The bandwidth estimate is the current congestion window size divided by the RTT estimate: @@ -425,90 +469,70 @@ TCP Vegas then estimates the queue use caused by congestion as: = cwnd - cwnd*RTT_min/RTT_current = cwnd * (1 - RTT_min/RTT_current) -So only RTT_min and RTT_current need to be recorded to provide this -queue_use estimate. - - TODO: This simplification might not hold for some versions of BWE - and BDP estimation. See also the [TOR_WESTWOOD] section's TODO - and paper citations for both TCP Westwood and TCP Vegas. In - particular, see Section 3.5.2 of: - http://pages.cs.wisc.edu/~akella/CS740/F08/740-Papers/BOP94.pdf - or Section 3.2 of: - http://www.mathcs.richmond.edu/~lbarnett/cs332/assignments/brakmo_peterson_… +However, because the SENDME BDP estimate is more accurate, and because +Piecewise BDP allows us to back off more when the local OR connection is +blocked, we parameterize this cwnd-based queue_use calculation as a tunable +weighted average between the cwnd-based estimate and the piecewise estimate +(consensus parameter 'cc_vegas_bdp_mix'). -3.2.1. Tor Vegas Slow Start +Additionally, if the local OR connection is blocked at the time of SENDME ack +arrival, this is treated as an immediate congestion signal. -During slow start, we will increase our window exponentially, so long as -this queue_use estimate is below the 'vegas_gamma' consensus parameter. +(We can also optionally use the ECN signal described in +ideas/xxx-backward-ecn.txt, to exit Slow Start.) -We also re-use the Tor Westwood backoff, upon exit from Slow Start. +Congestion signals from RTT, blocked OR connections, or ECN are processed only +once per congestion window. -Note though that the exit from Slow Start for here does *not* use the -BOOTLEG_RTT_TOR style RTT threshold, and instead relies on the -queue_use calculation directly. +Here is the complete pseudocode for TOR_VEGAS, which is run once per SENDME +ack: -Tor Vegas slow start can also be exited due to [BACKWARD_ECN] cell -signal, which is omitted for brevity and clarity. + # Update acked cells + inflight -= cc_sendme_inc - package_window = package_window - circwindow_inc # Ack cells + if next_cc_event: + next_cc_event-- - if queue_use < vegas_gamma: # Vegas RTT check - cwnd = cwnd + circwindow_inc # Exponential growth - else: - BDP = BWE*RTT_min # Or other BDP estimate - cwnd = min(cwnd * cwnd_recovery_m, BDP) # Westwood backoff - in_slow_start = 0 - -3.2.2. Tor Vegas: Steady State Queue Tracking + if next_cc_event == 0: + if BDP > cwnd: + queue_use = 0 + else: + queue_use = cwnd - BDP -Recall that TCP Vegas does not use AIMD in the steady state. Because -TCP Vegas is actually trying to directly control the queue use -on the path, its updates are additive and subtractive only. + if in_slow_start: + if queue_use < cc_vegas_gamma and not orconn_blocked: + cwnd = MAX(cwnd * cc_cwnd_inc_pct_ss, BDP) # Exponential or BDP + else: + cwnd = BDP + in_slow_start = 0 + else: + if queue_use > cc_vegas_beta or orconn_blocked: + cwnd += cc_cwnd_inc + elif queue_use < cc_vegas_alpha: + cwnd -= cc_cwnd_inc -If queue_use drops below a threshold alpha (typically 2-3 packets for -TCP Vegas, but perhaps double or triple that for our smaller cells), -then the congestion window is increased. If queue_use exceeds a -threshold beta (typically 4-6 packets, but again we should probably -double or triple this), then the congestion window is decreased. + cwnd = MAX(cwnd, cc_circwindow_min) + next_cc_event = cwnd / (cc_cwnd_inc_rate * cc_sendme_inc) - package_window = package_window - circwindow_inc # Ack cells - if queue_use < vegas_alpha: - cwnd = cwnd + circwindow_inc/cwnd # linear growth - elif queue_use > vegas_beta: - cwnd = cwnd - circwindow_inc/cwnd # linear backoff +3.4. Tor NOLA: Direct BDP tracker [TOR_NOLA] -Notice that we only change the window size by a single packet per -congestion window, rather than by the full delta between current -queue_use and the target value. This is done because if more than one -connection jumps to use the available bandwidth at once, excess -congestion will result (or underutilization). +Based on the theory that congestion control should track the BDP, +the simplest possible congestion control algorithm could just set the +congestion window directly to its current BDP estimate, every SENDME ack. -3.2.3. Tor Vegas: Complete SENDME Update Algorithm +Such an algorithm would need to overshoot the BDP slightly, especially in the +presence of competing algorithms. But other than that, it can be exceedingly +simple. Like Vegas, but without puttin' on airs. Just enough strung together. -Recall that 'package_window' is not allowed to exceed 'cwnd' while sending. -'package_window' must also never become negative - this is a protocol error -that indicates a malicious endpoint. +After meditating on this for a while, it also occurred to me that no one has +named a congestion control algorithm after New Orleans. We have Reno, Vegas, +and scores of others. What's up with that? - in_slow_start = 1 # Per-circuit indicator +Here's the pseudocode for TOR_NOLA that runs on every SENDME ack: - Every received SENDME ack: - package_window = package_window - circwindow_inc # Update acked cells - - queue_use = cwnd * (1 - RTT_min/RTT_current) - - if in_slow_start: - if queue_use < vegas_gamma: - cwnd = cwnd + circwindow_inc # Exponential growth - else: - BDP = BWE*RTT_min # Or other BDP estimate - cwnd = min(cwnd * cwnd_recovery_m, BDP) # Westwood backoff - in_slow_start = 0 - else: - if queue_use < vegas_alpha: - cwnd = cwnd + circwindow_inc/cwnd # linear growth - elif queue_use > vegas_beta: - cwnd = cwnd - circwindow_inc/cwnd # linear backoff + cwnd = BDP + cc_nola_overshoot + cwnd = MAX(cwnd, cc_circwindow_min) 4. Flow Control [FLOW_CONTROL] @@ -574,7 +598,7 @@ build up in a queue at that endpoint. Three consensus parameters will govern the max length of this queue: xoff_client, xoff_exit, and xoff_mobile. These will be used for Tor -clients, exits, and mobile devices, respectively. These cuttofs will be +clients, exits, and mobile devices, respectively. These cutoffs will be a percentage of current 'cwnd' rather than number of cells. Something like 5% of 'cwnd' should be plenty, since these edge connections should normally drain *much* faster than Tor itself. @@ -757,9 +781,15 @@ simulate their use in the Shadow Tor network simulator. Simulation runs will need to evaluate performance on networks that use only one algorithm, as well as on networks that run a combinations of algorithms - particularly each type of congestion control in combination -with Tor's current flow control. If Tor's current flow control is too -aggressive, we can experiment with kneecapping these legacy flow control -Tor clients by setting a low 'circwindow' consensus parameter for them. +with Tor's current flow control. Depending upon the number of current +flow control clients, more aggressive parameters of these algorithms may +need to be set, but this will result in additional queueing as well as +sub-optimal behavior once all clients upgrade. + +If Tor's current flow control is too aggressive, we can experiment with +kneecapping these legacy flow control Tor clients by setting a low +'circwindow' consensus parameter for them. This will allow us to set more +reasonable parameter values, without waiting for all clients to upgrade. Because custom congestion control can be deployed by any Exit or onion service that desires better service, we will need to be particularly @@ -768,7 +798,14 @@ implementations that more aggressively increase their window sizes. During these adversarial-style experiments, we must verify that cheaters do not get better service, and that Tor's circuit OOM killer properly closes circuits that seriously abuse the congestion control algorithm, -as per [SECURITY_ANALYSIS]. +as per [SECURITY_ANALYSIS]. This may requiring tuning CircuitEWMAHalfLife, +as well as the oomkiller cutoffs. + +Additionally, we will need to experiment with reducing the cell queue +limits on OR conns before they are blocked, and study the interaction +of that with treating the or conn block as a congestion signal. + + TODO: We should make that into a consensus parameter Finally, we should determine if the [BACKWARD_ECN] cell_t.command congestion signal is enough of an optimization to be worth the @@ -805,70 +842,224 @@ re-run these tuning experiments on the live Tor network, as described in: https://trac.torproject.org/projects/tor/wiki/org/roadmaps/CoreTor/Performa… -The following list is the complete set of network consensus parameters -referenced in this proposal, sorted roughly in order of importance (most -important to tune first): +6.5.1. Parameters common to all algorithms + +These are sorted in order of importance to tune, most important first. cc_alg: - Description: Specifies which congestion control algorithm clients should use, as an integer. - - Range: [0,2] (0=fixed, 1=Westwood, 2=Vegas) + - Range: [0,3] (0=fixed, 1=Westwood, 2=Vegas, 3=NOLA) - Default: 2 + - Tuning Values: 0-3 + - Tuning Notes: + These algorithms need to be tested against percentages of current + fixed alg client competition, in Shadow. Their optimal parameter + values, and even the optimal algorithm itself, will likely depend + upon how much fixed sendme traffic is in competition. See the + algorithm-specific parameters for additional tuning notes. + + cc_bwe_min: + - Description: + The minimum number of SENDME acks to average over in order to + estimate bandwidth (and thus BDP). + - Range: [2, 20] + - Default: 5 + - Tuning Values: 3-5 + - Tuning Notes: + The lower this value is, the sooner we can get an estimate of + the true BDP of a circuit. Low values may lead to massive + over-estimation, due to ack compression. - cwnd_recovery_m: - - Description: Specifies how much to reduce the congestion - window after a congestion signal, as a fraction of - 100. - - Range: [0, 100] - - Default: 70 + cc_icw: + - Description: Initial congestion window for new congestion + control Tor clients. This can be set much higher + than TCP, since actual TCP to the guard will prevent + buffer bloat issues at local routers. + - Range: [100, 10000] + - Default: 500 + - Tuning Values: 150,200,250,500 + - Tuning Notes: + Higher initial congestion windows allow the algorithms to + more accurately, but will lead to queue bursts and latency. + Ultimately, the ICW should be set to approximately + 'cc_bwe_min'*'cc_sendme_inc', but the presence of competing + fixed window clients may require higher values. + + cc_cwnd_min: + - Description: The minimum allowed cwnd. + - Range: [cc_sendme_inc, 1000] + - Tuning Values: [50, 100, 150] + - Tuning Notes: + If the cwnd falls below cc_sendme_inc, connections can't send + enough data to get any acks, and will stall. If it falls below + cc_bwe_min*cc_sendme_inc, connections can't use SENDME BDP + estimates. Likely we want to set this around + cc_bwe_min*cc_sendme_inc. circwindow: - Description: Initial congestion window for legacy Tor clients + - Range: [100, 1000] + - Default: 1000 + - Tuning Values: 100,200,500,1000 + - Tuning Notes: + If the above congestion algorithms are not optimal until an + unreasonably high percentge of clients upgrade, we can reduce + the performance of ossified legacy clients by reducing their + circuit windows. This will allow old clients to continue to + operate without impacting optimal network behavior. + + cc_cwnd_inc_rate: + - Description: How often we update our congestion window, per cwnd worth + of packets + - Range: [1, 250] + - Default: 1 + - Tuning Values: [1,2,5,10] + - Tuning Notes: + Congestion control theory says that the congestion window should + only be updated once every cwnd worth of packets. We may find it + better to update more frequently, but this is probably unlikely + to help a great deal. + + cc_ewma_cwnd_cnt: + - Description: This specifies the N in N-EWMA smoothing of RTT and BDP + estimation. It allows us to average these values over 1 + or more congestion windows. + - Range: [1, 100] + - Default: 2 + - Tuning Values: [1,2,3] + - Tuning Notes: + Smoothing our estimates reduces the effects of ack compression and + other ephemeral network hiccups; changing this much is unlikely + to have a huge impact on performance. + + cc_cwnd_inc: + - Description: How much to increment the congestion window by during + steady state, every cwnd. - Range: [1, 1000] - - Default: 1000 (reduced if legacy Tor clients compete unfairly) + - Default: 50 + - Tuning Values: 25,50,100 + - Tuning Notes: + We are unlikely to need to tune this much, but it might be worth + trying a couple values. + + cc_cwnd_inc_pct_ss: + - Description: Percentage of the current congestion window to increment + by during slow start, every cwnd. + - Range: [10, 300] + - Tuning Values: 50,100,200 + + cc_bdp_alg: + - Description: The BDP estimation algorithm to use. + - Range: [0,7] + - Default: 7 (Piecewise EWMA) + - Tuning Notes: + We don't expect to need to tune this. + + cc_sendme_inc: + - Description: Specifies how many cells a SENDME acks + - Range: [1, 5000] + - Default: 50 + - Tuning Notes: + We don't expect to need to tune this. - circwindow_cc: - - Description: Initial congestion window for new congestion - control Tor clients. This can be set much higher - than TCP, since actual TCP to the guard will prevent - buffer bloat issues at local routers. - - Range: [1, 10000] - - Default: 10-1000 +6.5.2. Westwood parameters - rtt_thresh: + cc_westwood_rtt_thresh: - Description: Specifies the cutoff for BOOTLEG_RTT_TOR to deliver congestion signal, as fixed point representation divided by 1000. - Range: [1, 1000] - - Default: 230 + - Default: 33 + - Tuning Values: [20, 33, 40, 50] + - Tuning Notes: + The Defenestrator paper set this at 23, but did not justify it. We + may need to raise it to compete with current fixed window SENDME. + + cc_westwood_cwnd_m: + - Description: Specifies how much to reduce the congestion + window after a congestion signal, as a fraction of + 100. + - Range: [0, 100] + - Default: 75 + - Tuning Values: [50, 66, 75] + - Tuning Notes: + Congestion control theory started out using 50 here, and then + decided 70-75 was better. + + cc_westwood_min_backoff: + - Description: If 1, take the min of BDP estimate and westwood backoff. + If 0, take the max of BDP estimate and westwood backoff. + - Range: [0, 1] + - Default: 0 + - Tuning Notes: + This parameter can make the westwood backoff less agressive, if + need be. We're unlikely to need it, though. + + cc_westwood_rtt_m: + - Description: Specifies a backoff percent of RTT_max, upon receipt of + a congestion signal. + - Range: [50, 100] + - Default: 100 + - Tuning Notes: + Westwood technically has a runaway condition where congestion can + cause RTT_max to grow, which increases the congestion threshhold. + This has not yet been observed, but because it is possible, we + include this parameter. - vegas_alpha - vegas_beta - vegas_gamma +6.5.3. Vegas Parameters + + + cc_vegas_alpha: + cc_vegas_beta: + cc_vegas_gamma: - Description: These parameters govern the number of cells that [TOR_VEGAS] can detect in queue before reacting. - Range: [1, 1000] - - Defaults: 6,12,12 - - circwindow_inc: - - Description: Specifies how many cells a SENDME acks - - Range: [1, 5000] + - Defaults: 6*cc_sendme_inc for gamma and beta; 3*cc_sendme_inc for alpha + - Tuning Notes: + The amount of queued cells that Vegas should tolerate is heavily + dependent upon competing congestion control algorithms. The specified + defaults are necessary to compete against current fixed SENDME traffic, + but are much larger than neccessary otherwise. As the number of + clients using fixed windows is reduced (or circwindow is lowered), we + can reduce these parameters, which will result in less overall queuing + and congestion on the network. + + cc_vegas_bdp_mix: + - Description: This parameter allows us to specify a weighted percent + average between the cwnd BDP estimator and the piecewise + estimator. + - Range: [0, 100] + - Default: 0 (use 100% Piecewise EWMA) + - Tuning Notes: + The original Vegas literature specified the CWND estimator, but + the Piecewise estimator is very likely more suited for our use + case. This parameter allows us to average them. We're unlikely to + need it. + +6.5.4. NOLA Parameters + + cc_nola_overshoot: + - Description: The number of cells to add to the BDP estimator to obtain + the NOLA cwnd. + - Range: [0, 1000] - Default: 100 + - Tuning Values: 0, 50, 100, 150, 200 + - Tuning Notes: + In order to compete against current fixed sendme, and to ensure + that the congestion window has an opportunity to grow, we must + set the cwnd above the current BDP estimate. How much above will + be a function of competing traffic. It may also turn out that + absent any more agressive competition, we do not need to overshoot + the BDP estimate. - min_queue_target: - - Description: How long in milliseconds can a cell spend in - a relay's queues before we declare its circuit congested? - - Range: [1, 10000] - - Default: 10 - queue_interval: - - Description: How long in milliseconds must cells exceed - 'min_queue_target' queue delay before we actually send a - congestion signal? - - Range: [1, 10000] - - Default: 200 +6.5.5. Flow Control Parameters + + TODO: These may expand, particularly to include cell_queue_highwater xoff_client xoff_mobile @@ -894,12 +1085,12 @@ important to tune first): 7.1. Circuit window handshake format TODO: We need to specify a way to communicate the currently seen - circwindow_inc consensus parameter to the other endpoint, + cc_sendme_inc consensus parameter to the other endpoint, due to consensus sync delay. Probably during the CREATE onionskin (and RELAY_COMMAND_EXTEND). TODO: We probably want stricter rules on the range of values for the per-circuit negotiation - something like - it has to be between [circwindow_inc/2, 2*circwindow_inc]. + it has to be between [cc_sendme_inc/2, 2*cc_sendme_inc]. That way, we can limit weird per-circuit values, but still allow us to change the consensus value in increments. @@ -1137,3 +1328,9 @@ as well as review of our versions of the algorithms. 25. Tor Performance Metrics for Live Network Tuning https://trac.torproject.org/projects/tor/wiki/org/roadmaps/CoreTor/Performa… + +26. Bandwidth-Delay Product + https://en.wikipedia.org/wiki/Bandwidth-delay_product + +27. Exponentially Weighted Moving Average + https://corporatefinanceinstitute.com/resources/knowledge/trading-investing…

1 0

[torspec/main] Prop 324: Describe clock jump and stall heuristics.
by nickm＠torproject.org 30 Aug '21

30 Aug '21

commit baa504ea8f54fd7d3da1ece073843e672bf00a00 Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Wed Jul 28 01:17:11 2021 +0000 Prop 324: Describe clock jump and stall heuristics. --- proposals/324-rtt-congestion-control.txt | 42 +++++++++++++++++++++++++++++++- 1 file changed, 41 insertions(+), 1 deletion(-) diff --git a/proposals/324-rtt-congestion-control.txt b/proposals/324-rtt-congestion-control.txt index dddd362..b7d827e 100644 --- a/proposals/324-rtt-congestion-control.txt +++ b/proposals/324-rtt-congestion-control.txt @@ -128,6 +128,29 @@ Circuits will also record the minimum and maximum RTT seen so far. Algorithms that make use of this RTT measurement for congestion window update are specified in [CONTROL_ALGORITHMS]. +2.1.1. Clock Jump Heuristics [CLOCK_HEURISTICS] + +The timestamps for RTT (and BDP) are measured using Tor's +monotime_absolute_usec() API. This API is designed to provide a monotonic +clock that only moves forward. However, depending on the underlying system +clock, this may result in the same timestamp value being returned for long +periods of time, which would result in RTT 0-values. Alternatively, the clock +may jump forward, resulting in abnormally large RTT values. + +To guard against this, we perform a series of heuristic checks on the time delta +measured by the RTT estimator, and if these heurtics detect a stall or a jump, +we do not use that value to update RTT or BDP, nor do we update any congestion +control algorithm information that round. + +If the time delta is 0, that is always treated as a clock stall. + +If we have measured at least 'cc_bwe_min' RTT values or we have successfully +exited slow start, then every sendme ACK, the new candidate RTT is compared to +the stored EWMA RTT. If the new RTT is either 100 times larger than the EWMA +RTT, or 100 times smaller than the stored EWMA RTT, then we do not record that +estimate, and do not update BDP or the congestion control algorithms for that +SENDME ack. + 2.2. SENDME behavior changes We will make four major changes to SENDME behavior to aid in computing @@ -320,7 +343,8 @@ truncation, we compute the BDP using multiplication first: Note that the SENDME BDP estimation will only work after two (2) SENDME acks have been received. Additionally, it tends not to be stable unless at least five (5) num_sendme's are used, due to ack compression. This is controlled by -the 'cc_bwe_min' consensus parameter. +the 'cc_bwe_min' consensus parameter. Finally, if [CLOCK_HEURISTICS] have +detected a clock jump or stall, this estimator is not updated. If all edge connections no longer have data available to send on a circuit and all circuit queues have drained without blocking the local orconn, we stop @@ -430,6 +454,11 @@ each time we get a SENDME (aka sendme_process_circuit_level()): if next_cc_event: next_cc_event-- + # Do not update anything if we detected a clock stall or jump, + # as per [CLOCK_HEURISTICS] + if clock_stalled_or_jumped: + return + if next_cc_event == 0: # BOOTLEG_RTT_TOR threshold; can also be BACKWARD_ECN check: if (RTT_current < @@ -497,6 +526,11 @@ ack: if next_cc_event: next_cc_event-- + # Do not update anything if we detected a clock stall or jump, + # as per [CLOCK_HEURISTICS] + if clock_stalled_or_jumped: + return + if next_cc_event == 0: if BDP > cwnd: queue_use = 0 @@ -535,6 +569,12 @@ and scores of others. What's up with that? Here's the pseudocode for TOR_NOLA that runs on every SENDME ack: + # Do not update anything if we detected a clock stall or jump, + # as per [CLOCK_HEURISTICS] + if clock_stalled_or_jumped: + return + + # If the orconn is blocked, do not overshoot BDP if orconn_blocked: cwnd = BDP else:

1 0

[torspec/main] Prop 324: Rename cc_icw to cc_cwnd_init
by nickm＠torproject.org 30 Aug '21

30 Aug '21

commit 532bec055175b626a0b200aeeb24e57bbeb4e78e Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Thu Jul 29 17:02:32 2021 +0000 Prop 324: Rename cc_icw to cc_cwnd_init --- proposals/324-rtt-congestion-control.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/proposals/324-rtt-congestion-control.txt b/proposals/324-rtt-congestion-control.txt index b7d827e..25118a4 100644 --- a/proposals/324-rtt-congestion-control.txt +++ b/proposals/324-rtt-congestion-control.txt @@ -228,8 +228,8 @@ network traffic. This experimentation and tuning is detailed in section All of these algorithms have rules to update 'cwnd' - the current congestion window, which starts out at a value controlled by consensus parameter -'cc_icw'. The algorithms also keep track of 'inflight', which is a count of -the number of cells currently not yet acked by a SENDME. The algorithm MUST +'cc_cwnd_init'. The algorithms also keep track of 'inflight', which is a count +of the number of cells currently not yet acked by a SENDME. The algorithm MUST ensure that cells cease being sent if 'cwnd - inflight <= 0'. Note that this value CAN become negative in the case where the cwnd is reduced while packets are inflight. @@ -922,7 +922,7 @@ These are sorted in order of importance to tune, most important first. The lower this value is, the sooner we can get an estimate of the true BDP of a circuit. Low values may lead to massive over-estimation, due to ack compression. However, if this - value is above the number of acks that fit in cc_icw, then + value is above the number of acks that fit in cc_cwnd_init, then we won't get a BDP estimate within the first use of the circuit. Additionally, if this value is above the number of acks that fit in cc_cwnd_min, we may not be able to estimate BDP @@ -942,7 +942,7 @@ These are sorted in order of importance to tune, most important first. 100, we can set this as low as 33 to have the same amount of overhead. - cc_icw: + cc_cwnd_init: - Description: Initial congestion window for new congestion control Tor clients. This can be set much higher than TCP, since actual TCP to the guard will prevent

1 0

[torspec/main] Prop 324: Fix fencepost error in SENDME BDP calculation
by nickm＠torproject.org 30 Aug '21

30 Aug '21

commit 481bcc74de14ef62ade8ad3cd229cde6992a49c6 Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Fri Jul 30 13:45:02 2021 +0000 Prop 324: Fix fencepost error in SENDME BDP calculation --- proposals/324-rtt-congestion-control.txt | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/proposals/324-rtt-congestion-control.txt b/proposals/324-rtt-congestion-control.txt index 25118a4..f98c28a 100644 --- a/proposals/324-rtt-congestion-control.txt +++ b/proposals/324-rtt-congestion-control.txt @@ -332,13 +332,19 @@ timestamps. With this, the calculation becomes: - BWE = num_sendmes * cc_sendme_inc / num_sendme_timestamp_delta + BWE = (num_sendmes-1) * cc_sendme_inc / num_sendme_timestamp_delta BDP = BWE * RTT_min -However, because the timestamps are microseconds, to avoid integer +Note that because we are counting the number of cells *between* the first +and last sendme of the congestion window, we must subtract 1 from the number +of sendmes actually recieved. Over the time period between the first and last +sendme of the congestion window, the other endpoint successfully read +(num_sendmes-1) * cc_sendme_inc cells. + +Furthermore, because the timestamps are microseconds, to avoid integer truncation, we compute the BDP using multiplication first: - BDP = num_sendmes * cc_sendme_inc * RTT_min / num_sendme_timestamp_delta + BDP = (num_sendmes-1) * cc_sendme_inc * RTT_min / num_sendme_timestamp_delta Note that the SENDME BDP estimation will only work after two (2) SENDME acks have been received. Additionally, it tends not to be stable unless at least

1 0

[torspec/main] Merge branch 'tor-gitlab/mr/38'
by nickm＠torproject.org 30 Aug '21

30 Aug '21

commit b244dd33a525e3c81aa8679cda128226dcd9d6fa Merge: df6af4f 481bcc7 Author: David Goulet <dgoulet(a)torproject.org> Date: Fri Jul 30 13:27:25 2021 -0400 Merge branch 'tor-gitlab/mr/38' proposals/324-rtt-congestion-control.txt | 890 ++++++++++++++++++++----------- 1 file changed, 580 insertions(+), 310 deletions(-)

1 0