1.3 Размер поля информации

Уже говорилось, что размер поля данных в пакетах АТМ должен быть достаточно маленьким. Однако, необходимо было определить, какой именно. Прежде всего дебаты разгорелись вокруг вопроса, делать ли пакет переменной или постоянной длины. Первым предложением было сделать пакеты фиксированной длины размером всего 16 байт. На самом деле как у переменной, так и у постоянной длины есть свои выгоды и недостатки. При этом исходили из оценки эффективности использования канала, затрат на коммутацию, сложности реализации и задержки.

Ясно, что с точки зрения использования канала переменная длина пакета предпочтительнее, поскольку если сообщение короткое или его длина не кратна фиксированному размеру пакета, то потребуется дополнять последний пакет до полного объема, на что уходит пропускная способность. Кроме того, при постоянной длине пакета придется вводить дополнительные функции в заголовок данных для того, чтобы определять, где именно в составе пакета кончаются пользовательские данные и начинаются биты заполнения (впрочем, это можно делать и на более высоком уровне).

С другой стороны, чем длиннее сообщение, тем это преимущество переменной длины менее заметно, поскольку доля вносимой избыточности становится малой по сравнению с пользовательскими данными - ведь дополнять объем поля данных до фиксированного размера придется только последнему пакету. Если же пакет переменной длины, то все равно придется вносить особые функции в заголовок с целью определения границ пакета наподобие того, как это делается в процедуре HDLC. Тем более, что все равно нужно как-то ограничивать максимальную длину - нельзя же допускать размер пакета, исчисляемый килобайтами!

В целом можно сказать, что с точки зрения эффективности использования канала переменная длина пакета выгоднее, чем постоянная, правда, очень незначительно.

Что касается затрат на коммутацию, и сложности реализации, то на это влияют два основных фактора: скорость обработки данных и требования по размеру памяти.

Скорость обработки зависит от объема операций и времени, отводимой на это. Одной из важных функций системы АТМ является обработка заголовка. Предположим, что заголовок обрабатывается независимо от того, используется ли переменная или постоянная длина пакета. Для того, чтобы работать в реальном времени, необходимо успеть обработать заголовок пакета за время приема следующего пакета. Если система рассчитана на работу со скоростью 150 Мбит/сек, то при длине пакета 53 байта это время составит 2.8 мксек. Если же представить себе систему с переменной длиной пакета, то ориентироваться по скорости обработки нужно на наихудший случай, т.е. когда пакет имеет минимальную длину, например, 10 байт. В этом случае при той же скорости заголовок должен быть полностью обработан за 533 наносекунды, т.е. требования по быстродействию значительно ужесточаются.

Что касается требований по управлению памятью, то в случае фиксированной длины пакета резервировать память гораздо проще. В случае переменной длины, резервировать память пришлось бы в расчете на максимальную длину, что менее производительно и экономно, или же динамически резервировать память побайтно, что значительно сложнее.

В отношении задержки можно сказать, что она напрямую зависит от длины пакета, и эта длина не может быть очень большой, поскольку в противном случае задержки передачи возрастают. Действительно, когда поток битов от пользователя поступает в сеть, то при формировании пакета первый бит должен ждать, пока придет последний, и только когда объем накопленной информации будет достаточным для заполнения пакета, он будет отправлен в канал. Следовательно, чем больше пакет, тем дольше будет информация ожидать в передатчике момента начала передачи. Поэтому при больших длинах пакетов становится проблематичной передача видео и голоса. Поэтому, даже, если и делать пакеты переменной длины, она сможет варьироваться в очень узких пределах.

Таким образом, преимущества переменной длины пакета над постоянной ничтожны, и в результате МККТТ остановился на принятии пакетов фиксированной длины. Ввиду этого возникла необходимость называть этот блок данных по-другому, поскольку существующее слово "пакет" означает блок данных произвольной длины. Остановились на слове "cell" , что в дословном переводе означает "ячейка". Однако, поскольку мне не попадались официальные переводы соответствующих документов на русский язык, которых может быть и не существует, я не возьму на себя смелость давать самостоятельный невыверенный перевод этого слова и в дальнейшем изложении буду называть его в английской транскрипции - СЕЛЛ.

Когда МККТТ выбирал конкретное значение длины селла, то при этом принималась во внимание использование канала, задержка передачи и сложность реализации. С точки зрения использования канала лучше сделать селл побольше, т.к. при этом доля служебной информации - заголовки - уменьшается, однако, чем больше длина селла, тем больше задержка в сети. Далее, чем больше длина селла, тем больше времени у системы на обработку заголовка, что упрощает построение коммутатора, но при этом ему требуется большая память, которая чем больше, тем медленнее. Все дебаты по выбору длины селла вращались вокруг диапазона между 32 и 64 байтами.

На задержку коммутации влияет во многом соотношение между длиной заголовка и длиной поля данных. Эта зависимость представлена на рис.3. Расчеты производились исходя из скорости каналов в 150 Мбит/сек. По оси абсцисс отложено отношение длины поля данных к длине заголовка. Попробуем физически объяснить поведение этих графиков.

При росте длины поля L увеличивается время обслуживания селлов в очереди, т.е. увеличивается задержка. Это происходит потому, что требуется больше времени для считывания данных из очереди и записи в нее. С другой стороны, при очень маленьких значениях L время обработки увеличивается из-за того, что селлов становится очень много, и объем заголовка относительно возрастает, следовательно, возрастает и время обслуживания, поскольку нужно изучить много таких заголовков.

В результате долгих дебатов, когда обсуждалось два предложения - сделать поле данных селла 32 или 64 байта, было принято решение выбрать середину - 48 байт, на которые накладываются еще пять байт заголовка - итого 53 байта.