search

mpiraux / draft-piraux-tcpls

Other
0 stars 0 forks source link

Clarify Migration (4.2.3) #4

Open frochet opened 3 years ago

frochet commented 3 years ago

I am not sure to understand the difference between the two paragraphs.

In my implementation, I use coupled streams to migrate. This does not look to be the case here.

Can we confirm/infirm if coupled streams for migration is on the table in this draft? I believe it should, it a nice usage of multiple path capabilities.

mpiraux commented 3 years ago

All frames are idempotent. So they can be transmitted in any order over one or several connections. Connection migration becomes simple, an endpoint retransmits the frames for which an ACK of their record is missing. The paragraph emphasises that both passive and active migration leverage the same protocol feature.

frochet commented 3 years ago

Alright, but it means we cannot do application-level type of migration without enabling failover. It is kinda a downgrade.

Mmh. or not? That really depends whether app-level conn migration can be useful without any notion of connection reliability.

mpiraux commented 3 years ago

Mmh. or not? That really depends whether app-level conn migration can be useful without any notion of connection reliability.

That's my opinion also. I don't really see a use for it. In any cases, endpoints could negotiate an extension to avoid sending ACKs, and retransmissions when migrating. But I believe the base case is enabling ACKs.

frochet commented 3 years ago

Yep. But I can imagine some weird app usage in privacy-specific context that would regularly move the stream from one network to another (or back and forth) even if the client is not mobile. And non-mobile clients unlikely enable failover.

mpiraux commented 3 years ago

Then specify it as an extension disabling the ACKs and retransmissions.