Кратко

  • RFC 1152, опубликованный в апреле 1990 года, сохранил материалы семинара по очень быстрым сетям. По мнению David Clark, существующие протоколы могли бы работать на гигабите в секунду, если бы требовалась только такая скорость; расстояние, число пользователей и новые услуги меняли задачу.
  • Keith Lantz говорил о низкой задержке и синхронизации разных медиа. Craig Partridge изучал ожидание удалённого вызова. Предварительные результаты Nectar показали разницу между обменом на коммуникационных платах и доставкой данных программам хоста.

Красивое число встретилось с техническим заданием

Семинар проводился при поддержке Internet Research Steering Group, связанной с IRTF. Craig Partridge составил отчёт по материалам руководителей сессий; участники проверили эти записи. Получилась полезная картина не единодушия, а выбора. Каждое предложение ускорить сеть начинало отвечать на свой набор требований.

David Clark открыл обсуждение реализации замечанием, которое остужало желание немедленно менять весь набор протоколов. Если цель сводится к гигабиту в секунду, существующих протоколов, по его оценке, достаточно. Но сеть предлагалось растянуть на большие расстояния, открыть многим пользователям и дополнить услугами вроде резервирования полосы. Только подробный список требований позволял сравнивать архитектуры. Рядом прозвучали идеи специализированных процессоров и более умных реализаций известных протоколов. Заголовок с числом сам по себе не говорил, какая схема нужна.

Keith Lantz описал «переносной офис» со стороны пользователя. Важна была возможность обращаться к тем же людям и услугам из дома, кабинета или поездки, а не вес самого компьютера. Настольная конференция совмещала текст, графику, звук и видео. Потокам требовались очень разные полосы, обычно малая задержка и иногда слабые колебания времени доставки. Их ещё нужно было согласовать друг с другом. Картинка с задержавшимся голосом быстро превращает демонстрацию широкой линии в комедию положений.

Lantz предлагал адаптировать протоколы к перегрузке, медленным участкам и изменению качества изображения. Пользователь не обязан жить на самом быстром отрезке пути. Если маршрут меняет возможности, приложение должно найти приемлемый способ продолжить разговор.

Быстрый процессор дороже ждёт

В секции распределённых систем Partridge взял удалённый вызов процедуры. Машины ускорялись, но время ответа далёкого узла по-прежнему включало путь туда и обратно. Скорость света не обновлялась вместе с процессором. Поэтому ожидание ответа стоило всё больше вычислительных циклов. Параллельные запросы помогают независимым задачам; цепочка, где следующий шаг зависит от предыдущего ответа, остаётся прикована к каждому рейсу.

Большой кеш убирает часть запросов, однако его копии требуют согласования. В итоге система может посылать вызовы синхронизации, чтобы не посылать обычные вызовы. Partridge предлагал объединять работу для одного удалённого узла в более крупную операцию. Другие участники защищали предварительную загрузку и асинхронные подходы. Отчёт честно сохраняет расхождение: каждый способ боролся с ожиданием, перенося затраты в другое место.

Эксперимент Nectar в Carnegie Mellon показал ещё один предел. По предварительным цифрам, приведённым в RFC, процессы на коммуникационных платах обменивались данными на 70 Mbps, а процессы на хостах достигали примерно 25 Mbps из-за интерфейса VME. Речь шла об определённом прототипе. Его пример объяснял, как скорость теряется после прохождения линии. Jeff Mogul добавил стоимость переноса пакетов в кеш процессора и уведомления пользовательской программы. Сеть доставляла пакет к машине; машине ещё предстояло доставить его до дела.

Семинар не вынес рецепта в одну строку. Он расширил понятие результата: ответ удалённой системы, совместное время звука и видео, поведение на медленном участке и путь данных через хост. Гигабитная связь получала аплодисменты первой. Программа оценивала спектакль только после возвращения ответа.