[alibek]

Готовим договор с поставщиком IPTV — IPTV по юникасту через интернет-канал (не выделенный канал связи).

Хотим прописать SLA, поставщик в принципе не возражает, но не согласен с нашими критериями.

Мы хотим обговорить следующие критерии:

*** Критерии качества контента
* Условные критерии качества
  - полное отсутствие сервисов (нет трафика или связи с серверами) 
    в течении X минут;
  - процент потерь пакетов (ping) до серверов превышает N% при 
    замерах в течение X минут;
  - время отклика (ping) до серверов превышает NNNмс при замерах 
    в течение X минут;
* Безусловные критерии качества
  - отсутствуют или не работают заявленные ТВ-каналы (Приложение №6);
  - в одном или нескольких каналах отсутствует звук (аудиодорожка);
  - в одном или нескольких каналах отсутствует или присутствует 
    недостоверная программа передач более 12 часов подряд;
  - отсутствие видеоархива (полное или частичное) в пределах 
    регламентируемой глубины архива;

*** Критерии качества доступа к Middleware
- задержки или отказы в регистрации/авторизации абонентских терминалов чаще 
  3 раз в течение часа;
- задержки или отказы в предоставлении плейлиста чаще 3 раз в течение часа;

*** Критерии качества доступа к панели управления
- недоступность панели управления длительностью более X минут;
- неработоспособность функций панели управления длительностью более X минут;

*** Сроки
При выявлении несоответствия получаемого уровня услуг гарантированному уровню 
Агент уведомляет Принципала о выявленном несоответствии по телефону или 
электронной почте. Принципал обязуется устранить выявленное несоответствие 
в следующих временных интервалах:
- несоблюдение критериев по контенту — в течение часа;
- несоблюдение критериев по работе Middleware — в течение часа;
- несоблюдение критериев по работе панели управления — в течение 4 часов;
Если несоответствие не было устранено в установленный срок, фиксируется факт 
несоблюдение гарантированного уровня предоставления сервиса.

Смысл сроков следующий:

• если длительность сбоя менее пороговой величины, он не учитывается
• если длительность сбоя более пороговой величины, но он устранен с регламентный срок, он не учитывается
• если сбой не устранен в регламентный срок, фиксируется нарушение SLA

 

Поставщик не согласен прописывать в SLA пинги и время отклика, так как по его словам это косвенные критерии и прямо с качеством услуги не связаны.

В принципе это так, но что тогда лучше прописать в SLA?

Количество retransmit или время установки tcp-соединения? Но это будет сложно измерять.

 

[paradox_]

так они вам услуги связи предоставляют или иптв ?

пинги и траблы сети это все услуги связи

 

вы еще в сла пропишите что бы луна была постоянно в пятом доме

[alibek]

Предоставляются услуги IPTV.

Но если, например, будет перегружен аплинк на серверах, то это скажется и на качестве контента.

Или если производительности сервера не хватит, чтобы отдавать потоки в ЧНН, это тоже деградация качества.

[paradox_]

как вы по пингу сервера определите перегружен ли у них аплинк или это где то по трассе проблема ?

можно требовать по сла только два параметра

1) доступность сервиса, т.е. вести свой мониторинг при котором сразу снимать трассу как минимум mtr

2) и качество услуги, как минимум статистика СС мпегтс, как максимум можно еще прописать весь mpegts который так любит skystar упоминать

 

и сразу же появляется вопрос а как вы будете это контролировать ?

какой у вас мониторинг ?

если его нет, то и требовать нет смысла

Edited January 5, 2019 by paradox_

[alibek]

45 минут назад, paradox_ сказал:

как вы по пингу сервера определите перегружен ли у них аплинк или это где то по трассе проблема ?

Собственно потому я и согласен убрать пинги из критериев.

Сейчас предложил рассматривать процент пакетов tcp retransmission, он должен быть не более определенного значения.

Это более коррелирует с качеством получаемой услуги.

 

59 минут назад, paradox_ сказал:

статистика СС мпегтс

По-моему софт, который анализирует видеопотоки, сильно платный.

Или есть бесплатные решения?

 

1 час назад, paradox_ сказал:

какой у вас мониторинг

Вначале нужно определиться с критериями.

А потом решать вопрос автоматизированного контроля этих критериев.

[paradox_]

ретрансмиты тсп - вы серьезно ?

смотрите что бы потом не оказалось что ваши хотелки не реализуемы

по правильному сначала отталкиваются от средств мониторинга

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

 

а то может потом оказаться что по всем критериям гуд

а клиенты жалуются

 

[alibek]

21 минуту назад, paradox_ сказал:

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

Так я потому и создал тему — по каким критериям следует оценивать качество видеоконтента.

Если бы речь шла про мультикаст, то там и вопроса бы особо не возникало, есть различные анализаторы потока, снимающие статистику mpegts.

Но у меня юникаст и возможно даже шифруемый.

На мой взгляд процент ретрансмитов достаточно хорошо должен коррелировать с качеством видео.

[paradox_]

для hls вообще все равно что там с ретрансмитом, да и в iptv овер интернет тем более

более того могут быть периодические провалы по полосе без потери качества

могут стягиваться пачками несколько сегментов и отдых и так по кругу

 

поэтому начинать нужно не с придумываний требований по сла

а с поиска анализаторов и прикидками на платные

 

смотреть нужно на pts dts в pes что бы он был ровный

[sky star]

посмотрел краем глаза , умеет

 

[maxlapshin]

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

 

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

 

 

Качество видео вообще никак не связано с ретрансмитами. Это HLS по TCP. Подумаешь, потеряются какие-то пакеты и скакнет задержка. Там уже из коробки задержка 30 секунд, которая сделана ровно для того, что бы компенсировать всё, что меньше.

 

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

[alibek]

4 часа назад, maxlapshin сказал:

Поставщик IPTV OTT никак не может вписываться ни в пинги, ни в ретрансмиты

Вы поставщик, потому и защищаете эту точку зрения.

 

4 часа назад, maxlapshin сказал:

Это HLS по TCP. Подумаешь, потеряются какие-то пакеты и скакнет задержка.

Убедили, согласен.

 

4 часа назад, maxlapshin сказал:

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

Тут все хорошо.

Но я бы хотел, чтобы SLA предусматривало не только полную остановку сервиса, но и как-то регламентировало качество.

 

Какое-то время назад в ЧНН начинали деградировать все онлайн-кинотеатры (преимущественно пиратские), базирующиеся на ВКонтакте.

Причина была в том, что в ЧНН были перегружены стыковочные линки с серверами ВКонтакте, их расширение было довольно дорогим и ВКонтакте считал, что это расширение должны делать операторы за свой счет, а операторы считали, что эти затраты должен понести источник трафика. В итоге стыки через несколько недель расширили (уж не знаю, за чей счет, но скорее всего за счет операторов), но эти несколько недель абоненты всю плешь выедали, что у них по вечерам ГидОнлайн или что-то подобное тормозит.

Это явно ответственность поставщика — следить за нагрузкой серверов и линков и заблаговременно их расширять.

[paradox_]

гарантировать вам все ваши хотелки может только тот оператор который осуществляет предоставления услуг связи и отт  иптв в одном флаконе как минимум

как максимум это может быть поставщик отт иптв с которым вы делите сеть одного оператора и оператор связи вам обеим гарантирует сла

[alibek]

9 минут назад, paradox_ сказал:

гарантировать вам все ваши хотелки может только тот оператор

Ну на самом деле это вопрос взаимных компромиссов.

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

От поставщика тоже ожидаю каких-то предложений.

Без гарантий, по принципу as is, услуга неинтересна — это показывает не столько реальное качество сервиса (за период тестирования сбоев не было), сколько будущее отношение к возможным перебоям.

[maxlapshin]

это примерно как давать обещание, что на вас не упадет метеорит.

 

Кто-то пообещает, кто-то не пообещает. Метеорит не упадет почти точно, но первый будет обманщик.

 

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

 

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

 

OTT везде и всегда и у всех предоставляется as is. По другому невозможно, это OTT по определению.

[alibek]

Речь ведь не про транзит, а про то, что выходит от поставщика.

[maxlapshin]

А каким методом вы собираетесь проверять то, что выходит от поставщика?  Для такой тонкой материи как ретрансмиты, нужно оборудование третьей стороны.
 

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

Вы получаете результат после транзита (если конечно нет прямого стыка). Фактически, всё что вы можете купить, это обещание и жгучее желание поставщика услуги сделать её хорошо, подобрать хороших транзитеров, обеспечить связность. Но вот требовать здесь гарантии — это очень странно.

[paradox_]

Он хочет от поставщика гарантии по сла, что у самого поставщика хватает мощностей и пропускной способности удовлетворить всех не загнувшись

 

Что то типа

- покажи мне свои деньги чувак и что они у тебя не закончатся если придет еще +10500 попрошаек у тебя занять

а то что ты говоришь что они у тебя есть или твои знакомые говорят что они у тебя есть, для меня не аргумент

 

[maxlapshin]

On 1/12/2019 at 9:29 AM, paradox_ said:

Он хочет от поставщика гарантии по сла, что у самого поставщика хватает мощностей и пропускной способности удовлетворить всех не загнувшись

 

Это невозможно гарантировать, на то он и OTT.

 

Между поставщиком услуги есть ещё транзитер (скорее всего) и есть сама сеть клиента.

 

Как вы предлагаете брать на себя ответственность за транзитных операторов?

 

Я ещё раз повторю: в случае с OTT ничего кроме доверия и обоюдного желания сделать хороший сервис абонентам нет и быть не может.

 

Плюс это всё конечно круто с SLA, но что-то (опыт) мне подсказывает, что желающие подписывать SLA обычно успокаиваются, когда начинают говорить о стоимости таких SLA. Например, что бы померять ретрансмиты и прочее, нужна третья сторона. Оплачивать её, конечно же, будет клиент (потому что только он всю кухню оплачивает). Ценник сразу вырастет не на проценты, а кратно.

 

Т.е.  пока тут обсуждают SLA в OTT HLS и пытаются понять, почему оно выйдет в несколько раз дороже головной станции, рядом конкурент уже всё запустит как есть.