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

[Aijun Wang <[e-mail]>]

Hi, Med:

 

Thanks for your information.

Actually, we investigate the existing approaches that you mentioned before:
1) MPTCP can solve the similar problem, but it is confined to the MPTCP
framework. We want to find one solution that can meet such requirements in
more general manner for TCP based application.

2) QUIC has such feature with its “Server’s Preferred Address”, but it
applies only to QUIC/UDP based application.  The migration pattern is
built-before-break, which may influence the performance of the CAN related
application.

 

These are the main reasons that we want find one lightweight solution for
the mentioned CAN scenario.

 

For the detail protocol design, I think using one new capability option
similar with EDO, and using the format of shared TCP option will be better
than the current approach.

We will review the related documents in more detail and update the solution
later.

 

Thanks for your suggestions!

 

Best Regards

 

Aijun Wang

China Telecom

 

From: [e-mail] <[e-mail]> On Behalf Of
[e-mail]
Sent: Wednesday, February 8, 2023 5:24 PM
To: Aijun Wang <[e-mail]>; 'Jeffrey (Zhaohui) Zhang'
<zzhang=[e-mail]>; [e-mail]; 'can'
<[e-mail]>
Cc: 'tcpm' <[e-mail]>; JACQUENET Christian INNOV/NET
<[e-mail]>
Subject: [Can] draft-wang-tcpm-tcp-service-affinity-option (RE: Proposed CAN
WG charter for discussion)

 

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: 

o   An alternate design would be to enable MPTCP. The server will then add
its own unicast address and withdraw the anycast one. 

o   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: 

o   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.

o   Consider Adjusting the format of the option to make use of shared TCP
option (RFC 6994)

o   Pick an ExID and register it here:
https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-exi
ds.

 

Cheers,

Med

 

De : Aijun Wang <[e-mail]
<mailto:[e-mail]> > 
Envoyé : mercredi 8 février 2023 08:42
À : 'Jeffrey (Zhaohui) Zhang' <zzhang=[e-mail]
<mailto:zzhang=[e-mail]> >; BOUCADAIR Mohamed INNOV/NET
<[e-mail] <mailto:[e-mail]> >;
[e-mail] <mailto:[e-mail]> ; 'can' <[e-mail]
<mailto:[e-mail]> >
Cc : 'tcpm' <[e-mail] <mailto:[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-optio
n/ ) 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.