SCTP подумалось, что наверное альтернативой TCP он станет не при моей жизни, но в теории его достаточно выгодно использовать в PEP'ах. То есть заворачивать в него TCP/UDP трафик, когда линк имеет длинный RTT и большую потерю пакетов (например 3g) или когда несколько 3g/4g объединены в один узел (бондинг или тупой sch_teql).
Из явных профитов протокол умеет multiplexing из коробки, в случае потери пакета SCTP, в отличие от TCP, может сказать какой именно пакет потерялся, умеет окна > 64K (критично для большого BDP) + multihoming (http://tdrwww.iem.uni-due.de/inhalt/forschung/sctp_fb/sctp_multihoming.html)
Сейчас SCTP вроде как активно развивается проектом lksctp (SCTP for linux kernel): lksctp.sourceforge.net
По производительности SCTP пока что проигрывает TCP: datatag.web.cern.ch
Однако, его вполне можно юзать (например для ситуации, которую я описал выше): linuxjournal.com
P/S:
Мои же тесты показали, что при большом BDP и низкой потере пакетов, SCTP проигрывает TCP c Hybla в качестве congestion control алгоритма (http://hybla.deis.unibo.it/)
После вдумчивого тыканья палочкой в Из явных профитов протокол умеет multiplexing из коробки, в случае потери пакета SCTP, в отличие от TCP, может сказать какой именно пакет потерялся, умеет окна > 64K (критично для большого BDP) + multihoming (http://tdrwww.iem.uni-due.de/inhalt/forschung/sctp_fb/sctp_multihoming.html)
Сейчас SCTP вроде как активно развивается проектом lksctp (SCTP for linux kernel): lksctp.sourceforge.net
По производительности SCTP пока что проигрывает TCP: datatag.web.cern.ch
Однако, его вполне можно юзать (например для ситуации, которую я описал выше): linuxjournal.com
P/S:
Мои же тесты показали, что при большом BDP и низкой потере пакетов, SCTP проигрывает TCP c Hybla в качестве congestion control алгоритма (http://hybla.deis.unibo.it/)