February 2022 - tor-commits - lists.torproject.org

[translation/communitytpo-contentspot] new translations in communitytpo-contentspot
by translation＠torproject.org 24 Feb '22

24 Feb '22

commit 7a500eefb7fca832feb6299b11e2252a9a322728 Author: Translation commit bot <translation(a)torproject.org> Date: Thu Feb 24 15:00:54 2022 +0000 new translations in communitytpo-contentspot --- contents+ar.po | 4 +- contents+bn.po | 4 +- contents+de.po | 15 ++++++- contents+el.po | 4 +- contents+id.po | 4 +- contents+ja.po | 4 +- contents+kk.po | 4 +- contents+km.po | 11 ++--- contents+pt-BR.po | 6 +-- contents+ru.po | 120 ++++++++++++++++++++++++++++++++++++------------------ 10 files changed, 114 insertions(+), 62 deletions(-) diff --git a/contents+ar.po b/contents+ar.po index 236ce2b857..c95435ab2f 100644 --- a/contents+ar.po +++ b/contents+ar.po @@ -17,8 +17,8 @@ # erinm, 2022 # Ilyes Chouia <celyes02(a)gmail.com>, 2022 # Layla Taha <layla(a)asl19.org>, 2022 -# Transifex Bot <>, 2022 # Emma Peel, 2022 +# Transifex Bot <>, 2022 # msgid "" msgstr "" @@ -26,7 +26,7 @@ msgstr "" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2022-02-15 20:14+UTC\n" "PO-Revision-Date: 2019-12-11 10:50+0000\n" -"Last-Translator: Emma Peel, 2022\n" +"Last-Translator: Transifex Bot <>, 2022\n" "Language-Team: Arabic (https://www.transifex.com/otf/teams/1519/ar/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" diff --git a/contents+bn.po b/contents+bn.po index 70f3b1f7be..2bddcdf2ab 100644 --- a/contents+bn.po +++ b/contents+bn.po @@ -8,8 +8,8 @@ # Al Shahrior Hasan Sagor <shahrior3814(a)gmail.com>, 2021 # erinm, 2022 # Emma Peel, 2022 -# Transifex Bot <>, 2022 # Foxom Toto <foxomot957(a)coalamails.com>, 2022 +# Transifex Bot <>, 2022 # msgid "" msgstr "" @@ -17,7 +17,7 @@ msgstr "" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2022-02-15 20:14+UTC\n" "PO-Revision-Date: 2019-12-11 10:50+0000\n" -"Last-Translator: Foxom Toto <foxomot957(a)coalamails.com>, 2022\n" +"Last-Translator: Transifex Bot <>, 2022\n" "Language-Team: Bengali (https://www.transifex.com/otf/teams/1519/bn/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" diff --git a/contents+de.po b/contents+de.po index 2222d3afc6..11ee73d5ea 100644 --- a/contents+de.po +++ b/contents+de.po @@ -25,6 +25,7 @@ # Curtis Baltimore <curtisbaltimore(a)protonmail.com>, 2022 # Transifex Bot <>, 2022 # Emma Peel, 2022 +# jarl, 2022 # msgid "" msgstr "" @@ -32,7 +33,7 @@ msgstr "" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2022-02-15 20:14+UTC\n" "PO-Revision-Date: 2019-12-11 10:50+0000\n" -"Last-Translator: Emma Peel, 2022\n" +"Last-Translator: jarl, 2022\n" "Language-Team: German (https://www.transifex.com/otf/teams/1519/de/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -9744,7 +9745,7 @@ msgstr "Hier sind ein paar Tipps:" #: https//community.torproject.org/onion-services/advanced/dos/ #: (content/onion-services/advanced/dos/contents+en.lrpage.body) msgid "### Configuration parameters" -msgstr "" +msgstr "### Konfigurationsparameter" #: https//community.torproject.org/onion-services/advanced/dos/ #: (content/onion-services/advanced/dos/contents+en.lrpage.body) @@ -9754,6 +9755,11 @@ msgid "" "intro-dos-defense-extention.txt) was implemented, some `torrc` options were " "added to help mitigating DoS attacks at the introduction points:" msgstr "" +"Seit [Proposal " +"305](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/3…" +"intro-dos-defense-extention.txt) implementiert wurde, wurden einige 'torrc' " +"Optionen hinzugefügt um dabei zu helfen, DoS-Attacken am Einstiegspunkt " +"abzumildern." #: https//community.torproject.org/onion-services/advanced/dos/ #: (content/onion-services/advanced/dos/contents+en.lrpage.body) @@ -9761,6 +9767,8 @@ msgid "" "* `HiddenServiceEnableIntroDoSDefense`: Enable DoS defense at the intropoint" " level." msgstr "" +"* `HiddenServiceEnableIntroDoSDefense`: Aktiviert Verteidigung gegen DoS-" +"Attacken am Einstiegspunkt." #: https//community.torproject.org/onion-services/advanced/dos/ #: (content/onion-services/advanced/dos/contents+en.lrpage.body) @@ -9769,6 +9777,9 @@ msgid "" " point which will then use them to apply rate limiting for introduction " "request to this service." msgstr "" +"Wenn dies aktiviert ist werden die rate und burst Parameter an den " +"Einstiegspunkt gesendet, welcher diese nutzt um die Rate der " +"Bekanntmachungsanfragen zu begrenzen." #: https//community.torproject.org/onion-services/advanced/dos/ #: (content/onion-services/advanced/dos/contents+en.lrpage.body) diff --git a/contents+el.po b/contents+el.po index 42ef4461e7..76b707e040 100644 --- a/contents+el.po +++ b/contents+el.po @@ -8,9 +8,9 @@ # Dimitris Adamakis <gt.dimitris(a)gmail.com>, 2021 # Elektra M. <safiragon(a)yahoo.gr>, 2021 # erinm, 2022 -# Transifex Bot <>, 2022 # george k <norhorn(a)gmail.com>, 2022 # Emma Peel, 2022 +# Transifex Bot <>, 2022 # msgid "" msgstr "" @@ -18,7 +18,7 @@ msgstr "" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2022-02-15 20:14+UTC\n" "PO-Revision-Date: 2019-12-11 10:50+0000\n" -"Last-Translator: Emma Peel, 2022\n" +"Last-Translator: Transifex Bot <>, 2022\n" "Language-Team: Greek (https://www.transifex.com/otf/teams/1519/el/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" diff --git a/contents+id.po b/contents+id.po index 56a50e5c5b..919f4c2c45 100644 --- a/contents+id.po +++ b/contents+id.po @@ -19,8 +19,8 @@ # Andre Julian <andrejulian30(a)gmail.com>, 2022 # erinm, 2022 # Dewie Ang, 2022 -# Transifex Bot <>, 2022 # Emma Peel, 2022 +# Transifex Bot <>, 2022 # msgid "" msgstr "" @@ -28,7 +28,7 @@ msgstr "" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2022-02-15 20:14+UTC\n" "PO-Revision-Date: 2019-12-11 10:50+0000\n" -"Last-Translator: Emma Peel, 2022\n" +"Last-Translator: Transifex Bot <>, 2022\n" "Language-Team: Indonesian (https://www.transifex.com/otf/teams/1519/id/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" diff --git a/contents+ja.po b/contents+ja.po index 7915f1258c..60cf43149d 100644 --- a/contents+ja.po +++ b/contents+ja.po @@ -17,8 +17,8 @@ # Emma Peel, 2022 # erinm, 2022 # h345u37g3 h345u37g3, 2022 -# Transifex Bot <>, 2022 # Ito Takeshi, 2022 +# Transifex Bot <>, 2022 # msgid "" msgstr "" @@ -26,7 +26,7 @@ msgstr "" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2022-02-15 20:14+UTC\n" "PO-Revision-Date: 2019-12-11 10:50+0000\n" -"Last-Translator: Ito Takeshi, 2022\n" +"Last-Translator: Transifex Bot <>, 2022\n" "Language-Team: Japanese (https://www.transifex.com/otf/teams/1519/ja/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" diff --git a/contents+kk.po b/contents+kk.po index d9693f0171..dd6fe0019f 100644 --- a/contents+kk.po +++ b/contents+kk.po @@ -3,8 +3,8 @@ # Baurzhan Muftakhidinov <baurthefirst(a)gmail.com>, 2021 # Zangar Batyrkhan <zangar.kazakh(a)gmail.com>, 2021 # erinm, 2021 -# Transifex Bot <>, 2022 # Dimash Esen <esengeldi0202(a)gmail.com>, 2022 +# Transifex Bot <>, 2022 # msgid "" msgstr "" @@ -12,7 +12,7 @@ msgstr "" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2022-02-15 20:14+UTC\n" "PO-Revision-Date: 2019-12-11 10:50+0000\n" -"Last-Translator: Dimash Esen <esengeldi0202(a)gmail.com>, 2022\n" +"Last-Translator: Transifex Bot <>, 2022\n" "Language-Team: Kazakh (https://www.transifex.com/otf/teams/1519/kk/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" diff --git a/contents+km.po b/contents+km.po index 61c558e3e2..f42bdefed8 100644 --- a/contents+km.po +++ b/contents+km.po @@ -2,14 +2,15 @@ # Translators: # Seavmeng Samoeurth <seavmengs(a)silaka.org>, 2021 # Ty Sok <sokty2(a)gmail.com>, 2021 -# Moses Ngeth, 2021 # erinm, 2022 # Sokhem Khoem <sokhem(a)open.org.kh>, 2022 # Chanphosda Prak <chanphosda.prak(a)gmail.com>, 2022 # Piseth KONG <pisethk(a)gmail.com>, 2022 -# Transifex Bot <>, 2022 # Vannak Lach, 2022 # Emma Peel, 2022 +# Moses Ngeth, 2022 +# Cantaloupe Melon, 2022 +# Transifex Bot <>, 2022 # msgid "" msgstr "" @@ -17,7 +18,7 @@ msgstr "" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2022-02-15 20:14+UTC\n" "PO-Revision-Date: 2019-12-11 10:50+0000\n" -"Last-Translator: Emma Peel, 2022\n" +"Last-Translator: Transifex Bot <>, 2022\n" "Language-Team: Khmer (https://www.transifex.com/otf/teams/1519/km/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -21429,8 +21430,8 @@ msgstr "" #: templates/outreach-talk.html:77 templates/two-columns-page.html:30 msgid "Back to previous page: " -msgstr "" +msgstr "ត្រឡប់ទៅទំព័រមុន៖" #: templates/macros/projects.html:20 msgid "Read more." -msgstr "" +msgstr "អានបន្ថែម" diff --git a/contents+pt-BR.po b/contents+pt-BR.po index 42656bf020..160f690fb9 100644 --- a/contents+pt-BR.po +++ b/contents+pt-BR.po @@ -28,10 +28,10 @@ # ufa <ufa(a)technotroll.org>, 2022 # erinm, 2022 # Communia <ameaneantie(a)riseup.net>, 2022 -# Billy Bill, 2022 +# billy bill, 2022 # Emma Peel, 2022 -# Transifex Bot <>, 2022 # Silvio Rhatto, 2022 +# Transifex Bot <>, 2022 # msgid "" msgstr "" @@ -39,7 +39,7 @@ msgstr "" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2022-02-15 20:14+UTC\n" "PO-Revision-Date: 2019-12-11 10:50+0000\n" -"Last-Translator: Silvio Rhatto, 2022\n" +"Last-Translator: Transifex Bot <>, 2022\n" "Language-Team: Portuguese (Brazil) (https://www.transifex.com/otf/teams/1519/pt_BR/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" diff --git a/contents+ru.po b/contents+ru.po index 176fbc4f87..f864048fa4 100644 --- a/contents+ru.po +++ b/contents+ru.po @@ -18,9 +18,9 @@ # ktchr, 2021 # T9 T9, 2022 # erinm, 2022 -# Emma Peel, 2022 -# Transifex Bot <>, 2022 # Sergey Smirnov <cj75300(a)gmail.com>, 2022 +# Transifex Bot <>, 2022 +# Emma Peel, 2022 # msgid "" msgstr "" @@ -28,7 +28,7 @@ msgstr "" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2022-02-15 20:14+UTC\n" "PO-Revision-Date: 2019-12-11 10:50+0000\n" -"Last-Translator: Sergey Smirnov <cj75300(a)gmail.com>, 2022\n" +"Last-Translator: Emma Peel, 2022\n" "Language-Team: Russian (https://www.transifex.com/otf/teams/1519/ru/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -4102,7 +4102,7 @@ msgstr "" #: https//community.torproject.org/relay/setup/guard/ #: (content/relay/setup/guard/contents+en.lrpage.section) msgid "relay operations" -msgstr "" +msgstr "Действия с узлами" #: https//community.torproject.org/relay/setup/ #: (content/relay/setup/contents+en.lrpage.body) @@ -4259,14 +4259,14 @@ msgstr "" msgid "" "A guard relay is the first relay in the chain of 3 relays building a Tor " "circuit." -msgstr "" +msgstr "Сторожевой узел – первый в цепочке трёх узлов Tor." #: https//community.torproject.org/relay/types-of-relays/ #: (content/relay/types-of-relays/contents+en.lrpage.body) msgid "" "A middle relay is neither a guard nor an exit, but acts as the second hop " "between the two." -msgstr "" +msgstr "Промежуточный узел – не сторожевой и не выходной, а между ними." #: https//community.torproject.org/relay/types-of-relays/ #: (content/relay/types-of-relays/contents+en.lrpage.body) @@ -4326,7 +4326,7 @@ msgstr "" #: https//community.torproject.org/relay/types-of-relays/ #: (content/relay/types-of-relays/contents+en.lrpage.body) msgid "# Exit relay" -msgstr "" +msgstr "# Выходной узел" #: https//community.torproject.org/relay/types-of-relays/ #: (content/relay/types-of-relays/contents+en.lrpage.body) @@ -17244,7 +17244,7 @@ msgstr "" #: https//community.torproject.org/relay/setup/bridge/fedora/ #: (content/relay/setup/bridge/fedora/contents+en.lrpage.body) msgid "### 3. Install `tor`" -msgstr "" +msgstr "### 3. Установите `tor`" #: https//community.torproject.org/relay/setup/bridge/fedora/ #: (content/relay/setup/bridge/fedora/contents+en.lrpage.body) @@ -17374,7 +17374,7 @@ msgid "" "externally" msgstr "" "# Замените \"TODO1\" портом Tor по своему выбору. Этот порт должен быть " -"доступен" +"доступен." #: https//community.torproject.org/relay/setup/bridge/fedora/ #: (content/relay/setup/bridge/fedora/contents+en.lrpage.body) @@ -17390,7 +17390,7 @@ msgstr "" #: (content/relay/setup/bridge/freebsd/contents+en.lrpage.body) msgid "" "# reachable. Avoid port 9001 because it's commonly associated with Tor and" -msgstr "" +msgstr "# Избегайте порта 9001. Он обычно ассоциируется с Tor. Цензоры" #: https//community.torproject.org/relay/setup/bridge/fedora/ #: (content/relay/setup/bridge/fedora/contents+en.lrpage.body) @@ -17405,7 +17405,7 @@ msgstr "" #: https//community.torproject.org/relay/setup/bridge/freebsd/ #: (content/relay/setup/bridge/freebsd/contents+en.lrpage.body) msgid "# censors may be scanning the Internet for this port." -msgstr "" +msgstr "могут знать об этом, просматривая Интернет." #: https//community.torproject.org/relay/setup/bridge/fedora/ #: (content/relay/setup/bridge/fedora/contents+en.lrpage.body) @@ -17456,7 +17456,7 @@ msgstr "ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy" #: https//community.torproject.org/relay/setup/bridge/freebsd/ #: (content/relay/setup/bridge/freebsd/contents+en.lrpage.body) msgid "# Replace \"TODO2\" with an obfs4 port of your choice. This port must be" -msgstr "" +msgstr "# Замените \"TODO2\" портом obfs4 по своему выбору. Этот порт должен быть" #: https//community.torproject.org/relay/setup/bridge/fedora/ #: (content/relay/setup/bridge/fedora/contents+en.lrpage.body) @@ -17488,7 +17488,7 @@ msgstr "# доступен извне и отличаться от порта OR #: https//community.torproject.org/relay/setup/bridge/freebsd/ #: (content/relay/setup/bridge/freebsd/contents+en.lrpage.body) msgid "# Avoid port 9001 because it's commonly associated with" -msgstr "" +msgstr "# Избегайте порта 9001. Он обычно ассоциируется с Tor." #: https//community.torproject.org/relay/setup/bridge/fedora/ #: (content/relay/setup/bridge/fedora/contents+en.lrpage.body) @@ -17503,7 +17503,7 @@ msgstr "" #: https//community.torproject.org/relay/setup/bridge/freebsd/ #: (content/relay/setup/bridge/freebsd/contents+en.lrpage.body) msgid "# Tor and censors may be scanning the Internet for this port." -msgstr "" +msgstr "# Цензоры могут знать об этом, просматривая Интернет." #: https//community.torproject.org/relay/setup/bridge/fedora/ #: (content/relay/setup/bridge/fedora/contents+en.lrpage.body) @@ -17573,6 +17573,8 @@ msgstr "" #: (content/relay/setup/bridge/freebsd/contents+en.lrpage.body) msgid "# \"Ext\" means \"extended\", not \"external\". Don't try to set a specific port" msgstr "" +"# \"Ext\" значит \"расширенный\", а не \"внешний\". Не пытайтесь установить " +"конкретный" #: https//community.torproject.org/relay/setup/bridge/fedora/ #: (content/relay/setup/bridge/fedora/contents+en.lrpage.body) @@ -17587,7 +17589,7 @@ msgstr "" #: https//community.torproject.org/relay/setup/bridge/freebsd/ #: (content/relay/setup/bridge/freebsd/contents+en.lrpage.body) msgid "# number, nor listen on 0.0.0.0." -msgstr "" +msgstr "# номер порта или слушать 0.0.0.0." #: https//community.torproject.org/relay/setup/bridge/fedora/ #: (content/relay/setup/bridge/fedora/contents+en.lrpage.body) @@ -17630,6 +17632,8 @@ msgid "" "# Replace \"<address(a)email.com>\" with your email address so we can contact " "you if" msgstr "" +"# Замените \"<address(a)email.com>\" вашим адресом email, чтобы мы могли " +"связаться с вами" #: https//community.torproject.org/relay/setup/bridge/fedora/ #: (content/relay/setup/bridge/fedora/contents+en.lrpage.body) @@ -17645,7 +17649,7 @@ msgstr "" #: (content/relay/setup/bridge/freebsd/contents+en.lrpage.body) msgid "" "# there are problems with your bridge. This is optional but encouraged." -msgstr "" +msgstr "# в случае проблем с вашим мостом. Это необязательно, но желательно." #: https//community.torproject.org/relay/setup/bridge/fedora/ #: (content/relay/setup/bridge/fedora/contents+en.lrpage.body) @@ -17746,6 +17750,8 @@ msgid "" "Don't forget to change the `ORPort`, `ServerTransportListenAddr`, " "`ContactInfo`, and `Nickname` options." msgstr "" +"Не забудьте изменить опции `ORPort`, `ServerTransportListenAddr`, " +"`ContactInfo` и `Nickname`." #: https//community.torproject.org/relay/setup/bridge/fedora/ #: (content/relay/setup/bridge/fedora/contents+en.lrpage.body) @@ -17797,7 +17803,7 @@ msgstr "# systemctl enable --now tor" #: https//community.torproject.org/relay/setup/bridge/voidlinux/ #: (content/relay/setup/bridge/voidlinux/contents+en.lrpage.body) msgid "### 6. Monitor your logs" -msgstr "" +msgstr "### 6. Следите за логами" #: https//community.torproject.org/relay/setup/bridge/fedora/ #: (content/relay/setup/bridge/fedora/contents+en.lrpage.body) @@ -17815,6 +17821,8 @@ msgid "" "To confirm your bridge is running with no issues, you should see something " "like this (usually in `/var/log/tor/log` or `/var/log/syslog`):" msgstr "" +"Доказательством того, что ваш мост работает без проблем, служит примерно " +"такая запись (обычно в `/var/log/tor/log` или `/var/log/syslog`):" #: https//community.torproject.org/relay/setup/bridge/fedora/ #: (content/relay/setup/bridge/fedora/contents+en.lrpage.body) @@ -17840,6 +17848,8 @@ msgid "" "[notice] Your Tor server's identity key fingerprint is '<NICKNAME> " "<FINGERPRINT>'" msgstr "" +"[notice] Your Tor server's identity key fingerprint is '<NICKNAME> " +"<FINGERPRINT>'" #: https//community.torproject.org/relay/setup/bridge/fedora/ #: (content/relay/setup/bridge/fedora/contents+en.lrpage.body) @@ -17965,6 +17975,8 @@ msgid "" "[notice] Now checking whether ORPort <redacted>:3818 is reachable... (this " "may take up to 20 minutes -- look for log messages indicating success)" msgstr "" +"[notice] Now checking whether ORPort <redacted>:3818 is reachable... (this " +"may take up to 20 minutes -- look for log messages indicating success)" #: https//community.torproject.org/relay/setup/bridge/fedora/ #: (content/relay/setup/bridge/fedora/contents+en.lrpage.body) @@ -18004,7 +18016,7 @@ msgstr "" #: https//community.torproject.org/relay/setup/guard/freebsd/ #: (content/relay/setup/guard/freebsd/contents+en.lrpage.body) msgid "### 7. Final Notes" -msgstr "" +msgstr "### 7. В завершение" #: https//community.torproject.org/relay/setup/bridge/fedora/ #: (content/relay/setup/bridge/fedora/contents+en.lrpage.body) @@ -18038,6 +18050,8 @@ msgid "" "If you are having trouble setting up your bridge, have a look at [our help " "section](../../../getting-help/)." msgstr "" +"Если у вас проблемы с настройкой моста, обратите внимание на наш [раздел " +"помощи](../../../getting-help/)." #: https//community.torproject.org/relay/setup/bridge/fedora/ #: (content/relay/setup/bridge/fedora/contents+en.lrpage.body) @@ -18067,6 +18081,8 @@ msgid "" "If your bridge is now running, check out the [post-install notes](../post-" "install/)." msgstr "" +"Если ваш мост работает прямо сейчас, загляните в [примечания после " +"установки](../post-install/)." #: https//community.torproject.org/relay/setup/bridge/openbsd/ #: (content/relay/setup/bridge/openbsd/contents+en.lrpage.subtitle) @@ -18301,7 +18317,7 @@ msgstr "# rcctl start tor" #: https//community.torproject.org/relay/setup/bridge/openbsd/ #: (content/relay/setup/bridge/openbsd/contents+en.lrpage.body) msgid "### 7. Monitor your logs (usually in your syslog)" -msgstr "" +msgstr "### 7. Следите за логами (обычно в вашем syslog)" #: https//community.torproject.org/relay/setup/bridge/openbsd/ #: (content/relay/setup/bridge/openbsd/contents+en.lrpage.body) @@ -18311,6 +18327,8 @@ msgid "" "To confirm your bridge is running with no issues, you should see something " "like this:" msgstr "" +"Доказательством того, что ваш мост работает без проблем, служит примерно " +"такая запись:" #: https//community.torproject.org/relay/setup/bridge/openbsd/ #: (content/relay/setup/bridge/openbsd/contents+en.lrpage.body) @@ -18321,7 +18339,7 @@ msgstr "" #: https//community.torproject.org/relay/setup/bridge/dragonflybsd/ #: (content/relay/setup/bridge/dragonflybsd/contents+en.lrpage.body) msgid "### 8. Final Notes" -msgstr "" +msgstr "### 8. В завершение" #: https//community.torproject.org/relay/setup/bridge/windows/ #: (content/relay/setup/bridge/windows/contents+en.lrpage.subtitle) @@ -18616,7 +18634,7 @@ msgstr "" #: https//community.torproject.org/relay/setup/bridge/windows/ #: (content/relay/setup/bridge/windows/contents+en.lrpage.body) msgid "### 5. Monitor your logs" -msgstr "" +msgstr "### 5. Следите за логами" #: https//community.torproject.org/relay/setup/bridge/windows/ #: (content/relay/setup/bridge/windows/contents+en.lrpage.body) @@ -18624,11 +18642,13 @@ msgid "" "To confirm your bridge is running with no issues, you should see something " "like this in `C:\\Users\\<user>\\AppData\\Roaming\\tor\\notice.log`." msgstr "" +"Доказательством того, что ваш мост работает без проблем, служит примерно " +"такая запись в `C:\\Users\\<user>\\AppData\\Roaming\\tor\\notice.log`." #: https//community.torproject.org/relay/setup/bridge/windows/ #: (content/relay/setup/bridge/windows/contents+en.lrpage.body) msgid "### 6. Final notes" -msgstr "" +msgstr "### 6. В завершение" #: https//community.torproject.org/relay/setup/bridge/windows/ #: (content/relay/setup/bridge/windows/contents+en.lrpage.body) @@ -18638,6 +18658,8 @@ msgid "" "If your bridge is now running, check out the [post-install " "notes](../../post-install/)." msgstr "" +"Если ваш мост работает прямо сейчас, загляните в [примечания после " +"установки](../../post-install/)." #: https//community.torproject.org/relay/setup/bridge/voidlinux/ #: (content/relay/setup/bridge/voidlinux/contents+en.lrpage.subtitle) @@ -18676,7 +18698,7 @@ msgstr "" #: https//community.torproject.org/relay/setup/guard/archlinux/ #: (content/relay/setup/guard/archlinux/contents+en.lrpage.body) msgid "### 2. Install `tor`" -msgstr "" +msgstr "### 2. Установите `tor`" #: https//community.torproject.org/relay/setup/bridge/voidlinux/ #: (content/relay/setup/bridge/voidlinux/contents+en.lrpage.body) @@ -18684,7 +18706,7 @@ msgid "" "To install the `tor` package on Void Linux, considering you are already on " "an up-to-date system:" msgstr "" -"Для установки пакета `tor` в Void Linux, убедитесь, что ваша система " +"Для установки пакета `tor` в Void Linux убедитесь, что ваша система " "обновлена:" #: https//community.torproject.org/relay/setup/bridge/voidlinux/ @@ -18917,7 +18939,7 @@ msgstr "" #: https//community.torproject.org/relay/setup/bridge/docker/ #: (content/relay/setup/bridge/docker/contents+en.lrpage.body) msgid "### 3. Monitor your logs" -msgstr "" +msgstr "### 3. Следите за логами" #: https//community.torproject.org/relay/setup/bridge/docker/ #: (content/relay/setup/bridge/docker/contents+en.lrpage.body) @@ -19272,12 +19294,12 @@ msgstr "# service tor start" #: https//community.torproject.org/relay/setup/bridge/freebsd/ #: (content/relay/setup/bridge/freebsd/contents+en.lrpage.body) msgid "### 8. Monitor your logs" -msgstr "" +msgstr "### 8. Следите за логами" #: https//community.torproject.org/relay/setup/bridge/centos-rhel/ #: (content/relay/setup/bridge/centos-rhel/contents+en.lrpage.body) msgid "### 9 Final Notes" -msgstr "" +msgstr "### 9 В завершение" #: https//community.torproject.org/relay/setup/bridge/opensuse/ #: (content/relay/setup/bridge/opensuse/contents+en.lrpage.subtitle) @@ -19331,7 +19353,7 @@ msgstr "" #: https//community.torproject.org/relay/setup/bridge/opensuse/ #: (content/relay/setup/bridge/opensuse/contents+en.lrpage.body) msgid "### 6. Monitor your logs (usually in your syslog)" -msgstr "" +msgstr "### 6. Следите за логами (обычно в вашем syslog)" #: https//community.torproject.org/relay/setup/bridge/netbsd/ #: (content/relay/setup/bridge/netbsd/contents+en.lrpage.subtitle) @@ -19425,7 +19447,7 @@ msgstr "# /etc/rc.d/tor start" #: https//community.torproject.org/relay/setup/bridge/dragonflybsd/ #: (content/relay/setup/bridge/dragonflybsd/contents+en.lrpage.body) msgid "### 7. Monitor your logs" -msgstr "" +msgstr "### 7. Следите за логами" #: https//community.torproject.org/relay/setup/bridge/post-install/ #: (content/relay/setup/bridge/post-install/contents+en.lrpage.subtitle) @@ -19559,19 +19581,19 @@ msgstr "Как запустить мост obfs4 в Arch Linux" #: https//community.torproject.org/relay/setup/guard/archlinux/ #: (content/relay/setup/guard/archlinux/contents+en.lrpage.body) msgid "To install the `tor` package on Arch Linux, please run:" -msgstr "" +msgstr "Чтобы установить пакет `tor` в Arch Linux:" #: https//community.torproject.org/relay/setup/bridge/archlinux/ #: (content/relay/setup/bridge/archlinux/contents+en.lrpage.body) #: https//community.torproject.org/relay/setup/guard/archlinux/ #: (content/relay/setup/guard/archlinux/contents+en.lrpage.body) msgid "# pacman -Syu tor" -msgstr "" +msgstr "# pacman -Syu tor" #: https//community.torproject.org/relay/setup/bridge/archlinux/ #: (content/relay/setup/bridge/archlinux/contents+en.lrpage.body) msgid "### 3. Install a Pluggable Transport" -msgstr "" +msgstr "### 3. Установите подключаемый транспорт" #: https//community.torproject.org/relay/setup/bridge/archlinux/ #: (content/relay/setup/bridge/archlinux/contents+en.lrpage.body) @@ -19580,6 +19602,9 @@ msgid "" "install it, so we must either build and it from source, or use the AUR " "(ArchLinux User Repository)." msgstr "" +"К сожалению, в официальных репозиториях Arch Linux нет нужного пакета. " +"Поэтому придётся или собирать его из исходников, или использовать " +"репозиторий AUR (ArchLinux User Repository)." #: https//community.torproject.org/relay/setup/bridge/archlinux/ #: (content/relay/setup/bridge/archlinux/contents+en.lrpage.body) @@ -19588,26 +19613,29 @@ msgid "" "is how `obfs4proxy` can be installed on Arch Linux using an unprivileged " "user account with `sudo` permissions:" msgstr "" +"Если выбрали AUR, а `makepkg` запущен не с правами **суперпользователя**, то" +" установка `obfs4proxy` в обычном пользовательском аккаунте с правами `sudo`" +" выглядит так:" #: https//community.torproject.org/relay/setup/bridge/archlinux/ #: (content/relay/setup/bridge/archlinux/contents+en.lrpage.body) msgid "$ sudo pacman -Syu git" -msgstr "" +msgstr "$ sudo pacman -Syu git" #: https//community.torproject.org/relay/setup/bridge/archlinux/ #: (content/relay/setup/bridge/archlinux/contents+en.lrpage.body) msgid "$ git clone https://aur.archlinux.org/obfs4proxy" -msgstr "" +msgstr "$ git clone https://aur.archlinux.org/obfs4proxy" #: https//community.torproject.org/relay/setup/bridge/archlinux/ #: (content/relay/setup/bridge/archlinux/contents+en.lrpage.body) msgid "$ cd obfs4proxy" -msgstr "" +msgstr "$ cd obfs4proxy" #: https//community.torproject.org/relay/setup/bridge/archlinux/ #: (content/relay/setup/bridge/archlinux/contents+en.lrpage.body) msgid "$ makepkg -irs" -msgstr "" +msgstr "$ makepkg -irs" #: https//community.torproject.org/relay/setup/bridge/archlinux/ #: (content/relay/setup/bridge/archlinux/contents+en.lrpage.body) @@ -19615,6 +19643,8 @@ msgid "" "* **DISCLAIMER:** _AUR_ packages are user produced content. Any use of the " "provided files is at your own risk." msgstr "" +"* **ВНИМАНИЕ.** Пакеты в репозиториях _AUR_ подготовлены самими " +"пользователями. Используйте их на свой страх и риск." #: https//community.torproject.org/relay/setup/bridge/archlinux/ #: (content/relay/setup/bridge/archlinux/contents+en.lrpage.body) @@ -19634,12 +19664,12 @@ msgstr "" #: https//community.torproject.org/relay/setup/guard/archlinux/ #: (content/relay/setup/guard/archlinux/contents+en.lrpage.body) msgid "DataDirectory /var/lib/tor" -msgstr "" +msgstr "DataDirectory /var/lib/tor" #: https//community.torproject.org/relay/setup/bridge/archlinux/ #: (content/relay/setup/bridge/archlinux/contents+en.lrpage.body) msgid "User tor" -msgstr "" +msgstr "User tor" #: https//community.torproject.org/relay/setup/bridge/archlinux/ #: (content/relay/setup/bridge/archlinux/contents+en.lrpage.body) @@ -19652,7 +19682,7 @@ msgstr "" #: https//community.torproject.org/relay/setup/guard/dragonflybsd/ #: (content/relay/setup/guard/dragonflybsd/contents+en.lrpage.body) msgid "### 6. Final Notes" -msgstr "" +msgstr "### 6. В завершение" #: https//community.torproject.org/relay/setup/bridge/debian-ubuntu/ #: (content/relay/setup/bridge/debian-ubuntu/contents+en.lrpage.subtitle) @@ -19725,6 +19755,9 @@ msgid "" "or 443), you will need to give obfs4 `CAP_NET_BIND_SERVICE` capabilities to " "bind the port with a non-root user:" msgstr "" +"* Если решите использовать фиксированный порт obfs4 со значением менее 1024 " +"(например, 80 или 443), вам нужно дать obfs4 `CAP_NET_BIND_SERVICE` право " +"связать порт с пользователем без прав суперпользователя:" #: https//community.torproject.org/relay/setup/bridge/debian-ubuntu/ #: (content/relay/setup/bridge/debian-ubuntu/contents+en.lrpage.body) @@ -19740,6 +19773,11 @@ msgid "" "For more details, see [ticket " "18356](https://gitlab.torproject.org/tpo/core/tor/-/issues/18356)." msgstr "" +"Для большей защиты systemd вам также понадобится установить " +"`NoNewPrivileges=no` в `/lib/systemd/system/tor(a)default.service` и " +"`/lib/systemd/system/tor@.service`, а затем запустить `systemctl daemon-" +"reload`. Подробнее см. [заявку " +"18356](https://gitlab.torproject.org/tpo/core/tor/-/issues/18356)." #: https//community.torproject.org/relay/setup/bridge/debian-ubuntu/ #: (content/relay/setup/bridge/debian-ubuntu/contents+en.lrpage.body) @@ -20042,11 +20080,13 @@ msgid "" "To confirm your bridge is running with no issues, you should see something " "like this in `/var/log/tor/notices.log`:" msgstr "" +"Доказательством того, что ваш мост работает без проблем, служит примерно " +"такая запись в `/var/log/tor/notices.log`:" #: https//community.torproject.org/relay/setup/bridge/freebsd/ #: (content/relay/setup/bridge/freebsd/contents+en.lrpage.body) msgid "### 9. Final Notes" -msgstr "" +msgstr "### 9. В завершение" #: https//community.torproject.org/relay/setup/bridge/dragonflybsd/ #: (content/relay/setup/bridge/dragonflybsd/contents+en.lrpage.subtitle)

1 0

[tor/main] fix an already-existing bug in the unit tests
by dgoulet＠torproject.org 23 Feb '22

23 Feb '22

commit 5ee85c1fac9adbc09e0930166841c192129b2c28 Author: Roger Dingledine <arma(a)torproject.org> Date: Fri Oct 29 15:24:43 2021 -0400 fix an already-existing bug in the unit tests where the or_conn for testing the failure cache would be initialized with random stack data, so e.g. its potentially_used_for_bootstrapping field would start out at some random value. --- src/test/test_connection.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/test/test_connection.c b/src/test/test_connection.c index 87940f71e6..fbf9d6a5ab 100644 --- a/src/test/test_connection.c +++ b/src/test/test_connection.c @@ -826,6 +826,7 @@ test_failed_orconn_tracker(void *arg) /* Prepare the OR connection that will be used in this test */ or_connection_t or_conn; + memset(&or_conn, 0, sizeof(or_conn)); tt_int_op(AF_INET,OP_EQ, tor_addr_parse(&or_conn.canonical_orport.addr, "18.0.0.1")); tt_int_op(AF_INET,OP_EQ, tor_addr_parse(&or_conn.base_.addr, "18.0.0.1"));

1 0

[tor/main] don't cache connect failures from our own circuits
by dgoulet＠torproject.org 23 Feb '22

23 Feb '22

commit 5ad126a51bdfaeecc81b1cb6517abd2d5e039fad Author: Roger Dingledine <arma(a)torproject.org> Date: Tue Oct 26 05:40:38 2021 -0400 don't cache connect failures from our own circuits The connect failure cache had a bad interaction with retrying connections to our guards or bridges when we go offline and then come back online -- while offline we would fail to connect and cache this result, and then when we return we would decline to even attempt to connect, because our failure cache said it wouldn't work. Now only cache connect failures for relays when we connected to them because of somebody else's EXTEND request. Fixes bug 40499; bugfix on 0.3.3.4-alpha. --- changes/bug40499 | 7 +++++++ src/core/or/connection_or.c | 7 +++++++ 2 files changed, 14 insertions(+) diff --git a/changes/bug40499 b/changes/bug40499 new file mode 100644 index 0000000000..149e9bd200 --- /dev/null +++ b/changes/bug40499 @@ -0,0 +1,7 @@ + o Major bugfixes (client): + - Stop caching TCP connect failures to relays/bridges when we + initiated the connection as a client. Now we only cache connect + failures as a relay or bridge when we initiated them because + of an EXTEND request. Declining to re-attempt the client-based + connections could cause problems when we lose connectivity and + try to reconnect. Fixes bug 40499; bugfix on 0.3.3.4-alpha. diff --git a/src/core/or/connection_or.c b/src/core/or/connection_or.c index db9f93e6f6..0018b1dfd8 100644 --- a/src/core/or/connection_or.c +++ b/src/core/or/connection_or.c @@ -1316,6 +1316,13 @@ note_or_connect_failed(const or_connection_t *or_conn) tor_assert(or_conn); + if (or_conn->potentially_used_for_bootstrapping) { + /* Don't cache connection failures for connections we initiated ourself. + * If these direct connections fail, we're supposed to recognize that + * the destination is down and stop trying. See ticket 40499. */ + return; + } + ocf = or_connect_failure_find(or_conn); if (ocf == NULL) { ocf = or_connect_failure_new(or_conn);

1 0

[tor/main] Merge branch 'tor-gitlab/mr/488'
by dgoulet＠torproject.org 23 Feb '22

23 Feb '22

commit 45416356ed7dc5551cda491c01a4d7df1ed97a20 Merge: d09e58d9bf 5ee85c1fac Author: David Goulet <dgoulet(a)torproject.org> Date: Wed Feb 23 15:21:40 2022 -0500 Merge branch 'tor-gitlab/mr/488' changes/bug40499 | 7 +++++++ src/core/or/connection_or.c | 7 +++++++ src/test/test_connection.c | 1 + 3 files changed, 15 insertions(+)

1 0

[tor/main] cc: Fix memleak when building extension response
by dgoulet＠torproject.org 23 Feb '22

23 Feb '22

commit d09e58d9bf0a2c94cec886756351cb718cb31959 Author: David Goulet <dgoulet(a)torproject.org> Date: Wed Feb 23 13:22:59 2022 -0500 cc: Fix memleak when building extension response Fixes #40575 Signed-off-by: David Goulet <dgoulet(a)torproject.org> --- src/core/or/congestion_control_common.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/src/core/or/congestion_control_common.c b/src/core/or/congestion_control_common.c index fb56014315..93d3a9f2c5 100644 --- a/src/core/or/congestion_control_common.c +++ b/src/core/or/congestion_control_common.c @@ -1303,6 +1303,7 @@ congestion_control_build_ext_response(const circuit_params_t *our_params, ret = trn_extension_field_cc_encoded_len(cc_field); if (BUG(ret <= 0)) { + trn_extension_field_free(field); goto err; } size_t field_len = ret; @@ -1313,6 +1314,7 @@ congestion_control_build_ext_response(const circuit_params_t *our_params, ret = trn_extension_field_cc_encode(field_array, trn_extension_field_getlen_field(field), cc_field); if (BUG(ret <= 0)) { + trn_extension_field_free(field); goto err; } @@ -1340,11 +1342,7 @@ congestion_control_build_ext_response(const circuit_params_t *our_params, ret = 0; err: - if (ext) { - trn_extension_free(ext); - } else { - trn_extension_field_free(field); - } + trn_extension_free(ext); trn_extension_field_cc_free(cc_field); return (int)ret; }

1 0

[tor/main] Properly initialize the cc_enabled field in hs intro data.
by dgoulet＠torproject.org 23 Feb '22

23 Feb '22

commit 77bf932c83a1a8b1cf627a66656f40dea715d75e Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Wed Feb 23 00:23:23 2022 +0000 Properly initialize the cc_enabled field in hs intro data. --- src/feature/hs/hs_circuit.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/feature/hs/hs_circuit.c b/src/feature/hs/hs_circuit.c index 271bf652e7..f8a0e06d90 100644 --- a/src/feature/hs/hs_circuit.c +++ b/src/feature/hs/hs_circuit.c @@ -996,6 +996,7 @@ hs_circ_handle_introduce2(const hs_service_t *service, data.payload_len = payload_len; data.link_specifiers = smartlist_new(); data.replay_cache = ip->replay_cache; + data.cc_enabled = 0; if (get_subcredential_for_handling_intro2_cell(service, &data, subcredential)) {

1 0

[tor/main] Merge branch 'tor-gitlab/mr/536'
by dgoulet＠torproject.org 23 Feb '22

23 Feb '22

commit 69f1a7aa5944060f62ab3761f468cb6cd654d636 Merge: 37b0d464b8 2d0377be75 Author: David Goulet <dgoulet(a)torproject.org> Date: Wed Feb 23 13:19:10 2022 -0500 Merge branch 'tor-gitlab/mr/536' src/feature/hs/hs_cell.c | 6 ++++++ src/feature/hs/hs_circuit.c | 1 + src/test/test_hs_service.c | 1 + 3 files changed, 8 insertions(+)

1 0

[tor/main] Reject intro2 cells that request unadvertized congestion control.
by dgoulet＠torproject.org 23 Feb '22

23 Feb '22

commit 2d0377be75b158dde3a91b55d248fee4fe381452 Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Wed Feb 23 00:42:31 2022 +0000 Reject intro2 cells that request unadvertized congestion control. --- src/feature/hs/hs_cell.c | 6 ++++++ src/test/test_hs_service.c | 1 + 2 files changed, 7 insertions(+) diff --git a/src/feature/hs/hs_cell.c b/src/feature/hs/hs_cell.c index b7ab68f7c4..490f05e54f 100644 --- a/src/feature/hs/hs_cell.c +++ b/src/feature/hs/hs_cell.c @@ -952,6 +952,12 @@ hs_cell_parse_introduce2(hs_cell_introduce2_data_t *data, } } + /* If the client asked for congestion control, but we don't support it, + * that's a failure. It should not have asked, based on our descriptor. */ + if (data->cc_enabled && !congestion_control_enabled()) { + goto done; + } + /* Success. */ ret = 0; log_info(LD_REND, "Valid INTRODUCE2 cell. Launching rendezvous circuit."); diff --git a/src/test/test_hs_service.c b/src/test/test_hs_service.c index 33a3f279c6..482ee1a014 100644 --- a/src/test/test_hs_service.c +++ b/src/test/test_hs_service.c @@ -2330,6 +2330,7 @@ test_intro2_handling(void *arg) intro_circ->cpath->prev = intro_circ->cpath; intro_circ->hs_ident = tor_malloc_zero(sizeof(*intro_circ->hs_ident)); origin_circuit_t rend_circ; + TO_CIRCUIT(&rend_circ)->ccontrol = NULL; rend_circ.hs_ident = tor_malloc_zero(sizeof(*rend_circ.hs_ident)); curve25519_keypair_generate(&rend_circ.hs_ident->rendezvous_client_kp, 0); memset(rend_circ.hs_ident->rendezvous_cookie, 'r', HS_REND_COOKIE_LEN);

1 0

[torspec/main] Prop 324: Updates for Negotiation and Simulation Testing
by dgoulet＠torproject.org 23 Feb '22

23 Feb '22

commit 71c326ae934eee9f76b957f9097f5dba7fed8974 Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Tue Nov 30 06:03:28 2021 +0000 Prop 324: Updates for Negotiation and Simulation Testing Changes: - Rework exit negotiation logic a bit - Specify using ntorv3 with extension fields for negotiation - Clients only request congestion control; exits and services control sendme_inc - Rework onion service negotiation for descriptor-controlled FlowCtrl protover and sendme_inc value - Add bounds checks on sendme_inc for clients - Update parameter values based on Shadow results - Improvements to TOR_VEGAS algorithm based on simulation testing - Additional consensus parameters for RTT N-EWMA smoothing and TOR_VEGAS queue use caps - Clarify N_EWMA smoothing, and relocate it to its own sub-section. - TOR_VEGAS now defaults to CWND/RTT BDP estimator - Minor TOR_VEGAS alg bugfixes - Add a 'delta' parameter to TOR_VEGAS for steady-state backoff - Consensus param update notes and param range fixes. - Add glossary of common congestion control acronyms - Misc clarifications --- proposals/324-rtt-congestion-control.txt | 524 +++++++++++++++++++++++-------- 1 file changed, 395 insertions(+), 129 deletions(-) diff --git a/proposals/324-rtt-congestion-control.txt b/proposals/324-rtt-congestion-control.txt index 36e10e7..78b6789 100644 --- a/proposals/324-rtt-congestion-control.txt +++ b/proposals/324-rtt-congestion-control.txt @@ -51,6 +51,9 @@ be found at: An exhaustive list of citations for further reading is in Section [CITATIONS]. +A glossary of common congestion control acronyms and terminology is in +Section [GLOSSARY]. + 1. Overview [OVERVIEW] @@ -115,15 +118,14 @@ RELAY_COMMAND_SENDME relay cells every CIRCWINDOW_INCREMENT (100) cells of received RELAY_COMMAND_DATA. This allows those endpoints to measure the current circuit RTT, by -measuring the amount of time between sending of every 100th data cell -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. The current RTT is N-EWMA smoothed[27] over a -'cc_ewma_cwnd_cnt' multiple of congestion window worth of sendme acks. +measuring the amount of time between sending a RELAY_COMMAND_DATA cell +that would trigger a SENDME from the other endpoint, and the arrival of +that SENDME cell. This means that RTT is measured every 'cc_sendme_inc' +data cells. -Circuits will also record the minimum and maximum RTT seen so far. +Circuits will record the minimum and maximum RTT measurement, as well as +a smoothed value of representing the current RTT. The smoothing for the +current RTT is performed as specified in [N_EWMA_SMOOTHING]. Algorithms that make use of this RTT measurement for congestion window update are specified in [CONTROL_ALGORITHMS]. @@ -146,8 +148,8 @@ 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 +the stored EWMA RTT. If the new RTT is either 5000 times larger than the EWMA +RTT, or 5000 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. @@ -157,6 +159,28 @@ have enough data to compute the above heueristics. This cached value is also exported for use by the edge connection rate calculations done by [XON_ADVISORY]. +2.1.2. N_EWMA Smoothing [N_EWMA_SMOOTHING] + +Both RTT estimation and SENDME BDP estimation require smoothing, to +reduce the effects of packet jitter. + +This smoothing is performed using N_EWMA[27], which is an Exponential +Moving Average with alpha = 2/(N+1): + + N_EWMA = BDP*2/(N+1) + N_EWMA_prev*(N-1)/(N+1). + +Flow control rate limiting uses this function + +For both RTT and SENDME BDP estimation, N is the number of SENDME acks +between congestion window updates, divided by the value of consensus +parameter 'cc_ewma_cwnd_pct', and then capped at a max of 'cc_ewma_max', +but always at least 2: + + N = MAX(MIN(CWND_UPDATE_RATE(cc)*cc_ewma_cwnd_pct/100, cc_ewma_max), 2); + +CWND_UPDATE_RATE is normally just round(CWND/cc_sendme_inc), but after +slow start, it is round(CWND/(cc_cwnd_inc_rate*cc_sendme_inc)). + 2.2. SENDME behavior changes We will make four major changes to SENDME behavior to aid in computing @@ -174,10 +198,9 @@ congestion, since the RTT will be measured more often. If experimentation in Shadow shows that more frequent SENDMEs reduce 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: Refer to or include final version of the negotiation proposal for - this: https://gitlab.torproject.org/tpo/core/tor/-/issues/40377 +well, using Proposal 325. The method for negotiating a common value of +cc_sendme_inc on a circuit is covered in [ONION_NEGOTIATION] and +[EXIT_NEGOTIATION]. Third, authenticated SENDMEs can remain as-is in terms of protocol behavior, but will require some implementation updates to account for @@ -294,23 +317,11 @@ 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. -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 -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. +It is possible to directly measure BDP via the amount of time between SENDME +acks. In this period of time, we know that the endpoint successfully received +'cc_sendme_inc' cells. This means that the bandwidth of the circuit is then calculated as: @@ -343,17 +354,22 @@ truncation, we compute the BDP using multiplication first: 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 -five (5) num_sendme's are used, due to ack compression. This is controlled by -the 'cc_bwe_min' consensus parameter. Finally, if [CLOCK_HEURISTICS] have -detected a clock jump or stall, this estimator is not updated. +After all of this, the BDP is smoothed using [N_EWMA_SMOOTHING]. + +This smoothing means 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 'cc_bwe_min' sendme's are used. This is controlled by 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 updating this BDP estimate and discard old timestamps. However, we retain the actual estimator value. +Unfortunately, even after all of this, SENDME BDP estimation proved unreliable +in Shadow simulation, due to ack compression. + 3.1.2. Congestion Window BDP Estimation Assuming that the current congestion window is at or above the current BDP, @@ -422,8 +438,9 @@ 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 'cc_ewma_cwnd_cnt' congestion windows -worth of SENDME acks. +RTT_current is N-EWMA smoothed over 'cc_ewma_cwnd_pct' percent of +congestion windows worth of SENDME acks, up to a max of 'cc_ewma_max' acks, as +described in [N_EWMA_SMOOTHING]. Recall that BOOTLEG_RTT_TOR emits a congestion signal when the current RTT falls below some fractional threshold ('cc_westwood_rtt_thresh') fraction @@ -502,27 +519,29 @@ Thus, Vegas estimates estimates the queue use caused by congestion as: queue_use = cwnd - BDP -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 +Original TCP Vegas used a cwnd BDP estimator only. We added the ability to +switch this BDP estimator in the implementation, and experimented with various +options. We also parameterized 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'). +estimate (consensus parameter 'cc_vegas_bdp_mix'). After much testing of +various ways to compute BDP, we were still unable to do much better than the +original cwnd estimator. So while this capability to change the BDP estimator +remains in the C implementation, we do not expect it to be used. -Additionally, if the local OR connection is blocked at the time of SENDME ack -arrival, this is treated as an immediate congestion signal. +However, it was useful to use a local OR connection block at the time of +SENDME ack arrival, as an immediate congestion signal. -(We can also optionally use the ECN signal described in -ideas/xxx-backward-ecn.txt, to exit Slow Start.) +(As an additional optimization, we could also use the ECN signal described in +ideas/xxx-backward-ecn.txt, but this is not implemented. It is likely only of +any benefit during Slow Start, and even that benefit is likely small.) Congestion signals from RTT, blocked OR connections, or ECN are processed only 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: +Here is the complete pseudocode for TOR_VEGAS, which is run every time +an endpoint receives a SENDME ack: # Update acked cells inflight -= cc_sendme_inc @@ -543,18 +562,30 @@ ack: 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 + # Increment by slow start %, or at least 2 sendme_inc's worth + cwnd = cwnd + MAX(cwnd * cc_cwnd_inc_pct_ss, 2*cc_sendme_inc) + # If our BDP estimator thinks the BDP is still larger, use that + cwnd = MAX(cwnd, BDP) else: - cwnd = BDP + cwnd = BDP + cc_vegas_gamma in_slow_start = 0 else: - if queue_use > cc_vegas_beta or orconn_blocked: - cwnd += cc_cwnd_inc - elif queue_use < cc_vegas_alpha: + if queue_use > cc_vegas_delta: + cwnd = BDP + cc_vegas_delta - cc_cwnd_inc + elif queue_use > cc_vegas_beta or orconn_blocked: cwnd -= cc_cwnd_inc + elif queue_use < cc_vegas_alpha: + cwnd += cc_cwnd_inc cwnd = MAX(cwnd, cc_circwindow_min) - next_cc_event = cwnd / (cc_cwnd_inc_rate * cc_sendme_inc) + + # Count the number of sendme acks until next update of cwnd, + # rounded to nearest integer + if in_slow_start: + next_cc_event = round(cwnd / cc_sendme_inc) + else + # Never increment faster in slow start, only steady state. + next_cc_event = round(cwnd / (cc_cwnd_inc_rate * cc_sendme_inc)) 3.4. Tor NOLA: Direct BDP tracker [TOR_NOLA] @@ -1081,6 +1112,11 @@ These are sorted in order of importance to tune, most important first. 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. + - Shadow Tuning Results: + Westwood exhibited responsiveness problems, drift, and overshoot. + NOLA exhibited ack compression resulting in over-estimating the + BDP. Vegas, when tuned properly, kept queues low and throughput + high, but even. cc_bwe_min: - Description: @@ -1100,11 +1136,15 @@ These are sorted in order of importance to tune, most important first. 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. + - Shadow Tuning Results: + Regarless of how high this was set, there were still cases where + queues built up, causing BDP over-estimation. As a result, we disable + use of the BDP estimator, and only use the Vegas CWND estimator. cc_sendme_inc: - Description: Specifies how many cells a SENDME acks - - Range: [1, 5000] - - Default: 50 + - Range: [1, 255] + - Default: 31 - Tuning Values: 25,33,50 - Tuning Notes: Increasing this increases overhead, but also increases BDP @@ -1112,14 +1152,22 @@ These are sorted in order of importance to tune, most important first. 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. + - Shadow Tuning Results: + This was optimal at 31-32 cells, which is also the number of + cells that fit in a TLS frame. Much of the rest of Tor has + processing values at 32 cells, as well. + - Consensus Update Notes: + This value MUST only be changed by a factor of 2, every 4 hours. + If greater changes are needed, they MUST be spread out over + multiple consensus updates. 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 buffer bloat issues at local routers. - - Range: [100, 10000] - - Default: 500 + - Range: [31, 10000] + - Default: 4*31 - Tuning Values: 150,200,250,500 - Tuning Notes: Higher initial congestion windows allow the algorithms to @@ -1127,10 +1175,16 @@ These are sorted in order of importance to tune, most important first. 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. + - Shadow Tuning Results: + Setting this too high caused excessive cell queues at relays. + 4*31 ended up being a sweet spot. + - Consensus Update Notes: + This value must never be set below cc_sendme_inc. cc_cwnd_min: - Description: The minimum allowed cwnd. - - Range: [cc_sendme_inc, 1000] + - Range: [31, 1000] + - Default: 31 - Tuning Values: [100, 150, 200] - Tuning Notes: If the cwnd falls below cc_sendme_inc, connections can't send @@ -1138,10 +1192,14 @@ These are sorted in order of importance to tune, most important first. 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, but no lower than cc_sendme_inc. + - Shadow Tuning Results: + We set this at 31 cells, the cc_sendme_inc. + - Consensus Update Notes: + This value must never be set below cc_sendme_inc. cc_cwnd_max: - Description: The maximum allowed cwnd. - - Range: [cc_sendme_inc, INT32_MAX] + - Range: [500, INT32_MAX] - Default: INT32_MAX - Tuning Values: [5000, 10000, 20000] - Tuning Notes: @@ -1151,6 +1209,8 @@ These are sorted in order of importance to tune, most important first. queues large enough to cause ack compression should become rare. This parameter exists primarily to verify this in Shadow, but we preserve it as a consensus parameter for emergency use in the live network, as well. + - Shadow Tuning Results: + We kept this at INT32_MAX. circwindow: - Description: Initial congestion window for legacy Tor clients @@ -1175,39 +1235,69 @@ These are sorted in order of importance to tune, most important first. 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. + - Shadow Tuning Results: + Increasing this during slow start caused overshoot and excessive + queues. Increasing this after slow start was suboptimal for + performance. We keep this at 1. - cc_ewma_cwnd_cnt: + cc_ewma_cwnd_pct: - 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] + estimation, as a percent of the number of SENDME acks + in a congestion window. It allows us to average these RTT + values over a percentage of the congestion window, + capped by 'cc_ewma_max' below, and specified in + [N_EWMA_SMOOTHING]. + - Range: [1, 255] + - Default: 50,100 + - Tuning Values: [25,50,100] - 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. + - Shadow Tuning Results: + Setting this to 50 seemed to reduce cell queues, but this may also + have impacted performance. + + cc_ewma_max: + - Description: This specifies the max N in N_EWMA smoothing of RTT and BDP + estimation. It allows us to place a cap on the N of EWMA + smoothing, as specified in [N_EWMA_SMOOTHING]. + - Range: [2, INT32_MAX] + - Default: 10 + - Tuning Values: [10,20] + - Shadow Tuning Results: + We ended up needing this to make Vegas more responsive to + congestion, to avoid overloading slow relays. Values of 10 or 20 + were best. cc_cwnd_inc: - Description: How much to increment the congestion window by during steady state, every cwnd. - Range: [1, 1000] - - Default: 50 + - Default: 31 - 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. + - Shadow Tuning Results: + Increasing this negatively impacted performance. Keeping it at + cc_sendme_inc is best. cc_cwnd_inc_pct_ss: - Description: Percentage of the current congestion window to increment by during slow start, every cwnd. - - Range: [10, 300] - - Default: 100 + - Range: [1, 500] + - Default: 50 - 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. + - Shadow Tuning Results: + Setting this above 50 caused excessive queues to build up in + Shadow. This may have been due to imbalances in Shadow client + allocation, though. Values of 50-100 will be explored after + examining Shadow Guard Relay Utilization. cc_bdp_alg: - Description: The BDP estimation algorithm to use. @@ -1215,6 +1305,8 @@ These are sorted in order of importance to tune, most important first. - Default: 7 (Piecewise EWMA) - Tuning Notes: We don't expect to need to tune this. + - Shadow Tuning Results: + We leave this as-is, but disable it in Vegas instead, below. 6.5.2. Westwood parameters @@ -1273,13 +1365,18 @@ These are sorted in order of importance to tune, most important first. 6.5.3. Vegas Parameters - cc_vegas_alpha: - cc_vegas_beta: - cc_vegas_gamma: + cc_vegas_alpha_{exit,onion,sos,vg,sbws}: + cc_vegas_beta_{exit,onion,sos,vg,sbws}: + cc_vegas_gamma_{exit,onion,sos,vg,sbws}: + cc_vegas_delta_{exit,onion,sos,vg,sbws}: - Description: These parameters govern the number of cells that [TOR_VEGAS] can detect in queue before reacting. - - Range: [1, 1000] - - Defaults: 6*cc_sendme_inc for gamma and beta; 3*cc_sendme_inc for alpha + - Range: [0, 1000] (except delta, which has max of INT32_MAX) + - Defaults: + alpha: path_len*2*31-31 + beta: path_len*2*31 + gamma: path_len*2*31 + delta: path_len*2*31 + 2*31 - Tuning Notes: The amount of queued cells that Vegas should tolerate is heavily dependent upon competing congestion control algorithms. The specified @@ -1288,18 +1385,30 @@ These are sorted in order of importance to tune, most important first. 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. + - Shadow Tuning Results: + We found that the best values for 3-hop Exit circuits was to set + beta and gamma to the size of the outbufs times the number of hops. + This has the effect that Vegas detects congestion and backs off + when this much queue delay is detected. Alpha is set to one TLS + record/sendme_inc below this value. If the queue length is detected + to be below that, we increase the congestion window. We still + need to verify that the path length multiplier still holds for + other types of circuits, specifically onion services. 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) + - Default: 100 (use 100% CWND estimator) - 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. + - Shadow Tuning Results: + Because the BDP estimator had ack compression and over-estimation, + we the CWND estimator. 6.5.4. NOLA Parameters @@ -1358,7 +1467,7 @@ These are sorted in order of importance to tune, most important first. cc_xon_change_pct - Description: Specifies how much the edge drain rate can change before we send another advisory cell. - - Range: [1, 100] + - Range: [1, 99] - Default: 25 - Tuning values: [25, 50, 75] - Tuning Notes: @@ -1465,6 +1574,9 @@ These are sorted in order of importance to tune, most important first. expensive. We will need to trace or monitor epoll() invocations in Shadow or on a Tor exit to verify that low values do not lead to more mainloop invocations. + - Shadow Tuning Results: + After extensive tuning, it turned out that the defaults were optimal + in terms of throughput. orconn_high orconn_low @@ -1658,85 +1770,96 @@ also be used as a side channel. So we must limit its use to a couple of cells per circuit, at most. https://blog.torproject.org/tor-security-advisory-relay-early-traffic-confi… -9. Onion Services + +9. Onion Service Negotiation [ONION_NEGOTIATION] Onion service requires us to advertise the protocol version and congestion control parameters in a different way since the end points do not know each -other like a client knows all the relays and what they support. +other like a client knows all the relays and what they support. Additionally, +we cannot use ntorv3 for onion service negotiation, because it is not +supported at all rendezvous and introduction points. To address this, this is done in two parts. First, the service needs to -advertise to the world that it supports congestion control. This is done -through a new line in the descriptor, see section 9.1 below. +advertise to the world that it supports congestion control, and its view of +the current cc_sendme_inc consensus parameter. This is done through a new +line in the onion service descriptor, see section 9.1 below. Second, the client needs to inform the service that it wants to use congestion -control on the rendezvous circuit and with wich parameters. This is done -through the INTRODUCE cell as an extension, see section 9.2 below. +control on the rendezvous circuit. This is done through the INTRODUCE cell as +an extension, see section 9.2 below. -9.1. Descriptor +9.1. Onion Service Descriptor -We propose to add a new line to advertise the flow control protocol version: +We propose to add a new line to advertise the flow control protocol version, +in the encrypted section of the onion service descriptor: - "flow-control" SP version-number NL + "flow-control" SP version-range SP sendme-inc NL - The "version-number" value is the same as the protocol version FlowCtrl - that relay advertises which is defined earlier in this proposal. Current - value can only be "2". + The "version-range" value is the same as the protocol version FlowCtrl + that relay advertises which is defined earlier in this proposal. The + current value is "1-2". -Clients that are able to parse this line and know the protocol version can then -send in the INTRODUCE1 cell congestion control parameters that they would like -to use which is detailed in the next section. + The "sendme-inc" value comes from the service's current cc_sendme_inc + consensus parameter. -This line MUST be removed from the descriptor if the consensus disables -congestion control by setting "cc_alg=0". In other words, a service should only -advertise its flow control version if congestion control is enabled network -wide. +Clients MUST ignore additional unknown versions in "version-range", and MUST +ignore any additional values on this line. -9.2 INTRODUCE cell extension +Clients SHOULD use the highest value in "version-range" to govern their +protocol choice for "FlowCtrl" and INTRODUCE cell format, as per Section 9.2 +below. -We propose a new extension to the INTRODUCE cell which can be used to send -congestion control parameters down to the service. It is important to mention -that this is an extension to be used in the encrypted setion of the cell and -not its readable section by the introduction point. +If clients do not support any of the versions in "version-range", they SHOULD +reject the descriptor. (They MAY choose to ignore this line instead, but doing +so means using the old fixed-window SENDME flow control, which will likely be +bad for the network). -If used, it needs to be encoded within the N_EXTENSIONS field of the ENCRYPTED -section of the INTRODUCE1 cell defined in rend-spec-v3.txt section 3.3. The -content is defined as follow: +Clients that are able to parse this line and know the protocol version +MUST validate that the "sendme-inc" value is within a multiple of 2 of the +"cc_sendme_inc" in the consensus that they see. If "sendme-inc" is not within +range, they MUST reject the descriptor. - EXT_FIELD_TYPE: +If their consensus also lists a non-zero "cc_alg", they MAY then send in the +INTRODUCE1 cell congestion control request extention field, which is detailed +in the next section. - [01] -- Congestion Control Parameters. +A service should only advertise its flow control version if congestion control is +enabled. It MUST remove this line if congestion control is disabled. - If this flag is set, the extension should be used by the service to learn - what are the congestion control parameters to use on the rendezvous - circuit. +If the service observes a change in 'cc_sendme_inc' consensus parameter since +it last published its descriptor, it MUST immediately close its introduction +points, and publish a new descriptor with the new "sendme-inc" value. The +additional step of closing the introduction points ensures that no clients +arrive using a cached descriptor, with the old "sendme-inc" value. - EXT_FIELD content format is: +9.2 INTRODUCE cell extension - N_PARAMS [1 byte] - N_PARAMS times: - PARAM_TYPE [1 byte] - PARAM_VALUE [8 byte] +We propose a new extension to the INTRODUCE cell which can be used to send +congestion control parameters down to the service. It is important to mention +that this is an extension to be used in the encrypted setion of the cell and +not its readable section by the introduction point. - The PARAM_TYPE possible values are: +If used, it needs to be encoded within the ENCRYPTED section of the INTRODUCE1 +cell defined in rend-spec-v3.txt section 3.3. The content is defined as follow: - [01] -- Newest protocol version supported - The newest protocol version that the client supports. + EXT_FIELD_TYPE: - [02] -- SENDME increment - The initial SENDME increment that should be used by both end points - when using congestion control. + [01] -- Congestion Control Request. - The PARAM_VALUE size is 8 bytes in order to accomodate 64bit values. It - MUST match the specified limits for the following PARAM_TYPE: +This field is has zero payload length. Its presence signifies that the client wants to +use congestion control. The client MUST NOT set this field, or use +ntorv3, if the service did not list "2" in the "FlowCtrl" line in the +descriptor. The client SHOULD NOT provide this field if the consensus parameter +'cc_alg' is 0. - [01] -- Min: 2, Max: 255 - [02] -- Min: 1, Max: 5000 (same as "cc_sendme_inc") +The service MUST ignore any unknown fields. 9.3 Protocol Flow First, the client reads the "flow-control" line in the descriptor and gets the -maximum value from what it supports and the service supports. As an example, if -the client supports 2-3-4 and the service supports 2-3, then 3 is chosen. +maximum value from that line's "version-range" and the service supports. As an +example, if the client supports 2-3-4 and the service supports 2-3, then 3 is +chosen. It then sends that value along its desired cc_sendme_inc value in the INTRODUCE1 cell in the extension. @@ -1747,7 +1870,7 @@ then applied to the rendezvous circuit. 9.4 Circuit Behavior -If the extension is not found in the cell, the service MUST not use congestion +If the extension is not found in the cell, the service MUST NOT use congestion control on the rendezvous circuit. Any invalid values received in the extension should result in closing the @@ -1765,15 +1888,159 @@ everyone looks the same again. The new extension is located in the encrypted part of the INTRODUCE1 cell and thus the introduction point can't learn its content. -10. Acknowledgements + +10. Exit negotiation [EXIT_NEGOTIATION] + +Similar to onion services, clients and exits will need to negotiate the +decision to use congestion control, as well as a common value for +'cc_sendme_inc', for a given circuit. + +10.1. When to negotiate + +Clients decide to initiate a negotiation attempt for a circuit if the +consensus lists a non-zero 'cc_alg' parameter value, and the protover line +for their chosen exit includes a value of 2 in the "FlowCtrl" field. + +If the FlowCtrl=2 subprotocol is absent, a client MUST NOT attempt negotiation. + +If 'cc_alg' is absent or zero, a client SHOULD NOT attempt +negotiation, or use ntorv3. + +If the protover and consensus conditions are met, clients SHOULD negotiate +with the Exit if the circuit is to be used for exit stream activity. Clients +SHOULD NOT negotiate congestion control for one-hop circuits, or internal +circuits. + +10.2. What to negotiate + +Clients and exits need not agree on a specific congestion control algorithm, +or any aspects of its behavior. Each endpoint's management of its congestion +window is independent. However, because the new algorithms no longer use +stream SENDMEs or fixed window sizes, they cannot be used with an endpoint +expecting the old behavior. + +Additionally, each endpoint must agree on the the SENDME increment rate, in +order to synchronize SENDME authentication and pacing. + +For this reason, negotiation needs to establish a boolean: "use congestion +control", and an integer value for SENDME increment. + +No other parameters need to be negotiated. + +10.3. How to negotiate + +Negotiation is performed by sending an ntorv3 onionskin, as specified in +Proposal 332, to the Exit node. The encrypted payload contents from the +clients are encoded as an extension field, as in the onion service INTRO1 +cell: + + EXT_FIELD_TYPE: + + [01] -- Congestion Control Request. + +As in the INTRO1 extension field, this field is has zero payload length. + +Its presence signifies that the client wants to use congestion control. +Again, the client MUST NOT set this field, or use ntorv3, if this exit did not +list "2" in the "FlowCtrl" version line. The client SHOULD NOT set this to 1 +if the consensus parameter 'cc_alg' is 0. + +The Exit MUST ignore any additional unknown extension fields. + +The server's encrypted ntorv3 reply payload is encoded as: + + EXT_FIELD_TYPE: + + [02] -- Congestion Control Response. + + If this flag is set, the extension should be used by the service to learn + what are the congestion control parameters to use on the rendezvous + circuit. + + EXT_FIELD content payload is a single byte: + + sendme_inc [1 byte] + +The Exit MUST provide its current view of 'cc_sendme_inc' in this payload if it +observes a non-zero 'cc_alg' consensus parameter. Exits SHOULD only include +this field once. + +The client MUST use the FIRST such field value, and ignore any duplicate field +specifiers. The client MUST ignore any unknown additional fields. + +10.5. Client checks + +The client MUST reject any ntorv3 replies for non-ntorv3 onionskins. + +The client MUST reject an ntorv3 reply with field EXT_FIELD_TYPE=02, if the +client did not include EXT_FIELD_TYPE=01 in its handshake. + +The client SHOULD reject a sendme_inc field value that differs from the +current 'cc_sendme_inc' consensus parameter by more than a factor of 2, in +either direction. + +If a client rejects a handshake, it MUST close the circuit. + +10.6. Managing consenus updates + +The pedantic reader will note that a rogue consensus can cause all clients +to decide to close circuits by changing 'cc_sendme_inc' by a large margin. + +As a matter of policy, the directory authorities MUST NOT change +'cc_sendme_inc' by more than a factor of two (2), within a four (4) hour +window, for this reason. + +In Shadow simulation, the optimal 'cc_sendme_inc' value to be ~31 cells, or +one (1) TLS record worth of cells. We do not expect to change this value +significantly. + + +11. Acknowledgements Immense thanks to Toke Høiland-Jørgensen for considerable input into all aspects of the TCP congestion control background material for this proposal, as well as review of our versions of the algorithms. +12. Glossary [GLOSSARY] + +ACK - Acknowledgment. In congestion control, this is a type of packet that +signals that the endpoint received a packet or packet set. In Tor, ACKs are +called SENDMEs. + +BDP - Bandwidth Delay Product. This is the quantity of bytes that are actively +in transit on a path at any given time. Typically, this does not count packets +waiting in queues. It is essentially RTT*BWE - queue_delay. + +BWE - BandWidth Estimate. This is the estimated throughput on a path. + +CWND - Congestion WiNDow. This is the total number of packets that are allowed +to be "outstanding" (aka not ACKed) on a path at any given time. An ideal +congestion control algorithm sets CWND=BDP. + +EWMA - Exponential Weighted Moving Average. This is a mechanism for smoothing +out high-frequency changes in a value, due to temporary effects. + +ICW - Initial Congestion Window. This is the initial value of the congestion +window at the start of a connection. -11. [CITATIONS] +RTT - Round Trip Time. This is the time it takes for one endpoint to send a +packet to the other endpoint, and get a response. + +SS - Slow Start. This is the initial phase of most congestion control +algorithms. Despite the name, it is an exponential growth phase, to quickly +increase the congestion window from the ICW value up the path BDP. After Slow +Start, changes to the congestion window are linear. + +XOFF - Transmitter Off. In flow control, XOFF means that the receiver is +receiving data too fast and is beginning to queue. It is sent to tell the +sender to stop sending. + +XON - Transmitter On. In flow control, XON means that the receiver is ready to +receive more data. It is sent to tell the sender to resume sending. + + +13. [CITATIONS] 1. Options for Congestion Control in Tor-Like Networks. https://lists.torproject.org/pipermail/tor-dev/2020-January/014140.html @@ -1866,4 +2133,3 @@ as well as review of our versions of the algorithms. 31. KIST: Kernel-Informed Socket Transport for Tor https://matt.traudt.xyz/static/papers/kist-tops2018.pdf -

1 0

[tor-launcher/master] Bug 40774: Update about:preferences page to match new UI designs
by richard＠torproject.org 23 Feb '22

23 Feb '22

commit 3f344cc7871d00764212dd872abdc8d7ecf73494 Author: Pier Angelo Vendrame <pierov(a)torproject.org> Date: Fri Feb 18 09:50:57 2022 +0100 Bug 40774: Update about:preferences page to match new UI designs --- src/chrome/locale/en-US/network-settings.dtd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/chrome/locale/en-US/network-settings.dtd b/src/chrome/locale/en-US/network-settings.dtd index c1cadc9..cc501cd 100644 --- a/src/chrome/locale/en-US/network-settings.dtd +++ b/src/chrome/locale/en-US/network-settings.dtd @@ -62,7 +62,7 @@ <!ENTITY torprogress.pleaseWait "Please wait while we establish a connection to the Tor network.  This may take several minutes.">  -<!ENTITY torPreferences.categoryTitle "Tor"> +<!ENTITY torPreferences.categoryTitle "Connection"> <!ENTITY torPreferences.torSettings "Tor Settings"> <!ENTITY torPreferences.torSettingsDescription "Tor Browser routes your traffic over the Tor Network, run by thousands of volunteers around the world." > <!ENTITY torPreferences.learnMore "Learn More">

1 0