Re: [uanog] Re: [uanog] Применимость механизмов Service Control в операторских сетях

Dmitry Cherkasov пишет:

2008/11/21 Dmitry Kiselev :

...

...

методы определения skype/torrent итд траффика из нетфлоу в студию !

Методы определения принадлежности шифрованного трафика с помощью DPI в студию!

Так что от поведенческого анализа уйти никак не получится, а для него смотреть в payload совершенно не нужно, т.е. netflow будет вполне достаточно.

P.S. По моим наблюдениям примерно 60% bittorent трафика (both control and data) УЖЕ шифруется.

Можно подойти к вопросу с другой стороны. 1) оставить как есть все, что есть на сейчас (непонятную смесь из p2p, skype, http, etc.) 2) предложить qos для тех видов трафика, которые возможный клиент опишет явно.

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

А какой метод можно предложить клиенту для маркировки своего траффика ? TOS/dscp ? Насколько я помню, несколько лет назад была некоторая инициатива дать возможность клиентским приложениям уровня X-lite того-же, выставлять QoS класс для своего траффика. Все это разбивается о то, что веря клиенту ты создаешь возможность воспользоваться этим не так как задумано. Он на своем бордере начнет весь свой траффик маркировать как realtime да и все.

Просто полосой вопрос qos не решается. Packet loss при достаточной полосе действительно исчезнет. А для стабильности задержки без классификации свободная полоса должна составлять 90%, что нереально.

Для тех, кто хочет ту же телефонию как основной сервис, а не как дополнение к сервису Internet, лучше наверное делать отдельный pvc/vlan/what ever со своим QoS в рамках бродбенд включения.