IP фрагментация

Unanswered Question
May 23rd, 2012

Добрый день коллеги, хотелось бы задать вопрос из области общих знаний. Допустим мы имеем фрагментированный пакет который передается по сети, из теории следует:

"Если хотя бы один фрагмент утерян — весь пакет должен быть отправлен заново."

Но почему? Неужели нельзя запросить отдельно фрагмент?

pmtud_ipfrag_02.gif

Картинка взята с http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml
Т.е. имеем потерю фрагмента sequence 0-2 мы легко определяем границы нехватающих данных (1501-3000-й байты) по остальным фрагментам (Fragment offset). Конечно если мы не получили последний фрагмент, где MF (more fragment) флаг 0, то мы не знаем последний фрагмент это или нет, но с остальными фрагментами таких проблем нет.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 0 (0 ratings)
Ivan Krimmel Wed, 05/23/2012 - 11:19

Привет Павел,

а кто или что делает фрагментацию?

Pavel Doronin Wed, 05/23/2012 - 19:38

Допустим так. В скобках MTU.

HOST(1500)----(1500)ROUTER1(576)-----(576)ROUTER2(1500)---(1500)HOST

Хост послал пакет 1500 байт, ROUTER1 разбил их на 3 фрагмента и отправил на ROUTER2, допустим потеряли 2-й фрагмент, есть 1-й и 3-й.

1-й

572 байта = 20  +   552          offset =0

                        IP    TCP+data

                       байты 0-552

2-й

572 байта= 20  +   552          offset =69 (data from 1-st byte/8=552/8=69)

                       IP    data only

                      байты 553-1104

3-й

376 байта = 20  +   356          offset =138 ((data from1-st byte+ data from 2-nd byte)/8 = (552+552)/8=138)

                        IP    data only

                       байты 1105-1500

Из того что мы потеряли 2-й фрагмент можно вычислить какие байты потеряны по offset'ам. Имеем offset 0 и 552 байта данных и offset 138 и 356 байт данных. Т.е. по фрагменту 1 можно вычмслить offset 2-го фрагмента (69). По фрагменту 3 мы знаем offset 138, имея эти данные мы знаем что недостает данных с 69 по 138 offset. т.е. с 69*8+1=553 по 138*8=1104.

nkarpysh Wed, 05/23/2012 - 20:04

Добрый День.

ИМХО:

Проблема в том, что спрашивать не у кого.

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

По крайней мере я так понимаю.

Николай.

Pavel Doronin Wed, 05/23/2012 - 22:20

Ну у роутера никак не спросит это точно, ведь то у стройство которое фрагментирует не оставляет о себе никаких сведений. Собирает фрагменты конечный получатель, и только он может знать что утеряны фрагменты. В чем проблема спросить у хоста отправителя?  Ведь отправитель пока не получил подтверждение о получении пакета держит его в буфере (для ретрансляции при потере). Что мешает реализовать функционал запроса частичных даннных у хоста отправителя с такого-то по такой бит? Единственно что отправитель должен будет отправить пакет отформатированный как фрагмент а не как обычный. Т.е. с офффсетом и флагами. Также отправитель может не держать его в буфере для ожидания подтверждения.

Даже имея TCP заголовок только в первом фрагменте мы может запросить данные у отправителя по полю IDENTIFIER

nkarpysh Wed, 05/23/2012 - 23:13

Одна из теоритических проблем в следующем.

Предположим, что на получателе мы потеряли фрагмент 2. Мы идентифицировали sequence пакета, те мы знаем, какой пакет спросить у источника. Также мы знаем какие биты мы потеряли. Мы в итоге запрашиваем их. Источник - даже если у него будет функционал из определенного пакеты вычленять определенные биты, должен будет навесить на такой пакет помимо фрагментационного заголовка еще и транспортный заогловок, чтобы пакет смог маршрутизироваться. Этот транспортный заголовок должен иметь новый бит, говорящий, что внутри специальный пересланный пакет,  а не просто IP пакет.

В итоге получаем 2-ную инкапсуляцию как минимум + опять этот пакет будет больше МТУ - так как он равен МТУ (потерянные биты + заголовок фрагментации) + новый IP заголовок.  И мы опять его будем фрагментировать. Те даже если все пройдет гладко - особой выгоды мы не получим - может даже будет бОльшая задержка (так как по сравнению с простой пересылкой пакета - добавиться время на вычленение части пакета на источнике + какая-то новая обработка таких кусков на получателе).

Опять - всего лишь размышления.

Николай

Pavel Doronin Thu, 05/24/2012 - 00:11

Не совсем понял про 2-ю инкапсуляцию. Получатель не поймет такой пакет.

При отправке фрагмента на источнике нет нужды в двойной инкапсуляции, т.е. не инкапсулируем фрагмент в новый IP пакет, а пересылаем IP пакет в котором помимо IP адресов еще заполняем поле  offset и флаги, соответственно получатель поймет его как фрагмент.

Ivan Krimmel Wed, 05/23/2012 - 23:21

Коллеги,

хотя в случае с IPv6 фрагментация выполняется на хостах, искомый функционал добавит сложности при том что выигрыш от гранулярной ретрансмиссии потерянных фрагментов стремится к нулю, как мне кажется.

Иван.

Ivan Krimmel Thu, 05/24/2012 - 02:02

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

Иван.

Pavel Doronin Thu, 05/24/2012 - 03:05

Ошибки ушли бы со временем.

Скорее всего дело вот в чем: восстанавливать фрагменты можно только посредством самого IP протокола, а не средствами TCP.

Фрагментируется IP а не TCP или любой другой транспортный протокол. Перед тем как передать весь пакет с уровня IP на уровень выше (TCP, UDP и т.д.), пакет должен быть полностью собран. Если мы потеряли фрагмент, мы не можем передать фрагмент на уровень выше. Т.е. мы должны умудрится восстановить пакет средствами самого IP! Для этого надо было бы превратить сам IP в TCP, т.е. сделать алгоритм его работы таким же как у TCP. Т.е. TCP ждет получение подтверждения занимая буфер и IP ждет подтверждения занимая буфер. Т.e. помимо TCP ACK, нам бы потребовалось что-то вроде бы IP ACK.

dleontye Thu, 05/24/2012 - 13:23

Павел, разрешите вставить свои пять копеек.

Все о чем вы говорите уже было в жизни сетей. Достаточно вспомнить хотя бы стек проктоколов X.25, в котором протокол на каждом уровне - канальном, сетевом, транспортном был надежным протоколом с установлением соединения и подтверждениями (читай вел себя как TCP). Так вот, эти все протоколы вымерли как мамонты (кто мне подскажет, Х.28 когда перестали использовать для подключения банкоматов ?). Потому что эти протоколы создавались для работы по плохим линиям с большим количеством ошибок и маленькой скоростью передачи. И лучше всего было на каждом сегменте проконтролировать правильность передачи. С появлением более менее скоростных и надежных линий связи (читай доступности оптоволоконных каналов), стали отказываться от многоуровневой проверки правильности передаваемой информации, для того чтобы минимизировать задержки (Frame Relay, ATM). Так как легче передать испорченный (с малой вероятностью) пакет целиком или последовательность пакетов, начиная с испорченного, оставляя один протокол в стеке, который будет заниматься контролем передачи, чем контролировать правильность передачи кадров на каждом уровне, утяжеляя стек протоколов и увеличивая задержки. Собственно тоже самое можно сказать и о паре протоколов для ЛВС Ethernet vs Token Ring.

Т.е. накладные расходы по восстановлению фрагмента испорченной информации выше, чем передача заново блока информации, содержащего испорченный фрагмент.

Pavel Doronin Thu, 05/24/2012 - 18:35

О чем и речь, что в IP нет возможности восстановить утеряные фрагменты/пакеты, поэтому потеря фрагмента/пакета = потере пакета.

Хотелось бы немного уточнить (в рамках познания истории) - X.25 это протокол всего-лишь канального уровня, откуда там взялся надежный сетевой?

otipisov Sat, 06/09/2012 - 11:53

Любопытная дискуссия. X.25 всю жизнь был протоколом сетевого уровня, а на канальном уровне там работал LAPB.

dleontye Sat, 06/09/2012 - 14:03

Эх, скоро совсем забудем то, что долгие годы служило на благо цивилизации. Я имею ввиду протоколы Х-стека. На физическом уровне можно было использовать например Х.21, на канальном уровне работал X.25 канального уровня (Х.25/2) или LAPB, на сетевом уровне X.25 сетевого уровня (Х.25/3) или PLP, на транспортном Х.224, на уровне приложений Х.400, Х.500. Вот тут немного теории http://docwiki.cisco.com/wiki/X.25

Хороший был стек, надежный. Правительственные организации до начала 2000 годов на нем работали, банковские структуры, например S.W.I.F.T. Кстати многие с X.25 перешли впоследствии на MPLS.

Вот нашел новость в архивах о таком переходе http://www.global-one.by/resource/news/040707.html

Pavel Doronin Tue, 06/12/2012 - 22:13

Делайте скидку на то что некоторые ещё институт не закончили в 2004 году ))), а там уже не преподавали X-стеки. Видимо уже не актуально было.

Actions

Login or Register to take actions

This Discussion

Posted May 23, 2012 at 12:18 AM
Stats:
Replies:15 Avg. Rating:
Views:911 Votes:0
Shares:0
Tags: No tags.