Development discussion of WireGuard
 help / color / mirror / Atom feed
* Multilink/handover: proposal
@ 2017-11-11 10:33 Tatsuyuki Ishi
  2017-11-11 10:39 ` Jason A. Donenfeld
  0 siblings, 1 reply; 2+ messages in thread
From: Tatsuyuki Ishi @ 2017-11-11 10:33 UTC (permalink / raw)
  To: wireguard

[-- Attachment #1: Type: text/plain, Size: 700 bytes --]

I have seen a thread regarding multilink this month, and I'm also interested in it.

I'm not exactly sure if this is a thing to implement in WireGuard layer (MPTCP mentioned in previous thread is a good competitor), but I have some ideas for its design.

Extending the "roaming" design, we can choose to not directly switch to the new peer but allow it to split the traffic. We start round robin, and in each time frame, we check how many packets have we received from each path, and adjust the ratio of sending. This way a disconnect should gracefully propagate.

How does this sound? Comments welcome.

NOTICE: I have mail delivery disabled. Please use "Reply All" so it's also directly sent to me.

[-- Attachment #2: Type: text/html, Size: 834 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Multilink/handover: proposal
  2017-11-11 10:33 Multilink/handover: proposal Tatsuyuki Ishi
@ 2017-11-11 10:39 ` Jason A. Donenfeld
  0 siblings, 0 replies; 2+ messages in thread
From: Jason A. Donenfeld @ 2017-11-11 10:39 UTC (permalink / raw)
  To: Tatsuyuki Ishi; +Cc: WireGuard mailing list

[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]

I'm pretty sure WireGuard is the wrong place to import the massive quantity
of research on asynchronous packet scheduling that's gone into creating
MPTCP. Instead, just use MPTCP. It works super well. You can even do it
over several WireGuard interfaces, need be.


On Nov 11, 2017 19:34, "Tatsuyuki Ishi" <ishitatsuyuki@protonmail.com>
wrote:

I have seen a thread regarding multilink this month, and I'm also
interested in it.

I'm not exactly sure if this is a thing to implement in WireGuard layer
(MPTCP mentioned in previous thread is a good competitor), but I have some
ideas for its design.

Extending the "roaming" design, we can choose to not directly switch to the
new peer but allow it to split the traffic. We start round robin, and in
each time frame, we check how many packets have we received from each path,
and adjust the ratio of sending. This way a disconnect should gracefully
propagate.

How does this sound? Comments welcome.

*NOTICE: I have mail delivery disabled. Please use "Reply All" so it's also
directly sent to me.*

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

[-- Attachment #2: Type: text/html, Size: 1951 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2017-11-11 10:35 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-11 10:33 Multilink/handover: proposal Tatsuyuki Ishi
2017-11-11 10:39 ` Jason A. Donenfeld

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).