но я слабо верю в способности IP гарантировать надёжность
а что ты понимаешь в данном случае под обеспечением надежности?
огда он весь построен по принципу "best effort"
неправда. в нем самом есть изначальные закладки на QoS. нереализованность этого во многих стеках и устройствах -- проблемы этих реализаций, а не генетические особенности.
разнообразные виды congestion control и прочих средств обеспечения надёжности не встроены в основные механизмы, а привешиваются сбоку припёка.
они достаточно органично встроены, по крайне мере в пределах сети одного провайдера. а вопрос обеспечения качества на стыках -- в традиционной телефонии стоит не менее остро ("межстанционное занято")
> а что ты понимаешь в данном случае под обеспечением надежности?
Это значит - что бы ни происходило в той IP части которая обеспечивает например интернет и тельавидение - телефонная часть не должна страдать. Какие бы там потоки не шли. Какие бы TV, IP only каналы не страдали.
Как будем обеспечивать? VLAN'ы, QoS между ними и per-VLAN STP?
> неправда. в нем самом есть изначальные закладки на QoS. нереализованность этого во многих стеках и устройствах -- проблемы этих реализаций, а не генетические особенности.
Обрати внимание на алгоритм удвоения задержки. Ты не найдёшь реализацию TCP в которой его нет или в которой его можно обойти. То же и с SIP.
> они достаточно органично встроены, по крайне мере в пределах сети одного провайдера. а вопрос обеспечения качества на стыках -- в традиционной телефонии стоит не менее остро ("межстанционное занято")
Нет, в таком аспекте и на стыках проблем мало - если DiffServ правильно настроен. Но сам DiffServ - это решение хоть и крайне эффективное в нынешних условиях (я его категорически поддерживаю), но сделанное по методу "сделаем хоть что-то, если нормально не можем"
Это значит - что бы ни происходило в той IP части которая обеспечивает например интернет и тельавидение - телефонная часть не должна страдать. Какие бы там потоки не шли. Какие бы TV, IP only каналы не страдали.
Как будем обеспечивать? VLAN'ы, QoS между ними и per-VLAN STP?
я правильно понимаю, что тут тебя заботит перераспределение канальной полосы в пользу голоса? Для этого достаточно strict priority для голосовых пакетов и на границе сети правильной маркировки/перемаркировки.
Обрати внимание на алгоритм удвоения задержки. Ты не найдёшь реализацию TCP в которой его нет или в которой его можно обойти. То же и с SIP.
по tcp идет только сигнализация, голос идет по udp. где в udp удвоение задержки?
Нет, в таком аспекте и на стыках проблем мало - если DiffServ правильно настроен. Но сам DiffServ - это решение хоть и крайне эффективное в нынешних условиях (я его категорически поддерживаю), но сделанное по методу "сделаем хоть что-то, если нормально не можем"
здрасте, diffserv практически с самого начала в стандарте ip есть -- только назывался ToS. отличее только в том, как теперь эти биты читают и считают.
я про rsvp и про ограниченно-доверительное масштабирование rsvp на сеть более чем одного провайдера, на данный момент rsvp не предназначен к работе на сети более чем одного провайдера. лет, кстати, этому rsvp столько, что я и не упомню.
Да, видимо тормоз. Ткните пальцем где Вы писали о том что и на базе каких технологий работает (с указанием имен технологий чтобы я в случае смог выгуглить).
Вы гоните. У Вас были только общие фразы. Понять что именно под ними Вы имеете ввиду было невозможно. Непонятно какие программно-аппаратные комплексы обеспечивали Вам вашу приоритетизацию пакетов и какими стандартами это регулируется.
Нашел ссылку только на Cisco IOS. Похоже что Ваш хваленый QoS обеспечивается Вам Циской и Циской провайдера и дальше по цепочке, где каждая пара связана контрактными обязательствами? Как Вы проверяете соответствие реальной ситуации обещанной? Существуют ли способы измерения QoS?
Сможете ли Вы отловить момент когда кусок канала, выделяемый Вам провайдером, уменьшится? Грубо говоря момент когда сумма проданных провайдером "гарантированных полос" превысит возможности внешних каналов?
было спрошено какая технология -- я ответил. детали не запрашивались какими стандартами это регулируется.
нафига тут какие-то стандарты?! это настройка моего оборудования, зачем мне на это стандарты?
Нашел ссылку только на Cisco IOS. Похоже что Ваш хваленый QoS обеспечивается Вам Циской и Циской провайдера и дальше по цепочке, где каждая пара связана контрактными обязательствами? Как Вы проверяете соответствие реальной ситуации обещанной? Существуют ли способы измерения QoS?
Да, моей Cisco. У провайдера я беру выделенный канал, без всяких его цисок. FR или LL или еще что. Контролирую задержку и потери на канале. Средства измерения есть в IOS.
Сможете ли Вы отловить момент когда кусок канала, выделяемый Вам провайдером, уменьшится? Грубо говоря момент когда сумма проданных провайдером "гарантированных полос" превысит возможности внешних каналов?
Мне на это наплевать, мне надо что бы параметры предоствляемого канала были в заявленных пределах (задержка, потери, ширина), а из-за чего они ухудшились -- мне уже все равно (ошибки на последней миле, оверсубскрайбинг, ошибки в настройке оборудования) и бить провайдера по голове буду одинаково.
Спасибо за ответ. Иначе говоря, качество Вы гарантируете только на своей циске, а дальше что Бог пошлет. То есть Вы не требуете скажем у провайдера таких же строгих приоритетов трафика как у себя.
Что значит "выделенный канал"? Просто IP? Или просто НС - физическое соединение точка-точка?
Пошлите в Википедию, что ли... По моему опыту характерная черта всех цисководов в том что они не могут объяснить все в двух словах - им проще послать. В результате я ничего не понимаю в BGP, QoS и VoIP.
> Что значит "выделенный канал"? Просто IP? Или просто НС - физическое соединение точка-точка?
Для данного вопроса это совершенно пофиг. Может быть и НС, и поток в FR, и сочетание всего вместе, лишь бы оно удовлетворяло принципу, что от точки A до точки B обеспечивается IP поток скорости не меньше указанной. При этом точки вполне могут находиться на разных континентах.
> Спасибо за ответ. Иначе говоря, качество Вы гарантируете только на своей циске, а дальше что Бог пошлет. То есть Вы не требуете скажем у провайдера таких же строгих приоритетов трафика как у себя.
От транспортного провайдера требуется обеспечение договоренного CIR. А от того кому приходит другой конец канала - если он обеспечивает QoS - обеспечение нужной политики (которая определяет 1) классификацию трафика, 2) приоритизацию трафика при сохранении заданных гарантированных, предельных полос и реакции на всплески). Если стыкуются сети разной подчинённости, на их стыке определяется как каждая сторона понимает QoS метки другой стороны (приоритет 802.1p, TOS пакета IP и так далее). Есть стандартные понимания этих значений, которых сейчас вполне достаточно чтобы включив QoS в принципе и настроив полосы - можно было ожидать, что оно будет работать так как надо. Пока не сломали;))
Ваш ответ подходит под мое определение IP-cояединения точка-точка. То есть ві покупаете у провайдера не просто QoS а IP QoS между конкретными точками A и B и на нижележащий транспорт Вам наплевать.
Вопросы о "строгих приоритетах" возникли оттого, что меня смущала Ваша привязка к CIR. CIR - это всего лишь гарантированная полоса пропускания, а голосовой траффик еще чувствителен к latency и даже jitter. Эта тройка параметров полностью определяет QoS?
Что насчет разных схем приоритетности/queuing disciplines? Вам все равно какую провайдер будет использовать для Вашего трафика? Или три параметра QoS определяют ее практически однозначно и требований трех параметров (или даже двух) достаточно?
> Сможете ли Вы отловить момент когда кусок канала, выделяемый Вам провайдером, уменьшится? Грубо говоря момент когда сумма проданных провайдером "гарантированных полос" превысит возможности внешних каналов?
Вот такие вещи решаются только юридически.:)
> Существуют ли способы измерения QoS?
Да. Загрузить поток на полную обещанную полосу и проверить с другой стороны, что пришло столько же.
> Похоже что Ваш хваленый QoS обеспечивается Вам Циской и Циской провайдера и дальше по цепочке, где каждая пара связана контрактными обязательствами?
Понимание QoS тегов сейчас достаточно стандартно, чтобы надеяться не только на Cisco.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2006-10-15 08:34 pm (UTC)придется...
а что ты понимаешь в данном случае под обеспечением надежности?
неправда. в нем самом есть изначальные закладки на QoS. нереализованность этого во многих стеках и устройствах -- проблемы этих реализаций, а не генетические особенности.
они достаточно органично встроены, по крайне мере в пределах сети одного провайдера. а вопрос обеспечения качества на стыках -- в традиционной телефонии стоит не менее остро ("межстанционное занято")
no subject
Date: 2006-10-16 06:18 am (UTC)Это значит - что бы ни происходило в той IP части которая обеспечивает например интернет и тельавидение - телефонная часть не должна страдать. Какие бы там потоки не шли. Какие бы TV, IP only каналы не страдали.
Как будем обеспечивать? VLAN'ы, QoS между ними и per-VLAN STP?
> неправда. в нем самом есть изначальные закладки на QoS. нереализованность этого во многих стеках и устройствах -- проблемы этих реализаций, а не генетические особенности.
Обрати внимание на алгоритм удвоения задержки. Ты не найдёшь реализацию TCP в которой его нет или в которой его можно обойти. То же и с SIP.
> они достаточно органично встроены, по крайне мере в пределах сети одного провайдера. а вопрос обеспечения качества на стыках -- в традиционной телефонии стоит не менее остро ("межстанционное занято")
Нет, в таком аспекте и на стыках проблем мало - если DiffServ правильно настроен. Но сам DiffServ - это решение хоть и крайне эффективное в нынешних условиях (я его категорически поддерживаю), но сделанное по методу "сделаем хоть что-то, если нормально не можем"
no subject
Date: 2006-10-16 06:36 am (UTC)я правильно понимаю, что тут тебя заботит перераспределение канальной полосы в пользу голоса? Для этого достаточно strict priority для голосовых пакетов и на границе сети правильной маркировки/перемаркировки.
по tcp идет только сигнализация, голос идет по udp. где в udp удвоение задержки?
здрасте, diffserv практически с самого начала в стандарте ip есть -- только назывался ToS. отличее только в том, как теперь эти биты читают и считают.
я про rsvp и про ограниченно-доверительное масштабирование rsvp на сеть более чем одного провайдера, на данный момент rsvp не предназначен к работе на сети более чем одного провайдера. лет, кстати, этому rsvp столько, что я и не упомню.
no subject
Date: 2006-10-16 03:13 pm (UTC)no subject
Date: 2006-10-16 03:24 pm (UTC)да и отношения хозяйственно-договорные еще не сложились и даже не начали складываться.
но, видимо, необходимо добавить аутентификацию и лимиты на запросы ресурсов оn пиров. ну и возможно билинг.
а, еще наверное поксирование-каскадирование запросов. т.е. когда идет запос полосы по цепочке A-B-C что бы ресурсы у C запрашивались от имени B.
no subject
Date: 2006-10-16 03:26 pm (UTC)no subject
Date: 2006-10-16 03:39 pm (UTC)no subject
Date: 2006-10-16 03:49 pm (UTC)no subject
Date: 2006-10-16 05:24 pm (UTC)no subject
Date: 2006-10-16 08:46 pm (UTC)no subject
Date: 2006-10-16 09:29 pm (UTC)ссылку на пост где я писал ключевое слово (стрикт приорити) мне искать лень...
no subject
Date: 2006-10-16 11:45 pm (UTC)Нашел ссылку только на Cisco IOS. Похоже что Ваш хваленый QoS обеспечивается Вам Циской и Циской провайдера и дальше по цепочке, где каждая пара связана контрактными обязательствами? Как Вы проверяете соответствие реальной ситуации обещанной? Существуют ли способы измерения QoS?
Сможете ли Вы отловить момент когда кусок канала, выделяемый Вам провайдером, уменьшится? Грубо говоря момент когда сумма проданных провайдером "гарантированных полос" превысит возможности внешних каналов?
no subject
Date: 2006-10-17 04:27 am (UTC)здрасте. каков вопрос -- таков ответ.
разжевать в постановке вопроса не звучало
было спрошено какая технология -- я ответил. детали не запрашивались
нафига тут какие-то стандарты?! это настройка моего оборудования, зачем мне на это стандарты?
Да, моей Cisco. У провайдера я беру выделенный канал, без всяких его цисок. FR или LL или еще что. Контролирую задержку и потери на канале. Средства измерения есть в IOS.
Мне на это наплевать, мне надо что бы параметры предоствляемого канала были в заявленных пределах (задержка, потери, ширина), а из-за чего они ухудшились -- мне уже все равно (ошибки на последней миле, оверсубскрайбинг, ошибки в настройке оборудования) и бить провайдера по голове буду одинаково.
no subject
Date: 2006-10-17 04:44 am (UTC)Что значит "выделенный канал"? Просто IP? Или просто НС - физическое соединение точка-точка?
no subject
Date: 2006-10-17 05:33 am (UTC)no subject
Date: 2006-10-17 06:33 pm (UTC)no subject
Date: 2006-10-17 07:05 pm (UTC)что там в википедии творится -- я не знаю, могу послать на www.cisco.com с предварительным заходом на http://www.protocols.ru/
no subject
Date: 2006-10-17 08:44 pm (UTC)no subject
Date: 2006-10-17 10:20 pm (UTC)таки не знаете.
я не зря на такие основы посылаю. а ietf слишком много содержит постороннего и многое там отсутствует
no subject
Date: 2006-10-17 05:40 am (UTC)> Что значит "выделенный канал"? Просто IP? Или просто НС - физическое соединение точка-точка?
Для данного вопроса это совершенно пофиг. Может быть и НС, и поток в FR, и сочетание всего вместе, лишь бы оно удовлетворяло принципу, что от точки A до точки B обеспечивается IP поток скорости не меньше указанной. При этом точки вполне могут находиться на разных континентах.
> Спасибо за ответ. Иначе говоря, качество Вы гарантируете только на своей циске, а дальше что Бог пошлет. То есть Вы не требуете скажем у провайдера таких же строгих приоритетов трафика как у себя.
От транспортного провайдера требуется обеспечение договоренного CIR. А от того кому приходит другой конец канала - если он обеспечивает QoS - обеспечение нужной политики (которая определяет 1) классификацию трафика, 2) приоритизацию трафика при сохранении заданных гарантированных, предельных полос и реакции на всплески). Если стыкуются сети разной подчинённости, на их стыке определяется как каждая сторона понимает QoS метки другой стороны (приоритет 802.1p, TOS пакета IP и так далее). Есть стандартные понимания этих значений, которых сейчас вполне достаточно чтобы включив QoS в принципе и настроив полосы - можно было ожидать, что оно будет работать так как надо. Пока не сломали;))
no subject
Date: 2006-10-17 06:49 pm (UTC)Вопросы о "строгих приоритетах" возникли оттого, что меня смущала Ваша привязка к CIR. CIR - это всего лишь гарантированная полоса пропускания, а голосовой траффик еще чувствителен к latency и даже jitter. Эта тройка параметров полностью определяет QoS?
Что насчет разных схем приоритетности/queuing disciplines? Вам все равно какую провайдер будет использовать для Вашего трафика? Или три параметра QoS определяют ее практически однозначно и требований трех параметров (или даже двух) достаточно?
no subject
Date: 2006-10-17 05:48 am (UTC)Вот такие вещи решаются только юридически.:)
> Существуют ли способы измерения QoS?
Да. Загрузить поток на полную обещанную полосу и проверить с другой стороны, что пришло столько же.
> Похоже что Ваш хваленый QoS обеспечивается Вам Циской и Циской провайдера и дальше по цепочке, где каждая пара связана контрактными обязательствами?
Понимание QoS тегов сейчас достаточно стандартно, чтобы надеяться не только на Cisco.
no subject
Date: 2006-10-17 06:55 pm (UTC)Я имел ввиду, сможете ли Вы вовремя отловить снижение QoS. Как его потом вернуть взад - в-общем, понятно.
> Понимание QoS тегов сейчас достаточно стандартно, чтобы надеяться не только на Cisco.
В-общем, вы ответили на вопрос.