[Drip] MPTCP (was RE: Comment on -arch-22)

[[e-mail]]

Re-

(changing the title as this is not within the scope of drip).

MPTCP-related matters can be discussed in tcpm since mptcp wg is closed. General multipath considerations can be discussed in tsvwg or panrg (for research oriented matters).

UAS-related activities and space in general were presented in previous mptcp meetings. See, e.g., https://www.ietf.org/proceedings/93/slides/slides-93-mptcp-1.pdf

Cheers,
Med

De : Jens Finkhaeuser <[e-mail]>
Envoyé : jeudi 24 mars 2022 13:59
À : Robert Moskowitz <[e-mail]>
Cc : Card, Stu <[e-mail]>om>; [e-mail]; BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Objet : Re: [Drip] Comment on -arch-22

Hi,

there is some conflict between the aviation world and the Internet world, and since they meet in UAS, that's where the conflict happens.

------- Original Message -------
On Thursday, March 24th, 2022 at 13:05, Robert Moskowitz <[e-mail]<mailto:[e-mail]>> wrote:


Handoff among different links (and different link technologies) is something we are trying to address. In our own test flights, for C2 (not UAS RID), we have used HIP, MP-TCP and other protocols to fail over transparently
Yes, we essentially replicate MP-TCP components but for strictly datagram/packet oriented "links" (terminology is a mess here with respect to ISO/OSI but it seemed the best compromise). This is borne out of issues with MP-TCP we've had in practice in border regions and completely unrelated to drones.

The protocol we've built here is a (set of) state machine(s) that observe/manage unidirectional flows and consider a multi-link established if at least one unidirectional flow in either direction is active. I suppose it's a generalized form of MP-TCP's behaviour. Data is encapsulated and sent over the highest priority egress flow.

In practice, we've mostly used UDP/IP uniflows that then come in pairs, so the protocol is a little overgeneralized for this case. However, it allows us to use different send and return channels.

I've written a draft paper about this, but it never got all that far due to other work items gaining priority. If there's an interest in this in the IETF, I wouldn't quite know which WG or when to carve out time to convert this to an IETF appropriate form. Plus, my employer would have to agree.

Not that this is the main topic here.


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.