Лет 30-40 назад было много подходов к этому снаряду. В общем, тогда отказались от такого подхода, потому что в RTT входят динамические параметры (задержка в очередях, например), на которые влияет решение о выборе маршрута. В результате возникает обратная связь, из-за которой маршрутизацию начинает постоянно колбасить. Простейший пример: два подзагруженных аплинка A и B, выбираем A - RTT через A тут же вырос, переключаемся на B - RTT через A упал, а через B вырос, и так до бесконечности. В общем, лет 20 назад решили, что примешивание данных data plane к control plane - это Bad Practice. А сейчас FV-то побольше на полтора-два порядка.
Сейчас, если есть достаточно intelligence, чтобы отличать мух от котлет, то можно в SDN поиграться, но дело непростое. С наскоку не получится.

rsvp-te auto-bw с метриками по latency с поправкой на увеличение метрик на один-два порядка на второстепенные пути куда даже со сравнимой задержкой трафик лучше не пускать - и вот уже хорошее приближение к коротким путям хотя бы внутри себя.
если потом кумулятивную метрику использовать в bgp как metric2 - то и исходящий трафик хотя бы до точки выхода можно подравнять для равно-длинных маршрутив, но тут уже много нюансов лезет
ну и да, попутно ощущуешь себя бетатестером софта всех вендоров вместе взятых 😉

это подходит для энтов с оверлеями скорее

реализации есть - внешняя политика гугла

это плохой путь. можно автоматизированно высчитывать rtt syn<->ack в абонентском трафике и группировать до префиксов из fv

чтобы это вычислять через разных провайдеров иметь абонентов-жертв в разных /24, которые анонсятся только в один провайдер, а в другие анонсится меньшая маска

собственно гугл постоянно этим и занимается (измеряет rtt handshake-а)

это если есть возможность его получать, что оператору достаточно дорого с хорошим покрытием. С сервисами конечно нужно использовать клиентские метрики.

оно создано не для сокращения латенси, а для сокращения платежей в сторону дорогих каналов

носки и футболка у них норм кстати. ))

по факту же просто берется топ-X игр, вычисляются их сервера и вручную тюнится bgp в целях минимизации rtt + делается отслеживание изменения этих latency в условном заббиксе

это если речь идет о b2c-сегменте

Не знаю как у РТК, а у ТТК всё было просто.
Есть оптический стык с китайцами, китайцы в целом были не против пиринга, ТТК - тоже.
Международники помогли наладить общение, тех. блок посчитал.
Ну и подняли.
Правда заняло это года полтора по времени.
😎

Китайцы не против пиринга? Ггг.

10 лет назад, когда это начиналось - были не против.
Лично ж общался с VP CT на эту тему.

А, 10 день назад - ок, согласен тогда они ещё делали вид что белые и пушистые

вообще если в обмене будут участвовать только непосредственные соседи, этого будет достаточно...  но надо продумать, именно как igp для оверлея смысл

это вам не BGP под KDE настраивать

Что за печь он там останавливает?