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