Linux için Multipath TCP (2022)

Multipath TCP'ye Genel Bakış

• Multipath TCP (MPTCP), standart TCP'nin bir uzantısıdır ve RFC 8684'te tanımlanmıştır.
• Bir cihazın aynı anda birden fazla arayüz kullanarak tek bir MPTCP bağlantısı üzerinden TCP paketleri gönderip almasını sağlar.
• MPTCP, birden fazla arayüzün bant genişliğini birleştirebilir veya gecikmesi en düşük olan arayüzü tercih edebilir.
• Ayrıca bir yol devre dışı kalsa bile failover mümkündür ve trafik diğer yollara kesintisiz biçimde yeniden enjekte edilir.

MPTCP kullanım senaryoları

• MPTCP ile birden fazla yolun paralel veya eşzamanlı kullanılabilmesi, TCP'ye kıyasla yeni kullanım senaryoları doğurur:
  • Seamless handovers: Bağlantıyı koruyarak bir yoldan diğerine geçiş. Apple bu nedenle 2013'ten beri akıllı telefonlarda ağırlıklı olarak MPTCP kullanıyor.
  • Best network selection: Gecikme, kayıp, maliyet, bant genişliği gibi koşullara göre "en iyi" yolun kullanılması.
  • Network aggregation: Daha yüksek throughput için birden fazla yolun aynı anda kullanılması. Örnek: Dosyaları daha hızlı göndermek için sabit ve mobil ağların birleştirilmesi.

MPTCP kavramları

• IPPROTO_MPTCP protokolüyle (yalnızca Linux) yeni bir soket oluşturulduğunda, veriyi bir arayüz üzerinden taşımak için kullanılan normal TCP bağlantılarından oluşan alt akışlar (veya yollar) oluşturulur.
• Ek alt akışlar daha sonra ana bilgisayarlar arasında müzakere edilebilir.
• Uzak ana bilgisayarın MPTCP kullanımını algılayabilmesi için, temel TCP alt akışının TCP option alanına yeni alanlar eklenir.
• Bu alanlar arasında, diğer ana bilgisayara MPTCP'yi destekliyorsa kullanmasını bildiren MP_CAPABLE seçeneği de bulunur.
• Uzak ana bilgisayar veya aradaki middlebox'lar MPTCP'yi desteklemiyorsa, dönen SYN+ACK paketinin TCP option alanında MPTCP seçenekleri yer almaz.
• Bu durumda bağlantı normal TCP'ye "downgrade" olur ve tek yol üzerinden devam eder.

Bu davranış, Path Manager ve Packet Scheduler adlı iki dahili bileşen sayesinde mümkün olur.

Path Manager

• Path Manager, alt akışların oluşturulmasından silinmesine kadar tüm yaşam döngüsünden sorumludur ve adres duyurularını da yönetir.
• Genellikle istemci tarafı alt akışları başlatır, sunucu tarafı ise ADD_ADDR ve REMOVE_ADDR seçenekleri üzerinden ek adresleri duyurur.
• Linux v5.19 itibarıyla, net.mptcp.pm_type sysctl düğmesiyle kontrol edilen 2 Path Manager vardır:
  • in-kernel (tip 0): Tüm bağlantılara aynı kuralları uygular (ip mptcp'ye bakın)
  • userspace (tip 1): Kullanıcı alanı daemon'u (ör. mptcpd) tarafından kontrol edilir ve her bağlantı için farklı kurallar uygulanabilir

Packet Scheduler

• Packet Scheduler, kullanılabilir alt akışlar arasından bir sonraki veri paketini göndermek için hangi alt akışın kullanılacağını seçmekten sorumludur.
• Mevcut bant genişliği kullanımını en üst düzeye çıkarabilir, yalnızca gecikmesi en düşük olan yolu seçebilir veya yapılandırmaya göre başka politikalara karar verebilir.
• Linux v6.8 itibarıyla, net.mptcp sysctl düğmeleriyle kontrol edilen tek bir Packet Scheduler vardır.

MPTCP'nin başlıca özellikleri (Linux v6.10 itibarıyla)

• socket() sistem çağrısında IPPROTO_MPTCP protokol desteği
• Eş veya middlebox MPTCP'yi desteklemiyorsa MPTCP'den TCP'ye geri dönüş
• Çekirdek içi veya kullanıcı alanı yol yöneticisi kullanan yol yönetimi
• TCP soketlerinde yaygın olarak kullanılan soket seçenekleri
• MIB sayaçları, diag desteği (ss komutunda kullanılır), tracepoint'ler içeren hata ayıklama özellikleri

GN⁺ görüşü

• MPTCP, uç cihazın birden fazla ağa bağlı olduğu durumlarda oldukça faydalı bir teknolojidir. 5G-Wi-Fi handover veya heterojen ağ birleştirme gibi alanlarda etkili biçimde kullanılabilir.
• Ancak MPTCP'nin hem sunucu hem istemci tarafında uygulanmış olması ve ara ağın da MPTCP'yi desteklemesi gerekir. Bu nedenle yaygınlaşması zaman alacak gibi görünüyor.
• Google'ın QUIC protokolü de benzer multipath yetenekleri sunuyor; QUIC daha basit ve UDP tabanlı olduğu için daha hızlı yayılacağı öngörülüyor. MPTCP ile QUIC arasında rekabet bekleniyor.
• Çekirdeğe bağımlı Linux için MPTCP uygulamasından farklı olarak Apple, MPTCP'yi kendi kullanıcı alanında uygulayıp iOS ve macOS'a entegre ediyor. Google da benzer bir yaklaşım benimseyebilir gibi görünüyor.
• MPTCP'nin yol kontrolü ve scheduling politikalarının uygulama gereksinimlerine en iyi şekilde uyarlanabilmesi için, uygulama ile MPTCP arasında API üzerinden bilgi alışverişi gerekebilir. Bunun için henüz standartlaştırılmış bir yöntem olmadığı anlaşılıyor.

[GN⁺]

Hacker News yorumları

• MPTCP’yi ilk kez 2013’te duyduğumda, mobil uygulamalar ağ değişimlerine zayıf tepki verdiği için kullanıcı deneyimini iyileştirmede büyük fayda sağlayacağını düşünmüştüm; ancak 10 yıl geçmesine rağmen neredeyse hiç ilgi görmemesi gerçekten hayal kırıklığı yaratıyor
• IPv4’ün 32 bitlik adres alanı ile TCP’nin bağlantı demetinde kaynak/hedef IP adreslerini kullanması arasında hangisinin daha üzücü olduğunu bilmiyorum. Bir zaman makinem olsaydı geçmişe dönüp bu ikisini değiştirmek isterdim
• MPTCP’nin pratik kullanımı, hızı artırmak için mobil ve Wi‑Fi ağlarını birlikte kullanmak; ancak mobil veri tarifeleri nedeniyle ben bunu her zaman kapalı tutuyorum, bu yüzden benim için pek işe yaramıyor
• OpenWrt türevi projeler gibi MPTCP kullanan projelere bağlantı verilmemesi üzücü. İki yıl boyunca GSOC’ta, OpenWrt’ye MPTCP desteği yamalayan bir öğrencinin mentorluğunu yaptım
• Şeffaf fallback varsa, uygulamanın neden açıkça opt-in yapması gerektiğini merak ediyorum. Çekirdeğin bunu tüm TCP bağlantıları için şeffaf biçimde ele alıp yol toplama/bağlantı tercihleri konusunda küresel kararlar vermesi en mantıklısı gibi görünüyor
• Linux ağ yığını ve sürücülerini destekleme/debug etme/düzeltme işiyle uğraşırken, MPTCP’nin düşük benimsenme oranına şaşırıyorum. SCTP gibi mevcut TCP’nin yerini almaya çalışan her şey, sanki yalnızca az sayıda geliştirici tarafından kullanılıp dünyanın geri kalanı tarafından unutulmaya mahkûm gibi
• MPTCP ile QUIC arasındaki mimari farkları ve yazarların önerdiği MPQUIC protokolünü açıklayan bir makale buldum. QUIC, tek bir UDP akışı üzerinde uygulama akışlarını çoklar; MPTCP ise tek bir akışı birden çok TCP alt akışına böler. MPQUIC ise uygulama akışlarını birden çok UDP alt akışı üzerinde çoklayarak bu iki özelliği birleştirir
• Apple da MPTCP’yi destekliyor ve bunu Siri’de kullanıyor
• Ortadaki middlebox MPTCP seçeneğini desteklemiyorsa, SYN+ACK paketinde MPTCP seçeneğinin yer almaması oldukça kısıtlayıcı görünüyor. Middlebox için tek gereksinim, MPTCP seçeneğini olduğu gibi iletmesi mi?
• MPTCP, güvenlik/gizlilik ayarları açısından faydalı olabilir. Örneğin trafiği birden çok uplink kanalına bölmek, Çin hükümetinin güvenlik duvarının engelleme amacıyla trafiği birleştirmesini zorlaştırır