А если свитч или раутер умрёт? Или кто-то STP дерево перекрутит? Сейчас телефоны могут быть отдельно, компьютеры - отдельно. Есть возможность связаться по крайней мере админам если сеть лежит. А после интеграции что - "Саратов!! Саратов!!!", да?
Ну почему. Я знаю что по крайней мере по городу 1) оптика есть, 2) она достаточно новая, 3) никто в IP это не загоняет. И точно так же по GSM-сетям наших национальных операторов. Вот за рубеж они часто по IP гонят - да, бывает. Но это обычно менее фатально, да и у многих (UMC например) есть выбор, как выходить - по IP или традиционно...
это ты знаешь что городская оптика межатсная нормальная. а ведь ее при большом желании тоже можно "раком" шаловливыми ручками поставить. вопрос в другом, что этот сервис более критичен и за ним обычно более квалифицированные люди с большей отвественностью следят. в случае all-over-ip сетей в каждый дом просто увеличиваются шансы что оборудование проще, персонал обслуживающий и имеющий доступ менее квалифицированный и т. д. Но как бы сущность при этом не меняется: есть оборудование клиента, есть провод которым он подключен к поставщику услуг, есть сеть поставщика услуг. Принципиальной разницы нет будет ли перебита экскаватором труба в которой шли 100-парка с аналоговым телефоном и оптика с цифрой -- ты лишишься обоих проводных линков в твою квартиру. GSM (или другое средство) деверсификации линка позволит тебе связатся с поставщиком услуг. а к сетям поставщика услуг, да, просто начинают выдвигатся большие требования по надежности. А там, какая разница что во что инкапсулировано в их сетях если они гарантируют надежность до какого-то уровня ?
> вопрос в другом, что этот сервис более критичен и за ним обычно более квалифицированные люди с большей отвественностью следят.
Угу - и динамический раутинг ой как не любят:) На каждом узле все городские префиксы прописывают. Впрочем, я заранее согласен, что это правильно:)
> Принципиальной разницы нет будет ли перебита экскаватором труба в которой шли 100-парка с аналоговым телефоном и оптика с цифрой -- ты лишишься обоих проводных линков в твою квартиру.
Диверсификация услуг даёт в частности и большую вероятность того, что центры раздачи этих услуг имеют разные системы кабелей, электропитания и прочего.
> GSM (или другое средство) деверсификации линка позволит тебе связатся с поставщиком услуг. а к сетям поставщика услуг, да, просто начинают выдвигатся большие требования по надежности. А там, какая разница что во что инкапсулировано в их сетях если они гарантируют надежность до какого-то уровня ?
Сейчас меня обзовут телефонистом, но я слабо верю в способности IP гарантировать надёжность, когда он весь построен по принципу "best effort" и разнообразные виды congestion control не встроены в основные механизмы, а привешиваются сбоку припёка.
Я бы тебя обозвал сторонником time division и противником пакетных сетей. За вопросами надежности - к сегодняшним IP-телефонистам. Я думаю на первых временах ненадежность будет похожа на первые аналоговые успехи - в среднем связь есть, но ничего не слышно.. Со временем думаю все будет пучком.
Меня больше пугает не пакетизация как таковая, а навешивание перспективных технологий на устаревший и без того IP. Ну и факт что TCP не собирается умирать а живее всех живых. Речь идет не только о том что он проектировался не глядя на механизмы QoS и congestion control, а даже о том что сбоку навешенные ECN и прочие фенечки большой частью реализаций просто не поддерживаются и поддерживаться не собираются.
> Я бы тебя обозвал сторонником time division и противником пакетных сетей.
Моя основная мысль - что имея только пакетную сеть, жёсткий time division обеспечить крайне сложно (на современном технологическом уровне). И что обеспечение надёжности разделением уровней реализации тут не проходит, значит, вместо многих уровней обеспечения надёжности мы получаем один с достаточно сомнительной репутацией.
> Меня больше пугает не пакетизация как таковая, а навешивание перспективных технологий на устаревший и без того IP. Ну и факт что TCP не собирается умирать а живее всех живых. Речь идет не только о том что он проектировался не глядя на механизмы QoS и congestion control, а даже о том что сбоку навешенные ECN и прочие фенечки большой частью реализаций просто не поддерживаются и поддерживаться не собираются.
Ну с TCP, мне кажется, всё-таки полегче. Базовый уровень (на котором формализованы сегменты, окна, формат пакета), нижний уровень управления потоком (slow start и прочее) и верхний уровень управления потоком (все эти Reno, Vegas, New Reno...) на котором вычисляются долговременные тренды - хорошо разделены и свою роль играют. Но TCP для realtime непригоден в принципе, изначально. Значит - UDP, SCTP, всякие RTP поверх них. Значит - снова самопал в управлении потоком (RTCP чего-то там умеет, но не сильно).
Цитаты из http://www.ietf.org/rfc/rfc2582.txt (New Reno):
RFC 2001 [RFC2001] documents the following four intertwined TCP congestion control algorithms: Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery. RFC 2581 [RFC2581] explicitly allows certain modifications of these algorithms, including modifications that use the TCP Selective Acknowledgement (SACK) option [MMFR96], and modifications that respond to "partial acknowledgments" (ACKs which cover new data, but not all the data outstanding when loss was detected) in the absence of SACK. This document describes a specific algorithm for responding to partial acknowledgments, referred to as NewReno.
Добавьте к этому ECN (http://www.icir.org/floyd/ecn.html) и скажите, отличаются ли остальные технологии по степени реализации от ECN?
Почитайте RFC 3135 (TCP Performance Enhancing Proxies). Добавление пары PEP в середину линка сушественно повышает производительность TCP по части задержек и степени использования полосы. В РФСи речь идет конечно о каналах с большой latency по природе, но недостатки TCP очевидны.
Slow Start тоже мешает в случае отдачи скажем мелких документов по HTTP с сервера с гигабитным подключением клиенту с всего лишь мегабитом. PathMTU тоже наш враг хотя он безусловно лучше фрагментации.
TCP подразумевает гомогенность среды на всем пути следования пакета по части MTU и полосы пропускания и был разработан исходя из этих требований (вспомните где и когда). Он также подразумевает тотальное недоверие всем узлам на пути следования пакета и полной независимостью отдельных соединений друг от друга. Все эти предположения в реальных сетях не выполняются и соответственно протокол спроектированный с их учетом был бы намного эффективнее.
внутренняя телефония ходит по IP и она на CallManagerе.
какашка в чем-то выдающаяся (как им вообще до 4-ой версии умудрялись пользоваться, если и от 4.1(3) иногда остается ощущение пионерской поделки?!), но после внедрения и освоения пользователями новых возможностей плюсы новой технологии начинают проявляться довольно быстро и чем дальше, тем больше.
А что они по оптоволокну пускают? Просветите меня всем нехитрым стеком атс-ных протоколов. Я только знаю что на нижнем уровне идет 8 бит мю-лоу на 8кгц, это все объединяется в Е1-E3 с разделением по времени. А дальше куда? Они его пакетизируют и по АТМ (Another Terrible Mistake) пускают вместе со старыми сетями Frame Relay и прочими? Извините если прогнал, у меня в голове каша.
Вполне. IP поверх SONET передаётся через HDLC фрейминг. ATM - тут не знаю, можно применить тот же HDLC, но не совсем выгодно если метку границы передавать на каждую ячейку. Думаю, она передаётся один раз на несколько. Тут уже читать надо.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2006-10-15 01:29 pm (UTC)no subject
Date: 2006-10-15 02:00 pm (UTC)no subject
Date: 2006-10-15 02:18 pm (UTC)А кто знает ЧТО у оператора после базы идет?
no subject
Date: 2006-10-15 02:46 pm (UTC)no subject
Date: 2006-10-15 03:34 pm (UTC)no subject
Date: 2006-10-15 05:07 pm (UTC)вопрос в другом, что этот сервис более критичен и за ним обычно более квалифицированные люди с большей отвественностью следят.
в случае all-over-ip сетей в каждый дом просто увеличиваются шансы что оборудование проще, персонал обслуживающий и имеющий доступ менее квалифицированный и т. д. Но как бы сущность при этом не меняется: есть оборудование клиента, есть провод которым он подключен к поставщику услуг, есть сеть поставщика услуг. Принципиальной разницы нет будет ли перебита экскаватором труба в которой шли 100-парка с аналоговым телефоном и оптика с цифрой -- ты лишишься обоих проводных линков в твою квартиру. GSM (или другое средство) деверсификации линка позволит тебе связатся с поставщиком услуг. а к сетям поставщика услуг, да, просто начинают выдвигатся большие требования по надежности. А там, какая разница что во что инкапсулировано в их сетях если они гарантируют надежность до какого-то уровня ?
no subject
Date: 2006-10-15 07:18 pm (UTC)Угу - и динамический раутинг ой как не любят:) На каждом узле все городские префиксы прописывают. Впрочем, я заранее согласен, что это правильно:)
> Принципиальной разницы нет будет ли перебита экскаватором труба в которой шли 100-парка с аналоговым телефоном и оптика с цифрой -- ты лишишься обоих проводных линков в твою квартиру.
Диверсификация услуг даёт в частности и большую вероятность того, что центры раздачи этих услуг имеют разные системы кабелей, электропитания и прочего.
> GSM (или другое средство) деверсификации линка позволит тебе связатся с поставщиком услуг. а к сетям поставщика услуг, да, просто начинают выдвигатся большие требования по надежности. А там, какая разница что во что инкапсулировано в их сетях если они гарантируют надежность до какого-то уровня ?
Сейчас меня обзовут телефонистом, но я слабо верю в способности IP гарантировать надёжность, когда он весь построен по принципу "best effort" и разнообразные виды congestion control не встроены в основные механизмы, а привешиваются сбоку припёка.
no subject
Date: 2006-10-15 10:36 pm (UTC)Меня больше пугает не пакетизация как таковая, а навешивание перспективных технологий на устаревший и без того IP. Ну и факт что TCP не собирается умирать а живее всех живых. Речь идет не только о том что он проектировался не глядя на механизмы QoS и congestion control, а даже о том что сбоку навешенные ECN и прочие фенечки большой частью реализаций просто не поддерживаются и поддерживаться не собираются.
no subject
Date: 2006-10-16 06:13 am (UTC)Моя основная мысль - что имея только пакетную сеть, жёсткий time division обеспечить крайне сложно (на современном технологическом уровне). И что обеспечение надёжности разделением уровней реализации тут не проходит, значит, вместо многих уровней обеспечения надёжности мы получаем один с достаточно сомнительной репутацией.
> Меня больше пугает не пакетизация как таковая, а навешивание перспективных технологий на устаревший и без того IP. Ну и факт что TCP не собирается умирать а живее всех живых. Речь идет не только о том что он проектировался не глядя на механизмы QoS и congestion control, а даже о том что сбоку навешенные ECN и прочие фенечки большой частью реализаций просто не поддерживаются и поддерживаться не собираются.
Ну с TCP, мне кажется, всё-таки полегче. Базовый уровень (на котором формализованы сегменты, окна, формат пакета), нижний уровень управления потоком (slow start и прочее) и верхний уровень управления потоком (все эти Reno, Vegas, New Reno...) на котором вычисляются долговременные тренды - хорошо разделены и свою роль играют. Но TCP для realtime непригоден в принципе, изначально. Значит - UDP, SCTP, всякие RTP поверх них. Значит - снова самопал в управлении потоком (RTCP чего-то там умеет, но не сильно).
no subject
Date: 2006-10-16 02:36 pm (UTC)RFC 2001 [RFC2001] documents the following four intertwined TCP
congestion control algorithms: Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery. RFC 2581 [RFC2581] explicitly allows
certain modifications of these algorithms, including modifications
that use the TCP Selective Acknowledgement (SACK) option [MMFR96],
and modifications that respond to "partial acknowledgments" (ACKs
which cover new data, but not all the data outstanding when loss was
detected) in the absence of SACK. This document describes a specific
algorithm for responding to partial acknowledgments, referred to as
NewReno.
Добавьте к этому ECN (http://www.icir.org/floyd/ecn.html) и скажите, отличаются ли остальные технологии по степени реализации от ECN?
Почитайте RFC 3135 (TCP Performance Enhancing Proxies). Добавление пары PEP в середину линка сушественно повышает производительность TCP по части задержек и степени использования полосы. В РФСи речь идет конечно о каналах с большой latency по природе, но недостатки TCP очевидны.
Slow Start тоже мешает в случае отдачи скажем мелких документов по HTTP с сервера с гигабитным подключением клиенту с всего лишь мегабитом. PathMTU тоже наш враг хотя он безусловно лучше фрагментации.
TCP подразумевает гомогенность среды на всем пути следования пакета по части MTU и полосы пропускания и был разработан исходя из этих требований (вспомните где и когда). Он также подразумевает тотальное недоверие всем узлам на пути следования пакета и полной независимостью отдельных соединений друг от друга. Все эти предположения в реальных сетях не выполняются и соответственно протокол спроектированный с их учетом был бы намного эффективнее.
no subject
Date: 2006-10-15 02:56 pm (UTC)no subject
Date: 2006-10-15 03:30 pm (UTC)И тем более по нему не ходит внутренняя телефония, которая на Меридиане:)
no subject
Date: 2006-10-15 09:35 pm (UTC)какашка в чем-то выдающаяся (как им вообще до 4-ой версии умудрялись пользоваться, если и от 4.1(3) иногда остается ощущение пионерской поделки?!), но после внедрения и освоения пользователями новых возможностей плюсы новой технологии начинают проявляться довольно быстро и чем дальше, тем больше.
no subject
Date: 2006-10-15 10:42 pm (UTC)no subject
Date: 2006-10-16 06:02 am (UTC)no subject
Date: 2006-10-16 10:30 am (UTC)no subject
Date: 2006-10-16 02:13 pm (UTC)no subject
Date: 2006-10-16 02:20 pm (UTC)IP поверх SONET передаётся через HDLC фрейминг. ATM - тут не знаю, можно применить тот же HDLC, но не совсем выгодно если метку границы передавать на каждую ячейку. Думаю, она передаётся один раз на несколько. Тут уже читать надо.
no subject
Date: 2006-10-15 02:13 pm (UTC)Сообщить что сеть упала."
no subject
Date: 2006-10-22 11:43 am (UTC)а если SDH-мультиплексор сдохнет, по которому идет и IP, и обычная телефония, и все GSM-ищики с него же потоки берут ? :)