Какова стоимость обслуживания высокоприоритетного трафика?

[QWE]

Абонент захотел в арендуемом канале 100Мбит/с гонять 10Мбит/с высоко приоритетного трафика размеченного на его стороне с использованием dscp.

НА сети есть 3550-3560 свичи по гигабиту соединенные. И понятно что этот сервис в принципе бесплатен, т.к. никто не будет укладывать 1гбит/с в полку а перейдет на более высокую скорость.

Бред, но абонент хочет почему бы и нет.

Если кто то продает сервис, то как считать или сколько это стоит?

Edited October 18, 2013 by QWE

[Saab95]

Если кто то продает сервис, то как считать или сколько это стоит?

 

+100 процентов абонентской платы сверху.

[QWE]

Если кто то продает сервис, то как считать или сколько это стоит?

 

+100 процентов абонентской платы сверху.

 

т.е. цену 100Мбит/с канала * 2, так?

[darkagent]

От таких запросов больше всего головняка в процессе обслуживания, одной сотней % тут не обойдется.

[andryas]

Посчитайте себестомость этих 10-ти мегабит для себя (с учётом всех затрат и налогов), добаьте свою маржу и получите конечную стоимость.

[HackerDeath]

Топикстартер и говорит что по большому счету ничего не теряет. А кто будет нарезать эти 10мб? Вы должны полисить по dscp и еще и приоритизировать? Я думаю тут индивидуальная настройка. И стоит прикинуть как цена 100мбит + 10мб*2 хотяб. А может и на больше умножать надо.

Edited October 18, 2013 by HackerDeath

[QWE]

Топикстартер и говорит что по большому счету ничего не теряет. А кто будет нарезать эти 10мб? Вы должны полисить по dscp и еще и приоритизировать? Я думаю тут индивидуальная настройка. И стоит прикинуть как цена 100мбит + 10мб*2 хотяб. А может и на больше умножать надо.

Что касается реализации. Абонент планирует сам подкрасить высоко приоритетный трафик. При размеченном со стороны абонента высоко приоритетного трафика схема проста. 10мбит/с приоритетного трафика пропускаем, остальное дропаем, что не дропаем пихаем в priority queue 1Гбит/с интерфейса.

[mefer]

Странный вопрос. Цену надо ставить ровно немного больше чем клиент готов платить. Или такую что б не ушёл к конкуренту.

[m0xf]

Может проще впарить второй кабель?

[Negator]

Угу, а потом доказывайте клиенту что не все байты к нему прилетели с учетом приоритетов.

И оно порой дороже нежели эту полосу нарезать.

[darkagent]

Есть смысл провести с абонентом беседы и выявить конкретику его ТУ, а так же откуда такие ТУ нарисовались. Может там покраска и вовсе не нужна, или имеется какая-нибудь хитрая задача, которую клиент хочет решить своими силами (тот же TDMoIP к примеру).

[QWE]

Может проще впарить второй кабель?

и организовать второй магистральный канал между узлами, на отдельной оптике?

[QWE]

Есть смысл провести с абонентом беседы и выявить конкретику его ТУ, а так же откуда такие ТУ нарисовались. Может там покраска и вовсе не нужна, или имеется какая-нибудь хитрая задача, которую клиент хочет решить своими силами (тот же TDMoIP к примеру).

Говорит VoIP трафик будет подкрашиваться

[QWE]

Угу, а потом доказывайте клиенту что не все байты к нему прилетели с учетом приоритетов.

И оно порой дороже нежели эту полосу нарезать.

абонент сам нарезает полосу, я лишь дропаю все что свыше полосы. Конечно вопрос - как он нарезает полосу (скорее всего трафик будет подкрашен на конечных железках) и как я буду эту полосу считать. Тут потестим и посмотрим. Голосовой трафик он пиками не будет - 50 pps на голосовой канал если трафик от голосовых шлюзов.

[HackerDeath]

Ну конечно впарить еще один кабель это хорошо, но ведь клиент все равно попросит его красить и приоритизировать.

 

 

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

Если клиент нужен и оно того стоит, то наверно как я сказал просто прибавь цену за еще 10мб*2. Если не хочется возиться, но клиент все равно нужен - то скажи клиенту что "Мы вам предоставляем гарантированную полосу в 100мбит, в которой вы можете сами как хотите управлять траифком. Вам достаточно внутри своей сети приоритизировать этот трафик и отправлять его через стык с нами в приоритете, параллельно шейпя все лишнее. Дальше у нас эти пакеты теряться не будут и без приоритизации с нашей стороны." Вот и все. То есть если клиент сам будет следить за тем что дропать сверху этих 100мбит, а что отправлять в приоритете - то нафиг еще от провайдера что надо? Пров итак дает гарантированную полосу в которую он помещается...

 

А если до клиента пофиг, не хочется возиться то как уж выше посоветовали. Ровно столько, сколько будет больше чем он готов платить...

Edited October 19, 2013 by HackerDeath

[QWE]

Ну конечно впарить еще один кабель это хорошо, но ведь клиент все равно попросит его красить и приоритизировать.

 

 

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

Если клиент нужен и оно того стоит, то наверно как я сказал просто прибавь цену за еще 10мб*2. Если не хочется возиться, но клиент все равно нужен - то скажи клиенту что "Мы вам предоставляем гарантированную полосу в 100мбит, в которой вы можете сами как хотите управлять траифком. Вам достаточно внутри своей сети приоритизировать этот трафик и отправлять его через стык с нами в приоритете, параллельно шейпя все лишнее. Дальше у нас эти пакеты теряться не будут и без приоритизации с нашей стороны." Вот и все. То есть если клиент сам будет следить за тем что дропать сверху этих 100мбит, а что отправлять в приоритете - то нафиг еще от провайдера что надо? Пров итак дает гарантированную полосу в которую он помещается...

 

А если до клиента пофиг, не хочется возиться то как уж выше посоветовали. Ровно столько, сколько будет больше чем он готов платить...

За всю мою историю в провайдинге, второй клиент с таким запросом.

Конечно я могу ему объяснить и сказать что все хорошо у него будет и так. Но он дергает - хочется гарантий. После того как он узнал что это будет платно, он пропал на пол года. Морально подготовился, созрел и нарисовался снова, мол готов платить.

Возиться или не возиться - тут возни не много.

Клиент не ставит условие что если не настроите прайорити то я уйду к другому.

10*2, сверх 100 это как то объяснимо-понятно

Edited October 19, 2013 by QWE

[dignity]

А вообще-то, инфраструктура ваша к этому-то готова, в плане sla? То есть, доставите ли вы эти пакеты в соответствии с dscp по своей сети?

[QWE]

А вообще-то, инфраструктура ваша к этому-то готова, в плане sla? То есть, доставите ли вы эти пакеты в соответствии с dscp по своей сети?

да. на маршруте этого канала два свича 3560G

[HackerDeath]

Ну я думаю человек если бы не мог по сети обеспечить данные требования врядли бы за советом о цене обращался на наг.

[dignity]

Ну я думаю человек если бы не мог по сети обеспечить данные требования врядли бы за советом о цене обращался на наг.

 

Ну вот смотрите, у меня на сети в ядре два свича с 10G портами и еще нескольк свичей 10G/1G и я тоже могу, в принципе сделать, что его трафик приоритетный будет ходить, но для этого мне надо на всех трактах включить респект DSCP и переконфигурировать несколько железок, а я это делать не буду, ибо бессмысленно и ради одного абонента это затевать не вижу смысла.

 

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

[HackerDeath]

Об этом я и говорил когда говорил "Охото ли возиться изза одного абонента."

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

Трафик VoIP и multicast сразу красится и приоритизируется, хотя утилизация каналов и 50% не достигает.

 

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

[mightyscv]

Об этом я и говорил когда говорил "Охото ли возиться изза одного абонента."

Без первого абонента никогда не будет второго :)

Мы предоставляем такие услуги. В частности клиентам которые гоняют IPTV через нас(услуга L2VPN), и ещё есть клиент который гоняет, вроде бы, STM-1. Ну и наша внутренняя телефония.

Один серьёзный миф, который я часто слышу от телеком-специалистов, и который нас жёстко пнул - "не надо настраивать QoS, главное чтобы перегрузки не было и всё будет хорошо". На практике оказалось, что не будет. Есть такая дурацкая штука как микробёрст. Возникает он когда у вас в один порт имеют возможность коммутироваться пакеты с двух других, аналогичных по скорости. Если они делают это одновременно то их совокупная приёмная скорость превышает скорость отправки, и тут уже нужна какая-то политика управления очередью. То есть даже если ваш 10Gb/s интерфейс не загружен вообще, на нём всё равно уже могут быть потери пакетов из-за микробёрстов.

 

В остальном всё несложно. У нас сеть MPLS с участками L2 до абонента. Трафик абонента по L2 идёт в QinQ. Классификация на границе по DSCP, заранее согласованному с клиентом. Out-of-profile переклассифицируется в best effort.

В L2 сегменте классификация по внешнему COS, в MPLS - по EXP. Классов трафика всего 4, по количеству очередей - network control, expedited forwarding, assured forwarding, и best-effort. IPTV трафику нужна гарантия доставки, поэтому он может шейпиться, но не может дропаться. Телефонный трафик не может шейпиться, но может дропаться. Планировщики очереди везде настраиваются соответствующим образом. Трафик в best effort теряется через tail-drop при перегрузке очереди.

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

 

С ценообразованием сложно. Поспрашивал наших менеджеров - у них весьма туманное представление о ценообразовании. Грубо говоря берётся стоимость обычного канала и прибавляется 30-100%, в зависимости от наглости менеджера в тот день и готовности клиента платить.

[HackerDeath]

По поводу того что не нужно это точно фигня. Я это хорошо знаю. Уже проверенно. На абсолютно не нагруженной сети IPTV терял пакеты жутко, просто дал EF приоритет трафику ИПТВ, и все. Стало супер работать.

[darkagent]

просто дал EF приоритет трафику ИПТВ, и все

просто оставлю это здесь... http://www.cisco.com/en/US/technologies/tk543/tk759/technologies_white_paper0900aecd80295aa1.pdf

[QWE]

просто оставлю это здесь... http://www.cisco.com/en/US/technologies/tk543/tk759/technologies_white_paper0900aecd80295aa1.pdf

 

"3) DESIGN AND TEST THE QoS POLICIES" это интересно если CoS в сети строить с нуля - слишком много классов, по факту дешевле расширить каналы.

Edited October 19, 2013 by QWE