Alexander Shikoff wrote:

Приветствую!

On Fri, Nov 09, 2012 at 10:31:47AM +0200, Alexandr Turovsky wrote:

...

Доброе утро коллеги .

Вообщем предистория такова , что у клиента имеется клиент-серверное приложение , которое не терпит "пропадание 1-2-4 пакетов" в сеансе связи , технологически имеем разветвленную сеть (точка-многоточка) , на каждый конечный сайт заходит 2 канала передачи данных , как L2 транспорт так и L2 поверх L3 . Каналы от 1 до 5 мбит/с , скорость передачи данных в каналах -<<1мбит/с .

На текущий момент поднят протокол RSTP , который плохо работает .

Есть ли решения , которые позволяют избежать "в конечном канале" для клиента потерь пакетов и имеет быструю (очень) скорость переключения работоспособного канала ?

(нв голову приходит что то типа потока Е1 овер L2 , но по IP и резервированием )

Как вариант: завязать все точки на Layer3 и использовать какой-то протокол динамической маршрутизации с BFD.

Думал, пробовал, варианты OSPF или BGP+BFD не подходит :)

On Fri, Nov 09, 2012 at 10:31:47AM +0200, Alexandr Turovsky wrote:

Доброе утро коллеги .

Вообщем предистория такова , что у клиента имеется клиент-серверное приложение , которое не терпит "пропадание 1-2-4 пакетов" в сеансе связи

Разработчиков, которые тупо переносят протоколы, ориентированные на сети с коммутацией каналов, на интернет с коммутацией пакетов (и, как следствие, негарантированностью доставки, jitter'ом и reordering'ом) нужно убивать из рогатки еще в детстве...

, технологически имеем разветвленную сеть (точка-многоточка) , на каждый конечный сайт заходит 2 канала передачи данных , как L2 транспорт так и L2 поверх L3 . Каналы от 1 до 5 мбит/с , скорость передачи данных в каналах - <<1мбит/с .

На текущий момент поднят протокол RSTP , который плохо работает .

Есть ли решения , которые позволяют избежать "в конечном канале" для клиента потерь пакетов и имеет быструю (очень) скорость переключения работоспособного канала ? (нв голову приходит что то типа потока Е1 овер L2 , но по IP и резервированием )

Взять поток на источнике, реплицировать в несколько потоков (каждый - по своему маршруту), на приёмнике - "лишние" пакеты убрать (плюс, возможно, провести dejitter) ? Тупо, overhead дикий, но работает... -- In theory, there is no difference between theory and practice. But, in practice, there is.

а udp завернуть в tcp-канал ? tcp с подтверждением, соответственно в теории пакеты теряться не должны. 9 ноября 2012 г., 11:29 пользователь Alexandr Turovsky написал:

Alexander V Soroka wrote:

...

Привет !

Выбранными тобой средствами, особенно извратом "телефония поверх IPv.4 данная задача не решается. "Телефонными" классическими средствами - решается на ура.

Все что могу посоветовать - убрать все источники "пиковых" набросов трафика в сеть, и поднять в два раза пропускную способность каналов. Это может полегчать, но не на 100%.

Трафик маленький около 100-200кбит/с и не пиковый . Нужно убрать редкие пропадания пакетов , или так есть протокол UDP , нужно добится аппаратно-программными средствами отсутствия пропадания пакетов . Протокол обмена в схеме клиент-сервер , заменить невозможно .

...

Friday, November 9, 2012, 10:31:47 AM, you wrote: AT> Вообщем предистория такова , что у клиента имеется клиент-серверное AT> приложение , которое не терпит "пропадание 1-2-4 пакетов" в сеансе связи AT> , технологически имеем разветвленную сеть (точка-многоточка) , AT> на каждый конечный сайт заходит 2 канала передачи данных , как L2 AT> транспорт так и L2 поверх L3 . Каналы от 1 до 5 мбит/с , скорость AT> передачи данных в каналах -<<1мбит/с .

AT> Есть ли решения , которые позволяют избежать "в конечном канале" для AT> клиента потерь пакетов и имеет быструю (очень) скорость переключения AT> работоспособного канала ?

AT> (нв голову приходит что то типа потока Е1 овер L2 , но по IP и AT> резервированием )

Привет! Транспорт через MPLS? Если да, то можно построить 2 статических RSVP-TE LSP туннеля через два разных маршрута и прописать, что если первый туннель падает, то переключать весь трафик во второй. Между всеми раутерами нужно поднять BFD. Если MPLS нет, то можно построить тоже самое на "обычном" RSVP (Resource Reservation Protocol), но сам такое не делал. Из плюсов: скорость переключения - "как у SDH", недостаток: все туннели/flows прийдется прописывать вручнуюю Best wishes, Maksym On 9 Nov 2012, at 09:31, Alexandr Turovsky wrote:

Доброе утро коллеги .

Вообщем предистория такова , что у клиента имеется клиент-серверное приложение , которое не терпит "пропадание 1-2-4 пакетов" в сеансе связи , технологически имеем разветвленную сеть (точка-многоточка) , на каждый конечный сайт заходит 2 канала передачи данных , как L2 транспорт так и L2 поверх L3 . Каналы от 1 до 5 мбит/с , скорость передачи данных в каналах - <<1мбит/с .

На текущий момент поднят протокол RSTP , который плохо работает .

Есть ли решения , которые позволяют избежать "в конечном канале" для клиента потерь пакетов и имеет быструю (очень) скорость переключения работоспособного канала ?

(нв голову приходит что то типа потока Е1 овер L2 , но по IP и резервированием )

L2 - по определению медленно сходящаяся среда, что бы вокруг нее ни придумывали. В кольцах еще более-менее разобрались, но как только топологии обретают не кольцевой вид, то опять надо их закольцовывать. А если, не дай бог, сеть из коммутаторов разных вендоров, то от STP деваться некуда :-) Да-да, придумали G.8032 или TRILL или 802.1aq, но, боюсь, оно пока есть далеко не во всех коммутаторах :-) По сути топика - 1) или, как предложил Снар, размножать трафик 2) или переписать приложение 3) или подсунуть ему хелпер, который UDP будет поверх TCP транспортировать - но этот вариант, конечно, сильно зависит от того, как написано приложение :-) если ему помимо потерь еще и задержку подавай гарантированную - то см. п.1 или 2 :-) -- /doka On Nov 9, 2012, at 3:54 PM, Andrew Stesin wrote:

Если изврат л2-овер-л3 заменить везде на честный л2 то глядишь и rstp окажется достаточен.

On Sun, Nov 11, 2012 at 11:26:45AM +0100, Maksym wrote:

Привет!

Транспорт через MPLS? Если да, то можно построить 2 статических RSVP-TE LSP туннеля через два разных маршрута и прописать, что если первый туннель падает, то переключать весь трафик во второй. Между всеми раутерами нужно поднять BFD.

Если MPLS нет, то можно построить тоже самое на "обычном" RSVP (Resource Reservation Protocol), но сам такое не делал.

Из плюсов: скорость переключения - "как у SDH", недостаток: все туннели/flows прийдется прописывать вручнуюю

.... есть еще один, наверное, самый главный, недостаток: в случае данного сферического приложения в ваккууме скорость схождения "как у SDH" совершенно недостаточна. Ему нужно не чтобы сеть сходилась а чтобы пакеты не терялись. _Вообще_ не терялись. Тот один пакет, который будет потерян за время схождения сети - это уже unacceptable :) Я уже скромно молчу, что потеря одного пакета в минуту не приводит к срабатыванию bfd (равно как и errored second не приводит к переключению на sdh), а на работе некоторых отдельно взятых приложений это сказывается крайне негативно. case studio: живая трансляция телевизера (iirc, в mpeg4). Одна crc-ошибка в три минуты - и всё, картинка рассыпается и "невозможно работать!" (c)(tm).

Best wishes, Maksym

On 9 Nov 2012, at 09:31, Alexandr Turovsky wrote:

...

Доброе утро коллеги .

Вообщем предистория такова , что у клиента имеется клиент-серверное приложение , которое не терпит "пропадание 1-2-4 пакетов" в сеансе связи , технологически имеем разветвленную сеть (точка-многоточка) , на каждый конечный сайт заходит 2 канала передачи данных , как L2 транспорт так и L2 поверх L3 . Каналы от 1 до 5 мбит/с , скорость передачи данных в каналах - <<1мбит/с .

На текущий момент поднят протокол RSTP , который плохо работает .

Есть ли решения , которые позволяют избежать "в конечном канале" для клиента потерь пакетов и имеет быструю (очень) скорость переключения работоспособного канала ?

(нв голову приходит что то типа потока Е1 овер L2 , но по IP и резервированием )

-- In theory, there is no difference between theory and practice. But, in practice, there is.

On Mon, Nov 12, 2012 at 08:06:22PM +0200, Vladimir Litovka wrote:

Снар, а кодирование подправить, чтобы I-frames чаще ходили?

По концам vpn'а стояло совершенно не наше оборудование...

Wrtten on soft keybord, sori for mistyps...

On Nov 12, 2012 6:12 PM, "Alexandre Snarskii" wrote:

On Sun, Nov 11, 2012 at 11:26:45AM +0100, Maksym wrote: > Привет! > > Транспорт через MPLS? Если да, то можно построить 2 статических RSVP-TE > LSP туннеля через два разных маршрута и прописать, что если первый туннель > падает, то переключать весь трафик во второй. Между всеми раутерами нужно > поднять BFD. > > Если MPLS нет, то можно построить тоже самое на "обычном" RSVP (Resource > Reservation Protocol), но сам такое не делал. > > Из плюсов: скорость переключения - "как у SDH", недостаток: все > туннели/flows прийдется прописывать вручнуюю

.... есть еще один, наверное, самый главный, недостаток: в случае данного сферического приложения в ваккууме скорость схождения "как у SDH" совершенно недостаточна. Ему нужно не чтобы сеть сходилась а чтобы пакеты не терялись. _Вообще_ не терялись. Тот один пакет, который будет потерян за время схождения сети - это уже unacceptable :)

Я уже скромно молчу, что потеря одного пакета в минуту не приводит к срабатыванию bfd (равно как и errored second не приводит к переключению на sdh), а на работе некоторых отдельно взятых приложений это сказывается крайне негативно.

case studio: живая трансляция телевизера (iirc, в mpeg4). Одна crc-ошибка в три минуты - и всё, картинка рассыпается и "невозможно работать!" (c) (tm).

> Best wishes, > Maksym > > On 9 Nov 2012, at 09:31, Alexandr Turovsky wrote: > > > Доброе утро коллеги . > > > > Вообщем предистория такова , что у клиента имеется клиент-серверное приложение , которое не терпит "пропадание 1-2-4 пакетов" в сеансе связи ,  технологически имеем разветвленную сеть (точка-многоточка)  , > > на каждый конечный сайт заходит 2 канала передачи данных , как L2 транспорт так и L2 поверх L3 . Каналы от 1 до 5 мбит/с , скорость передачи данных в каналах  - <<1мбит/с . > > > > На текущий момент поднят протокол RSTP  , который плохо  работает . > > > > Есть ли решения , которые позволяют избежать "в конечном канале" для клиента  потерь пакетов и имеет быструю (очень)  скорость переключения работоспособного канала ? > > > > (нв голову приходит что то типа потока Е1 овер L2 , но по IP и резервированием ) >

-- In theory, there is no difference between theory and practice. But, in practice, there is.

-- In theory, there is no difference between theory and practice. But, in practice, there is.

Решений таких точно нету, писать надо. Рид-Соломон позволяет исправлять битовые ошибки внутри пакета, с ситуацией когда пакет отбрасывается из-за перегрузки канала рид-соломон не поможет. Может не стоит изобретать велосипед, и попробовать разобраться почему не получается передать 100-200 kbps, что совсем не много, без потерь пакетов ?

On Fri, Nov 09, 2012 at 01:29:38PM +0400, Alexandre Snarskii writes:

AS> Взять поток на источнике, реплицировать в несколько потоков (каждый - AS> по своему маршруту), на приёмнике - "лишние" пакеты убрать (плюс, возможно, AS> провести dejitter) ? Тупо, overhead дикий, но работает...

Есть ли готовые решения для этой технологии? Типа туннеля, чтобы можно было задать два (три, четыре) маршрута, и чтобы это было не основной/запасной, а оба постоянно рабочих, и удалять дублирующие пакеты? Возможна отдельная проблема с reorder, но тоже разрешима. Или, в случае одного маршрута - передача с избыточностью, например, с использованием кода Рида-Соломона.

On Tue, Nov 13, 2012 at 02:21:33PM +0200, Sergey Smitienko writes: SS> Решений таких точно нету, писать надо. Рид-Соломон позволяет исправлять битовые ошибки SS> внутри пакета, с ситуацией когда пакет отбрасывается из-за перегрузки канала рид-соломон SS> не поможет. Может не стоит изобретать велосипед, и попробовать разобраться почему не SS> получается передать 100-200 kbps, что совсем не много, без потерь пакетов ? Разобраться-то можно, а вот исправить можно не всегда. Потому что не всегда причина потерь находится внутри сферы влияния. Конечно, если потери вызваны ограничением полосы пропускания, то избыточностью делу не поможешь: чем больше избыточность, тем больше потерь, и потери нужны именно для того, чтобы затормозить tcp и снизить нагрузку. Но если потери вызваны другими причинами, или если нужно сделать качественные 100K в канале, ограниченном на 20M (и QoS настроить нельзя, потому что он у провайдера) - тогда пригодилось бы. А такие задачи возникают не так уж редко.

...

On Fri, Nov 09, 2012 at 01:29:38PM +0400, Alexandre Snarskii writes:

AS>> Взять поток на источнике, реплицировать в несколько потоков (каждый - AS>> по своему маршруту), на приёмнике - "лишние" пакеты убрать (плюс, возможно, AS>> провести dejitter) ? Тупо, overhead дикий, но работает...

...

Есть ли готовые решения для этой технологии? Типа туннеля, чтобы можно было задать два (три, четыре) маршрута, и чтобы это было не основной/запасной, а оба постоянно рабочих, и удалять дублирующие пакеты? Возможна отдельная проблема с reorder, но тоже разрешима. Или, в случае одного маршрута - передача с избыточностью, например, с использованием кода Рида-Соломона.

-- Паша.

16 ноября 2012 г., 0:18 пользователь Sergey Smitienko написал:

On 13.11.2012 19:02, Pavel Gulchouck wrote:

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

знаете толк в извращениях, я погляжу. Проще уж тогда закинуть пакет по разным каналам и убить дубли.

On 16.11.2012 7:39, Vasiliy P. Melnik wrote:

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

знаете толк в извращениях, я погляжу. Проще уж тогда закинуть пакет по разным каналам и убить дубли.

Я имел в виду порезать пакет на части и запустить по разным каналам N копий и убить дубли на приемнике. Если пакеты теряются из-за высокого BER, у кучи маленьких пакетов больше шансов проскачить. -- Sergey Smitienko

2012/11/16 Valentin Nechayev

Fri, Nov 16, 2012 at 10:26:32, rad wrote about "[uanog] Re: [uanog] Re: [uanog] Резеревирование канала ПД с быстрой сходимостью .":

...

...

знаете толк в извращениях, я погляжу. Проще уж тогда закинуть пакет по разным каналам и убить дубли.

Тогда я сейчас скажу еще большее извращение: http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol Что господа на это скажут ?

Идея хорошая, но почему-то SCTP уже лет 12 не продвигается существенно.

Так ведь работает, зачем что-то менять?

-netch-

По сути топика -

1) или, как предложил Снар, размножать трафик 2) или переписать приложение 3) или подсунуть ему хелпер, который UDP будет поверх TCP транспортировать - но этот вариант, конечно, сильно зависит от того, как написано приложение :-) если ему помимо потерь еще и задержку подавай гарантированную - то см. п.1 или 2 :-)

Всё ж не понимаю, чего не пустить эту хрень просто поверх openvpn@udp и забыть о потерях пакетов + задержки тоже поменьшают. И развернуть просто довольно. Ну как изврат совсем - несколько openvpn тунелей и ospf на них. Что-то подобное у меня жило между площадками, когда шансы падения линка между ними были высокими и на каждую свой аплинк приходил - разве что внутренний трафик по инету гонять не очень прикольно было. -- Best regards, Paul Arakelyan.