Ну, конечно, у IP есть проблемы и с отказоустойчивостью, и с масшатбируемостью, и с качеством обслуживания. Но ни одна из них не является неустранимой.
> Ну, конечно, у IP есть проблемы и с отказоустойчивостью, и с масшатбируемостью, и с качеством обслуживания. Но ни одна из них не является неустранимой.
В теории. А есть на практике хоть один реальный пример как в большой сети устранили эти проблемы? Например, DiffServ+QoS и чтобы полосы хватало, и чтобы её попусту не расходовали, и чтобы при перегрузках была внятная диагностика ситуации (а не рвущийся звук), и чтобы в отдельных узлах можно было чётко различить в конфигурации уровень обеспечения связи и уровень всего остального и чтобы ни один админ полезший во второе не смог сломать первое, опциями конфигурации или банальной перегрузкой раутеров?
> В теории. А есть на практике хоть один реальный пример как в большой сети устранили эти проблемы?
Сетей, в которых эти вопросы решены, если не на пять, то хотя бы на четыре, есть. Чтобы сделать на четыре с плюсом, нужны механизмы, которые пока только таки в теории, да.
> Например, DiffServ+QoS и чтобы полосы хватало, и чтобы её попусту не расходовали
Ну, собственно, Diffserv не ведет к пустому расходу полосы. Хотя без "пустого" расхода полосы никуда не деться - overprovisioning есть всегда, и это фундаментальное свойство.
> и чтобы при перегрузках была внятная диагностика ситуации (а не рвущийся звук)
Admission control, причем как функция приложения, а не сети.
> Или речь идет про one egg - one basket?
И про это тоже.
А тут никуда не деться. Можно очень дорого, но очень надежно, а можно дешево, но с надежностью на уровне "good enough".
Да, если говорить про сегодняшний день, то у себя дома свою обычную pots-линию я убирать не собираюсь, хотя по ней я почти не говорю. Ни в пользу IP-телефона, ни в пользу GSM. Просто на случай катаклизмов.
Главное, чтобы рядом валялся обычный телефон, который умеет работать от станционного питания, по которому в случае нужды скорую можно вызвать в любой момент.
В Бейруте POTS вылетели первыми и лежали дольше всего.
И самыми надежными оказались именно домосети в их классическом проявлении. Причины: децентрализация (АТС разбомбили в первую очередь - и все, нет ПОЦа), простота и дешевизна ремонта (соплю кинул - и готово).
А если про бекапирование носителя говорить - то надо среду бекапировать. То есть кабель - радивом скажем. Или спутником. Кстати, собираюсь таки да в ближайшее время Турайкой обзавестить. Ибо в Москве например как только мало-мальски значимая шумиха - первым делом отключают GSM сети.
Наверное, в этом есть какая-то правда. Убомбить все домонеты разом действительно сложно. Одна беда - домонет не масштабируется.
Про турайку. Я мало про эту область знаю, но из общих соображений: предполагаю, что держать spare capacity им дорого и пиковая нагрузка, которую они смогут выдержать не так велика по сравнению с обычной, соответственно, случись заваруха - все достанут свои турайки, которые они держали на черный день, и привет.
Еще можно иридиумом обзавестись... его думаю не так много из-за цены. И лицензией на VSAT :) А еше лучше стать радиолюбителем на КВ и накупить топливных элементов с дизелями. Или генераторов работающих на дровах.
А че - вроде уже научились IP пускать. А там глядишь - всех разбомбят а ты будешь в ЖЖ постить всякие страхи спокойно. Надо только пира найти который тебе какой-нибудь globax или другой TCP PEP поверх голого gre поднимет ибо TCP при огромных потерях умрет.
У POTS при перегрузке (в "классической" ситуации - когда все таймслоты заняты, я не знаю как сейчас оно) ты получаешь отказ в обслуживании... А IP тебе хоть что-нибудь да даст. Да еще теоретически есть возможность уменьшать динамически битрейт если связи почти нет.
Насколько мне известно, админы и ISDN-адресацию могут поломать и криво настроить. То что при этом все работает вовсе не означает что каналы настроены оптимально - они просто простаивают, а разделение по времени обеспечивает скачкообразное качество - 100% или 0%. Айпи эту проблему решит пустив по тому же волокну еще и порнуху.
> У POTS при перегрузке (в "классической" ситуации - когда все таймслоты заняты, я не знаю как сейчас оно) ты получаешь отказ в обслуживании... А IP тебе хоть что-нибудь да даст. Да еще теоретически есть возможность уменьшать динамически битрейт если связи почти нет.
В перегруженном канале ничего голосового нормально не живёт - это я тебе как стоящий одной ногой на IP-телефонии говорю:) Уменьшать bitrate надо заранее и для всех, чтобы перегрузки не было. Или если локальный канал крайне узкий и не впустит нужное количество каналов в широком кодеке.
В перегруженном канале будут жить только стандартные интернетовские сервисы которым не требуется никакого realtime и которые на TCP могут прочихать любые данные, пока потери не достигли совсем уж фантастических величин. То есть всякие там email, мелкопоточные usenet - и даже не форумы, поскольку они полюбили раздувать страницы до 50-100k:( LJ жить толком не будет.
> Насколько мне известно, админы и ISDN-адресацию могут поломать и криво настроить. То что при этом все работает вовсе не означает что каналы настроены оптимально - они просто простаивают, а разделение по времени обеспечивает скачкообразное качество - 100% или 0%. Айпи эту проблему решит пустив по тому же волокну еще и порнуху.
Ну это если их на каком-нибудь ATM строить. В принципе это решение - но опять же если админ копаясь в настройках низкоприоритетных VC сломает высокоприоритетные - хорошо не будет:( Да и кому нужен такой ненадёжный канал? Только совсем уж конечным потребителям, которые готовы доплатить копеечку за высокий FIR при низком CIR?
В перегруженном канале ничего голосового нормально не живёт - это я тебе как стоящий одной ногой на IP-телефонии говорю:) Уменьшать bitrate надо заранее и для всех, чтобы перегрузки не было. Или если локальный канал крайне узкий и не впустит нужное количество каналов в широком кодеке.
это вы настраивать не умеете. у меня все каналы по жизни перегружены, но пока оператор мне выдает заказанный cir -- голос работает великолепно.
> это вы настраивать не умеете. у меня все каналы по жизни перегружены, но пока оператор мне выдает заказанный cir -- голос работает великолепно.
Вот именно - "пока"
А ты скажи, много будет потребителей получающих настоящий CIR в своём IP канале? Как всегда, пожлобятся... ну а про поломки общего свича который убивает всю связь я уже говорил.
Вот именно - "пока" а как только "пока" кончается -- я начинаю бить его по голове. а бабло -- зажимаю. до исправления.
А ты скажи, много будет потребителей получающих настоящий CIR в своём IP канале?
чё? IP -- мое, от опрератора -- FR.
что вообще за бред насчет CIR в IP канале? Либо ты у оператора берешь какой-то вид IP-VPNа и требуешь с него CIR в договорном порядке, либо у тебя интернет, который нифига не гарантирует на данный момент. но к этому придем.
ну а про поломки общего свича который убивает всю связь я уже говорил.
да-да, а поломки SDH сети избирательно действует на ПД, оставляя телефонию в порядке. сказки рассказывают в другом зале.
Сплетни мне доносят что в Харькове с криво настроенными ISDN именно так и обстоит. А на АТМ они построены или целиком в рамках ISDN поверх разделения времени как ты говоришь - собственно не важно.
Нетч, VoIP как средство экономить деньги на голосовом траффике это уже даже не вчерашний, это поза-поза-вчерашний день (равно как и считать QoS инструментом для максимального забивания доступной полосы). Сейчас концепция другая. VoIP через софт-свич. Софт-свич как платформа для IMS. all-over-ip позволяет сегодня ничего не меняя в инфраструктуре мгновенно получать новый сервис (так же, как получались до этого существующие сервисы) как только провайдер запустит его у себя на ims-е. all-over-ip позволяет совершенно без проблем тягать за собой чуть ли не по всему миру, скажем, телефонный номер (что в случае традиционной телефонии с использованием v5.2 (боже сколько оно денег стоит) было конечно частично возможно, но только частично). All-over-ip позволяет сегодня работать в оффисе 10 человекам, а завтра так же просто запустить 100 человек (даже банальная оффисная телефония: порты/платы в АТС закончились и привет. Жди пока новое оборудование прийдет -- это реальная ситуация крупного офиса).
Сегодня стоимость подачи широкой полосы стремительно падает (просто стремительно). Нет нужды инжинирить сеть таким образом, чтобы плотненько-плотненько все забивать (в ущерб качеству). Гораздо проще расчитать что нужно для нормального качества и расширить инфраструктуру под такие потребности.
![[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 03:02 pm (UTC)Или речь идет про one egg - one basket?
no subject
Date: 2006-10-15 03:29 pm (UTC)В теории. А есть на практике хоть один реальный пример как в большой сети устранили эти проблемы? Например, DiffServ+QoS и чтобы полосы хватало, и чтобы её попусту не расходовали, и чтобы при перегрузках была внятная диагностика ситуации (а не рвущийся звук), и чтобы в отдельных узлах можно было чётко различить в конфигурации уровень обеспечения связи и уровень всего остального и чтобы ни один админ полезший во второе не смог сломать первое, опциями конфигурации или банальной перегрузкой раутеров?
> Или речь идет про one egg - one basket?
И про это тоже.
no subject
Date: 2006-10-15 04:01 pm (UTC)Сетей, в которых эти вопросы решены, если не на пять, то хотя бы на четыре, есть. Чтобы сделать на четыре с плюсом, нужны механизмы, которые пока только таки в теории, да.
> Например, DiffServ+QoS и чтобы полосы хватало, и чтобы её попусту не расходовали
Ну, собственно, Diffserv не ведет к пустому расходу полосы. Хотя без "пустого" расхода полосы никуда не деться - overprovisioning есть всегда, и это фундаментальное свойство.
> и чтобы при перегрузках была внятная диагностика ситуации (а не рвущийся звук)
Admission control, причем как функция приложения, а не сети.
> Или речь идет про one egg - one basket?
И про это тоже.
А тут никуда не деться. Можно очень дорого, но очень надежно, а можно дешево, но с надежностью на уровне "good enough".
Да, если говорить про сегодняшний день, то у себя дома свою обычную pots-линию я убирать не собираюсь, хотя по ней я почти не говорю. Ни в пользу IP-телефона, ни в пользу GSM. Просто на случай катаклизмов.
no subject
Date: 2006-10-15 05:07 pm (UTC)no subject
Date: 2006-10-15 05:24 pm (UTC)no subject
Date: 2006-10-15 05:30 pm (UTC)no subject
Date: 2006-10-15 06:01 pm (UTC)(/me ducks and runs)
no subject
Date: 2006-10-15 06:31 pm (UTC)no subject
Date: 2006-10-15 07:29 pm (UTC)(no subject)
From:(no subject)
From:no subject
Date: 2006-10-15 08:36 pm (UTC)проверка: соедени их просто парой проводов.
(no subject)
From:no subject
Date: 2006-10-15 06:19 pm (UTC)И самыми надежными оказались именно домосети в их классическом проявлении. Причины: децентрализация (АТС разбомбили в первую очередь - и все, нет ПОЦа), простота и дешевизна ремонта (соплю кинул - и готово).
А если про бекапирование носителя говорить - то надо среду бекапировать. То есть кабель - радивом скажем. Или спутником. Кстати, собираюсь таки да в ближайшее время Турайкой обзавестить. Ибо в Москве например как только мало-мальски значимая шумиха - первым делом отключают GSM сети.
no subject
Date: 2006-10-15 06:54 pm (UTC)Про турайку. Я мало про эту область знаю, но из общих соображений: предполагаю, что держать spare capacity им дорого и пиковая нагрузка, которую они смогут выдержать не так велика по сравнению с обычной, соответственно, случись заваруха - все достанут свои турайки, которые они держали на черный день, и привет.
no subject
Date: 2006-10-15 07:46 pm (UTC)А при катаклизме ТАКОГО масштаба (не местного, в пределах страны-двух) уже надо не турайку, а рацию расчехлять... кстати, у меня есть ;)
no subject
Date: 2006-10-15 10:58 pm (UTC)А че - вроде уже научились IP пускать. А там глядишь - всех разбомбят а ты будешь в ЖЖ постить всякие страхи спокойно. Надо только пира найти который тебе какой-нибудь globax или другой TCP PEP поверх голого gre поднимет ибо TCP при огромных потерях умрет.
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2006-10-15 10:48 pm (UTC)Насколько мне известно, админы и ISDN-адресацию могут поломать и криво настроить. То что при этом все работает вовсе не означает что каналы настроены оптимально - они просто простаивают, а разделение по времени обеспечивает скачкообразное качество - 100% или 0%. Айпи эту проблему решит пустив по тому же волокну еще и порнуху.
no subject
Date: 2006-10-16 06:27 am (UTC)В перегруженном канале ничего голосового нормально не живёт - это я тебе как стоящий одной ногой на IP-телефонии говорю:) Уменьшать bitrate надо заранее и для всех, чтобы перегрузки не было. Или если локальный канал крайне узкий и не впустит нужное количество каналов в широком кодеке.
В перегруженном канале будут жить только стандартные интернетовские сервисы которым не требуется никакого realtime и которые на TCP могут прочихать любые данные, пока потери не достигли совсем уж фантастических величин. То есть всякие там email, мелкопоточные usenet - и даже не форумы, поскольку они полюбили раздувать страницы до 50-100k:( LJ жить толком не будет.
> Насколько мне известно, админы и ISDN-адресацию могут поломать и криво настроить. То что при этом все работает вовсе не означает что каналы настроены оптимально - они просто простаивают, а разделение по времени обеспечивает скачкообразное качество - 100% или 0%. Айпи эту проблему решит пустив по тому же волокну еще и порнуху.
Ну это если их на каком-нибудь ATM строить. В принципе это решение - но опять же если админ копаясь в настройках низкоприоритетных VC сломает высокоприоритетные - хорошо не будет:( Да и кому нужен такой ненадёжный канал? Только совсем уж конечным потребителям, которые готовы доплатить копеечку за высокий FIR при низком CIR?
no subject
Date: 2006-10-16 06:47 am (UTC)это вы настраивать не умеете. у меня все каналы по жизни перегружены, но пока оператор мне выдает заказанный cir -- голос работает великолепно.
no subject
Date: 2006-10-16 06:17 pm (UTC)Вот именно - "пока"
А ты скажи, много будет потребителей получающих настоящий CIR в своём IP канале? Как всегда, пожлобятся... ну а про поломки общего свича который убивает всю связь я уже говорил.
no subject
Date: 2006-10-16 08:18 pm (UTC)а как только "пока" кончается -- я начинаю бить его по голове. а бабло -- зажимаю. до исправления.
чё? IP -- мое, от опрератора -- FR.
что вообще за бред насчет CIR в IP канале? Либо ты у оператора берешь какой-то вид IP-VPNа и требуешь с него CIR в договорном порядке, либо у тебя интернет, который нифига не гарантирует на данный момент. но к этому придем.
да-да, а поломки SDH сети избирательно действует на ПД, оставляя телефонию в порядке. сказки рассказывают в другом зале.
no subject
Date: 2006-10-16 02:39 pm (UTC)no subject
Date: 2006-10-16 07:32 am (UTC)no subject
Date: 2006-10-16 02:42 pm (UTC)no subject
Date: 2006-10-16 06:22 pm (UTC)И мы приходим к вопросу, что лучше - не пускать при переполнении новых или пускать всех чтобы мешали друг другу?
no subject
Date: 2006-10-19 10:14 am (UTC)Нетч, VoIP как средство экономить деньги на голосовом траффике это уже даже не вчерашний, это поза-поза-вчерашний день (равно как и считать QoS инструментом для максимального забивания доступной полосы). Сейчас концепция другая. VoIP через софт-свич. Софт-свич как платформа для IMS. all-over-ip позволяет сегодня ничего не меняя в инфраструктуре мгновенно получать новый сервис (так же, как получались до этого существующие сервисы) как только провайдер запустит его у себя на ims-е. all-over-ip позволяет совершенно без проблем тягать за собой чуть ли не по всему миру, скажем, телефонный номер (что в случае традиционной телефонии с использованием v5.2 (боже сколько оно денег стоит) было конечно частично возможно, но только частично). All-over-ip позволяет сегодня работать в оффисе 10 человекам, а завтра так же просто запустить 100 человек (даже банальная оффисная телефония: порты/платы в АТС закончились и привет. Жди пока новое оборудование прийдет -- это реальная ситуация крупного офиса).
Сегодня стоимость подачи широкой полосы стремительно падает (просто стремительно). Нет нужды инжинирить сеть таким образом, чтобы плотненько-плотненько все забивать (в ущерб качеству). Гораздо проще расчитать что нужно для нормального качества и расширить инфраструктуру под такие потребности.
no subject
Date: 2006-10-19 12:33 pm (UTC)Это всё как раз понятно.
> Сегодня стоимость подачи широкой полосы стремительно падает (просто стремительно).
А способность её забить растёт ещё быстрее.