RFC 8511 | Альтернативный откат TCP с ECN (ABE)

Аннотация

Механизмы активного управления очередью (Active Queue Management — AQM) допускают пакетный допуск, обеспечивая при этом короткие очереди, чтобы минимизировать время, которое пакеты тратят в очереди в узком месте. Это может вызвать заметное снижение производительности для TCP-соединений, пересекающих такое узкое место, особенно если имеется только несколько потоков или их продукт с задержкой пропускной способности (BDP) велик. Получение метки явного уведомления о перегрузке (ECN), имеющей опыт перегрузки (CE), указывает на то, что механизм AQM используется в узком месте, и поэтому сетевая очередь узкого места, вероятно, будет короткой. Обратная связь этого сигнала позволяет реакции ECN на стороне отправителя TCP во избежание перегрузки уменьшить окно перегрузки (cwnd) на меньшую величину, чем реакция алгоритма управления перегрузкой на предполагаемую потерю пакета. Следовательно, эта спецификация определяет экспериментальное изменение реакции TCP, указанной в RFC 3168, как разрешено RFC 8311.

Скачать оригинальный документ на английском языке RFC 8511 PDF

1. Введение
2. Определения
3. Спецификация
3.1. Выбор множителя ABE
4. Дискуссия
4.1. Обоснование использования ECN для изменения степени отсрочки
4.2. Ответ на основе RTT для указанного затора
5. Требования к развертыванию ABE
6. Экспериментальные цели ABE
7. Соображения IANA
8. Вопросы безопасности
9. Ссылки
9.1. Нормативные ссылки
9.2. Информационные ссылки
Благодарности
Адреса авторов

Статус этой заметки

Этот документ не является спецификацией Internet Standards Track; оно публикуется для экспертизы, экспериментальной реализации и оценки.

Этот документ определяет Экспериментальный протокол для интернет-сообщества. Этот документ является продуктом Инженерной рабочей группы по Интернету (IETF). Он представляет собой консенсус сообщества IETF. Он получил общественное обозрение и был одобрен для публикации Руководящей группой по Интернет-разработкам (IESG). Не все документы, утвержденные IESG, являются кандидатами на любой уровень интернет-стандарта; см. раздел 2 RFC 7841.

Информацию о текущем состоянии этого документа, любых ошибках и способах предоставления отзывов о нем можно получить по адресу https://www.rfc-editor.org/info/rfc8511.

Уведомление об авторских правах

На данный документ распространяется действие BCP 78 и Правовые положения IETF Trust в отношении документов IETF (https://trustee.ietf.org/license-info), действующие на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права и ограничения в отношении этого документа. Компоненты кода, извлеченные из этого документа, должны включать в себя текст упрощенной лицензии BSD, как описано в разделе 4.e Правил доверия, и предоставляются без гарантии, как описано в упрощенной лицензии BSD.

1. Введение

Явное уведомление о перегрузке (ECN) [RFC3168] позволяет механизму активного управления очередью (AQM) сигнализировать о наличии зарождающейся перегрузки без необходимости потери пакетов. Это позволяет сети доставлять в приложение некоторые пакеты, которые были бы отброшены, если бы приложение или транспорт не поддерживали ECN. Такое уменьшение потери пакетов является наиболее очевидным преимуществом ECN, но оно часто является относительно скромным. Другие преимущества использования ECN описаны в [RFC8087].

Правила для ECN были изначально написаны, чтобы быть очень консервативными, и они требовали, чтобы алгоритмы управления перегрузкой протоколов ECN-Capable Transport (ECT) обрабатывали признаки перегрузки, сигнализируемые ECN, точно так же, как они будут обрабатывать предполагаемую потерю пакета [RFC3168] , Исследования продемонстрировали преимущества уменьшения сетевых задержек, которые вызваны взаимодействием контроля перегрузки TCP на основе потерь и чрезмерной буферизации [BUFFERBLOAT]. Это привело к созданию механизмов AQM, таких как Пропорциональный интегральный контроллер (PIE) [RFC8033] и Задержка управляющей очереди (CoDel) [RFC8289], которые предотвращают раздутые очереди, общие для неуправляемых и чрезмерно больших буферов, развернутых в Интернете [BUFFERBLOAT].

Механизмы AQM, упомянутые выше, направлены на то, чтобы поддерживать устойчивую очередь короткой, допуская временные (кратковременные) пакетные посылки. Однако используемые в настоящее время механизмы контроля перегрузок на основе потерь не всегда способны эффективно использовать узкое место в коротких очередях. Например, отправитель TCP, использующий контроль перегрузки Reno, должен иметь возможность хранить как минимум данные о продукте с задержкой пропускной способности (BDP) в буфере узких мест, если он должен поддерживать полное использование пути на стороне вызванное потерями уменьшение окна перегрузки (cwnd) [RFC5681]. Этот объем буферизации фактически удваивает объем данных, которые могут быть в полете, и максимальное время приема-передачи (RTT), которое испытывает отправитель TCP.

Современные механизмы AQM могут использовать ECN, чтобы сигнализировать о ранних признаках надвигающегося наращивания очереди задолго до того, как очередь отбрасывания хвоста будет вынуждена прибегнуть к отбрасыванию пакетов. Поэтому для алгоритма управления перегрузкой транспортного протокола целесообразно иметь более измеренный отклик, когда он получает индикацию с ранним предупреждением о перегрузке после того, как удаленная конечная точка получает пакет, отмеченный знаком ECN CE. Признавая эти изменения в современной практике AQM, было смягчено строгое требование, чтобы сигналы ECN CE обрабатывались идентично предполагаемой потере пакетов [RFC8311]. Поэтому в этом документе определяется новый ответ управления перегрузкой только на стороне отправителя, который называется «ABE» (альтернативный откат с ECN). ABE улучшает среднюю пропускную способность TCP, когда маршрутизаторы используют управляемые AQM буферы, которые допускают только короткие очереди.

2. Определения

Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119], [RFC8174].

3. Спецификация

Эта спецификация изменяет алгоритм управления перегрузкой транспортного протокола TCP, поддерживающего ECN, путем изменения отклика отправителя TCP на обратную связь от получателя TCP, которая указывает на прием отмеченного CE пакета, то есть получение пакета с помощью ECN-Echo. установить флаг (определенный в [RFC3168]), следуя процессу, определенному в [RFC8311].

Ответ TCP-отправителя в настоящее время указан в Разделе 6.1.2 спецификации ECN [RFC3168] и был слегка обновлен Разделом 4.1 [RFC8311] следующим образом:

Признак перегрузки следует рассматривать как потерю перегрузки в TCP, не поддерживающем ECN. Таким образом, источник TCP делит пополам окно «cwnd» на перегрузку и уменьшает порог медленного запуска «ssthresh», если экспериментальный RFC не определил иначе в потоке документов IETF.

Как разрешено RFC 8311, в этом документе указывается изменение на стороне отправителя протокола TCP, при котором при получении пакета с флагом ECN-Echo СЛЕДУЕТ инициировать источник TCP для установки порога медленного запуска (ssthresh) в 0,8 раза FlightSize, с меньшим значением граница 2 * SMSS применяется к результату (где SMSS означает максимальный размер сегмента отправителя)). Как и в [RFC5681], отправитель TCP также уменьшает значение cwnd не более чем до нового значения ssthresh. Раздел 6.1.2 RFC 3168 содержит руководство по настройке cwnd менее 2 * SMSS.

3.1. Выбор множителя ABE

ABE отделяет реакцию отправителя TCP на предполагаемую потерю пакета от указания перегруженной сигнализацией ECN на этапе предотвращения перегрузки. Для достижения этого ABE использует другой коэффициент масштабирования для уравнения 4 в разделе 3.1 [RFC5681]. В описании соответственно используются beta_ {loss} и beta_ {ecn} для ссылки на мультипликативные коэффициенты уменьшения, применяемые в ответ на предполагаемую потерю пакета и в ответ на приемник, указывающий перегруженную сигналом ECN. Для TCP-соединений без поддержки ECN применяется только beta_ {loss}.

Другими словами, в ответ на предполагаемую потерю пакета:

ssthresh = max (FlightSize * beta_{loss}, 2 * SMSS)

и в ответ на указание перегруженного сигналом ECN:

ssthresh = max (FlightSize * beta_{ecn}, 2 * SMSS)
и
cwnd = ssthresh

(Если ssthresh == 2 * SMSS, раздел 6.1.2 RFC 3168 предоставляет руководство по установке cwnd ниже, чем 2 * SMSS.)

где FlightSize — это объем ожидающих данных в сети, ограниченный сверху меньшим из cwnd отправителя и объявленного окна получателя (rwnd) [RFC5681]. Чем выше значения beta_ {loss} и beta_ {ecn}, тем менее агрессивен ответ любого отдельного события отката.

Подходящим выбором для значений beta_ {loss} и beta_ {ecn} является баланс между использованием пути и опустошением очереди. Более агрессивный откат (меньшая бета_ *) рискует недостаточно использовать путь, в то время как менее агрессивный откат (большая бета_ *) может привести к более медленному истощению очереди с узким местом.

Интернет уже работает по крайней мере с двумя различными значениями beta_ {loss} в течение нескольких лет: стандартное значение равно 0,5 [RFC5681], а реализация CUBIC для Linux [RFC8312] использует множитель 0,7 с версии ядра 2.6.25. выпущен в 2008 году. ABE не изменяет значение beta_ {loss}, используемого в текущих реализациях TCP.

Рекомендация в этом документе указывает значение beta_ {ecn} = 0,8. Это рекомендуемое значение beta_ {ecn} применимо только для стандартного управления перегрузкой TCP [RFC5681]. Выбор beta_ {ecn} позволяет настроить отклик TCP-соединения на небольшие пороговые значения AQM-маркировки. beta_ {loss} характеризует реакцию алгоритма управления перегрузкой на потерю пакетов, то есть исчерпание буферов (неизвестной глубины). Различные значения для beta_ {loss} были предложены для алгоритмов управления перегрузкой TCP. Следовательно, бета_ {ecn}, скорее всего, будет параметром, специфичным для алгоритма, а не постоянным кратным существующей бета_ {потери} алгоритма.

Ряд тестов (раздел IV [ABE2017]) с NewReno и CUBIC поверх CoDel и PIE в сценариях с небольшим мультиплексированием исследовали этот выбор параметра. Результаты этих тестов показывают, что соединения CUBIC выигрывают от beta_ {ecn} 0,85 (ср. Beta_ {loss} = 0,7), а соединения NewReno видят улучшения с beta_ {ecn} в диапазоне от 0,7 до 0,85 (ср. Beta_ {loss) } = 0,5).

4. Дискуссия

Большая часть технического фона для ABE может быть найдена в [ABE2017], который использует сочетание экспериментов, теории и моделирования с NewReno [RFC5681] и CUBIC [RFC8312] для оценки его производительности. Было показано, что ABE демонстрирует значительный прирост производительности в сценариях с небольшим мультиплексированием (несколько одновременных потоков), не теряя преимуществ, связанных с уменьшением задержки при развертывании CoDel или PIE. Улучшение производительности достигается при реагировании на ECN-эхо в предотвращении перегрузки (когда ssthresh> cwnd) путем умножения cwnd и ssthresh на значение в диапазоне [0.7,0.85]. Применение ABE, когда cwnd меньше или равно ssthresh, в настоящее время не рекомендуется, но его использование в этом сценарии может выиграть от дополнительного внимания, экспериментов и спецификаций.

4.1. Обоснование использования ECN для изменения степени отсрочки

Механизмы AQM, такие как CoDel [RFC8289] и PIE [RFC8033], устанавливают цель задержки в маршрутизаторах и используют уведомления о перегрузке для ограничения задержек в очереди, испытываемых пакетами, а не в ответ на надвигающееся или фактическое исчерпание буфера узкого места. С текущими заданными значениями задержки по умолчанию CoDel и PIE эффективно эмулируют узкое место с короткой очередью (Раздел II [ABE2017]), а также допускают короткие всплески трафика в очередь. Это обеспечивает приемлемую производительность для соединений TCP по тракту с низким BDP или в сценариях с высокой степенью мультиплексирования (много одновременных транспортных потоков). Однако в случае небольшого мультиплексирования по тракту с большим BDP обычный откат TCP приводит к перерывам в передаче пакетов и неполному использованию пути.

Вместо отбрасывания пакетов механизму AQM разрешается помечать пакеты, поддерживающие ECN, знаком ECN CE. Прием обратной связи с меткой CE не только указывает на перегрузку на сетевом пути, но также указывает на наличие механизма AQM в узком месте на пути. Таким образом, знак CE, вероятно, возник из узкого места с контролируемой короткой очередью. Реакция по-другому на перегруженную сигналом ECN, нежели на предполагаемую потерю пакета, может затем дать преимущество уменьшенного отката при коротких очередях. Использование ECN также может быть полезным по ряду других причин [RFC8087].

Идея по-разному реагировать на предполагаемую потерю пакетов и обнаружение перегруженности, сигнализируемой ECN, предшествует этой спецификации, например, предыдущее исследование, предложенное с использованием обратной связи, помеченной знаком ECN CE, для изменения поведения управления перегрузкой TCP через больший мультипликативный коэффициент уменьшения в сочетании с меньшей добавкой коэффициент увеличения [ICC2002]. Целью этой предыдущей работы была работа с узкими местами AQM (с использованием раннего раннего обнаружения (RED)), которые не обязательно были настроены для эмуляции короткой очереди. (В настоящее время использование RED в качестве метода AQM в Интернете ограничено [RFC7567].)

4.2. Ответ на основе RTT для указанного затора

Эта спецификация применяется к использованию обратной связи ECN, как определено в [RFC3168], которая определяет реакцию на указанную перегрузку, которая не чаще, чем один раз за время прохождения сигнала в обоих направлениях. Поскольку ABE отвечает на указанную перегрузку один раз за RTT, она не отвечает на любые дальнейшие потери в том же RTT, поскольку отправитель ABE уже уменьшил окно перегрузки. Если перегрузка сохраняется после такого уменьшения, ABE продолжает уменьшать окно перегрузки в каждом последовательном RTT. Это последовательное сокращение может защитить сеть от давней несправедливости в случае алгоритмов AQM, которые не сохраняют небольшую среднюю длину очереди. Механизм не полагается на точный ECN [ACC-ECN-FEEDBACK].

Напротив, механизмы транспортного протокола также могут быть разработаны для использования более частой и детальной обратной связи ECN (например, точного ECN [ACC-ECN-FEEDBACK]), которая затем разрешает ответ управления перегрузкой, который регулирует частоту отправки более часто. Центр обработки данных TCP (DCTCP) [RFC8257] является примером такого подхода.

5. Требования к развертыванию ABE

Это обновление относится только к отправителю. Как и другие изменения в алгоритмах управления перегрузкой, он не требует каких-либо изменений в приемнике TCP или сетевых устройствах. Он не требует каких-либо специфических для ABE изменений в маршрутизаторах или использования точной обратной связи ECN [ACC-ECN-FEEDBACK] получателем.

Если метод используется только некоторыми отправителями, а не другими, отправители, использующие его, могут получить некоторое преимущество, возможно, за счет других потоков, которые не используют этот обновленный метод. Поскольку это преимущество применяется только к пакетам с маркировкой ECN, а не к указаниям на потерю пакетов, узкое место, способное к ECN, все равно будет отбрасывать пакеты, если отправитель TCP, использующий ABE, слишком агрессивен. Результат ничем не отличается от того, если бы отправитель TCP использовал традиционный контроль перегрузок на основе потерь.

При использовании с узкими местами, которые не поддерживают маркировку ECN, спецификация не изменяет транспортный протокол.

6. Экспериментальные цели ABE

[RFC3168] утверждает, что ответ управления перегрузкой после указания перегруженной сигналом ECN такой же, как ответ на отброшенный пакет. [RFC8311] обновляет эту спецификацию, чтобы позволить системам обеспечивать другое поведение, когда они испытывают перегруженный сигналом ECN, а не потерю пакета. Настоящее описание определяет такой эксперимент и представляет собой экспериментальный RFC. Мы рассчитываем предложить его в качестве документа для отслеживания стандартов в будущем.

Цель эксперимента в Интернете — собрать опыт развертывания ABE и подтвердить приемлемую безопасность в развернутых сетях, которые используют это обновление для контроля перегрузки TCP. Чтобы оценить ABE, этот эксперимент требует поддержки в маршрутизаторах AQM для ECN-маркировки пакетов, содержащих транспортную кодовую точку ECT-Capable ECT (0) [RFC3168].

Результат этого интернет-эксперимента должен включать в себя исследование последствий появления знака ECN-CE с последующей потерей в том же RTT. В конце эксперимента об этом будет сообщено Рабочей группе TCPM или IESG.

ABE реализован как патч для Linux и FreeBSD. Он предназначен для исследований и экспериментов и доступен для загрузки по адресу <https://heim.ifi.uio.no/michawe/research/abe/>. Этот код был использован для получения результатов испытаний, о которых сообщается в [ABE2017]. Код FreeBSD был добавлен в основное ядро 19 марта 2018 года [ABE-REVISION].

7. Соображения IANA

В этом документе нет действий IANA.

8. Вопросы безопасности

Описанный способ является изменением транспорта только на стороне отправителя и не изменяет обмен протокольными сообщениями. Поэтому соображения безопасности для ECN [RFC3168] все еще применяются.

Это изменение в управлении перегрузкой TCP с помощью ECN, которое обычно приводит к изменению пропускной способности, достигаемой, когда потоки разделяют узкое место в сети. Это может привести к тому, что некоторые потоки получат больше, чем их справедливая доля емкости. Подобная несправедливость в отношении того, как совместно используется емкость, проявляется и в других механизмах контроля перегрузки, которые использовались в Интернете в течение многих лет (например, CUBIC [RFC8312]). Несправедливость также может быть результатом других факторов, включая время прохождения потока туда и обратно. ABE применяется только при получении пакетов, помеченных ECN, а не при их потере. Следовательно, использование ABE не может привести к коллапсу заторов.

9. Ссылки

9.1. Нормативные ссылки

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, «The Addition of Explicit Congestion Notification (ECN) to IP», RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>.

[RFC5681] Allman, M., Paxson, V., and E. Blanton, «TCP Congestion Control», RFC 5681, DOI 10.17487/RFC5681, September 2009,
<https://www.rfc-editor.org/info/rfc5681>.

[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., «IETF Recommendations Regarding Active Queue Management», BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
<https://www.rfc-editor.org/info/rfc7567>.

[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L., and G. Judd, «Data Center TCP (DCTCP): TCP Congestion Control for Data Centers», RFC 8257, DOI 10.17487/RFC8257,
October 2017, <https://www.rfc-editor.org/info/rfc8257>.

[RFC8311] Black, D., «Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation», RFC 8311, DOI 10.17487/RFC8311, January 2018,
<https://www.rfc-editor.org/info/rfc8311>.

9.2. Информационные ссылки

[ABE-REVISION] Stewart, L., «ABE patch review in FreeBSD», Revision 331214, March 2018, <https://svnweb.freebsd.org/base?view=revision&revision=331214>.

[ABE2017] Khademi, N., Armitage, G., Welzl, M., Zander, S., Fairhurst, G., and D. Ros, «Alternative backoff: Achieving low latency and high throughput with ECN and AQM», IFIP
Networking Conference and Workshops Stockholm, Sweden, DOI 10.23919/IFIPNetworking.2017.8264863, June 2017.

[ACC-ECN-FEEDBACK] Briscoe, B., Kuehlewind, M., and R. Scheffenegger, «More Accurate ECN Feedback in TCP», Work in Progress, draft-ietf-tcpm-accurate-ecn-07, July 2018.

[BUFFERBLOAT] Gettys, J. and K. Nichols, «Bufferbloat: Dark Buffers in the Internet», ACM Queue, Volume 9, Issue 11, DOI 10.1145/2063166.2071893, November 2011,
<https://queue.acm.org/detail.cfm?id=2071893>.

[ICC2002] Kwon, M. and S. Fahmy, «TCP increase/decrease behavior with explicit congestion notification (ECN)», 2002 IEEE International Conference on Communications Conference
Proceedings, ICC 2002, Cat. No.02CH37333, DOI 10.1109/ICC.2002.997262, May 2002,
<http://dx.doi.org/10.1109/ICC.2002.997262>.

[RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, «Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem», RFC 8033, DOI 10.17487/RFC8033, February 2017,
<https://www.rfc-editor.org/info/rfc8033>.

[RFC8087] Fairhurst, G. and M. Welzl, «The Benefits of Using Explicit Congestion Notification (ECN)», RFC 8087, DOI 10.17487/RFC8087, March 2017,
<https://www.rfc-editor.org/info/rfc8087>.

[RFC8289] Nichols, K., Jacobson, V., McGregor, A., Ed., and J. Iyengar, Ed., «Controlled Delay Active Queue Management», RFC 8289, DOI 10.17487/RFC8289, January 2018,
<https://www.rfc-editor.org/info/rfc8289>.

[RFC8312] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and R. Scheffenegger, «CUBIC for Fast Long-Distance Networks», RFC 8312, DOI 10.17487/RFC8312, February 2018,
<https://www.rfc-editor.org/info/rfc8312>.

Благодарности

Авторы Н. Хадеми, М. Вельцль и Г. Фэрхерст были частично профинансированы Европейским сообществом в рамках его Седьмой рамочной программы в рамках проекта по сокращению интернет-задержки (RITE) (ICT-317700). Мнения, высказанные исключительно за авторов.

Автор Г. Армитидж выполнил большую часть своей работы над этим документом, когда работал в Технологическом университете Суинберна, Мельбурн, Австралия.

Авторы хотели бы поблагодарить Стюарта Чешира за множество предложений при пересмотре этого документа. Они также хотели бы поблагодарить следующих людей за их вклад в [ABE2017]: Чамиля Кулатунгу, Дэвида Роса, Стейна Гессинга и Себастьяна Цандера. Также спасибо (в алфавитном порядке) Дэвиду Блэку, Роланду Блессу, Бобу Бриско, Маркку Кожо, Джону Лесли, Лоуренсу Стюарту и Рабочей группе TCPM за предоставление ценных отзывов об этом документе.

Наконец, авторы хотели бы поблагодарить всех, кто предоставил отзыв о поведении по контролю перегрузок, указанному в этом документе, который был получен от исследовательской группы IRTF по контролю перегрузок в Интернете (ICCRG).

Адреса авторов

Naeem Khademi
University of Oslo
PO Box 1080 Blindern
Oslo N-0316
Norway
Email: naeemk@ifi.uio.no

Michael Welzl
University of Oslo
PO Box 1080 Blindern
Oslo N-0316
Norway
Email: michawe@ifi.uio.no
Grenville Armitage
Netflix Inc.
Email: garmitage@netflix.com

Godred Fairhurst
University of Aberdeen
School of Engineering, Fraser Noble Building
Aberdeen AB24 3UE
United Kingdom
Email: gorry@erg.abdn.ac.uk

Поделись записью