[Can] draft-wang-tcpm-tcp-service-affinity-option (RE: Proposed CAN WG charter for discussion)

[[e-mail]]

Hi Aijun,

(changing the title as this is not related to the charter discussion)

Thank you for sharing this pointer. Please find below some quick comments:

  *   Putting aside the delay induced to reestablish a connection with the selected service instance, the SAF option can be generalized to coordinate connection migration (instance A to instance B for offload reasons, for example).
  *   However, the current design requires to reopen a new connection.
  *   You may discuss why existing approaches are not sufficient for your use case:
     *   An alternate design would be to enable MPTCP. The server will then add its own unicast address and withdraw the anycast one.
     *   For QUIC, you don't even need to use multi-path extensions as this functionality can be provided by letting the server announce its Preferred Address (rfc9000.html#name-servers-preferred-address).
  *   Likewise, the document should discuss how to prevent misbehaving nodes to inject a SAF option to intercept the connections.
  *   On the TCP design:
     *   I'm not sure the use of a TCP control flag is justified. You may consider negotiating the support of the SAF option similar to, e.g., draft-ietf-tcpm-tcp-edo#section-5.1.
     *   Consider Adjusting the format of the option to make use of shared TCP option (RFC 6994)
     *   Pick an ExID and register it here: https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-exids.

Cheers,
Med

De : Aijun Wang <[e-mail]>
Envoyé : mercredi 8 février 2023 08:42
À : 'Jeffrey (Zhaohui) Zhang' <zzhang=[e-mail]>; BOUCADAIR Mohamed INNOV/NET <[e-mail]>; [e-mail]; 'can' <[e-mail]>
Cc : 'tcpm' <[e-mail]>
Objet : RE: [Can] Proposed CAN WG charter for discussion

Hi, All:

We have one proposal (https://datatracker.ietf.org/doc/draft-wang-tcpm-tcp-service-affinity-option/ ) that tries to solve the "service affinity" requirements for CAN application scenario.
The proposal has been presented in the past IETF 115 meeting in TCPM WG.
We are looking forwarding to the interested experts to working with us to improve the applicability of this work.

Best Regards

Aijun Wang
China Telecom

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Wednesday, February 8, 2023 12:06 AM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; 'can' <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Can] Proposed CAN WG charter for discussion

Hi,

Service affinity (stickiness) had been in the initial requirements, and even before the first CAN BoF there were some drafts on solutions for the service affinity, which involved lots of complexity for synchronizing forwarding state among edge routers (considering that a mobile a device could move from edge router to another yet it is desired to keep using the previous service node that is now farther away).

That is one of the reasons for some people's view "solve this outside the routing (or even IETF)".

At this time I do support the work in IETF and routing area, now that the overlay model has been assumed (with that the line between "network-centric" and "application-centric" has blurred, and we need a way to exchange the routing/computing metrics and synchronizing forwarding state for service affinity purposes).

To make CAN really useful for the targeted use cases, service affinity should be included, even though it had not been discussed much in the process of gaining consensus towards forming the WG.

Jeffrey



Juniper Business Use Only
From: Can <[e-mail]<mailto:[e-mail]>> On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Friday, February 3, 2023 3:06 AM
To: [e-mail]<mailto:[e-mail]>; 'can' <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Can] Proposed CAN WG charter for discussion

[External Email. Be cautious of content]

Hi Adrian, all,

Focusing on the specific point.

You are right that the steering is constrained as in most cases the same instance(s) should be preserved in subsequent exchanges assuming the initial multi-metric bounds are still honored.

Such constrained steering is not unique to CAN. For example, SFFs in SFC should preserve the same path when stateful SFs are solicited.

We may consider adding terms such as "Traffic Steering with Service Affinity", "Service Placement with Instance Preservation", or "Multi-Constrained Steering at Edges", etc. to the charter but I think that characterizing the selection process (and only the metrics) is part of the analysis/req items.

Cheers,
Med

De : Can <[e-mail]<mailto:[e-mail]>> De la part de Adrian Farrel
Envoyé : jeudi 2 février 2023 18:24
À : 'can' <[e-mail]<mailto:[e-mail]>>
Objet : Re: [Can] Proposed CAN WG charter for discussion

Hi John, all,

I've been following this thread with interest.

[Med] ...


* What seems to be unique about this work (and I think is captured well in the charter text) is the mix of metrics that need to be considered (network capabilities, network status, service node location, service node capabilities, service node status). This requires service-node-to-edge exchange of service node information as well as network-to-edge collection of network information. However, isn't a very important point being missed? The steering decision is transactional and not packet-by-packet. That is, if you are performing compute function, you cannot send one packet to one compute node and the next packet to a different node. The whole transaction must go to the same place. So steering decisions must be "sticky". Furthermore, there is surely a need for the user of the service to be able to classify the transaction (I think this is hinted at with "as appropriate to the service"). How much data? What sort of computational intensity? Only then can the right steering choice be made. I accept that this is probably a big topic that we don't need to get into in any detail at this stage of the discussion, but I'd like us to recognise in the charter text that this is not "packet steering" and nor is it "flow steering" - it is somewhere in between as "transaction steering". Sadly, I can't think of a concise way of saying this. Do we need an extra paragraph?

Hope this is helpful,
Adrian



_________________________________________________________________________________________________________________________

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.