Ну почему. Я знаю что по крайней мере по городу 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 и полосы пропускания и был разработан исходя из этих требований (вспомните где и когда). Он также подразумевает тотальное недоверие всем узлам на пути следования пакета и полной независимостью отдельных соединений друг от друга. Все эти предположения в реальных сетях не выполняются и соответственно протокол спроектированный с их учетом был бы намного эффективнее.
![[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 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 и полосы пропускания и был разработан исходя из этих требований (вспомните где и когда). Он также подразумевает тотальное недоверие всем узлам на пути следования пакета и полной независимостью отдельных соединений друг от друга. Все эти предположения в реальных сетях не выполняются и соответственно протокол спроектированный с их учетом был бы намного эффективнее.