Re: [tcpm] [Can] draft-wang-tcpm-tcp-service-affinity-option (RE: Proposed CAN WG charter for discussion)
Aijun Wang <wangaijun@tsinghua.org.cn> Thu, 09 February 2023 08:46 UTC
Return-Path: <wangaijun@tsinghua.org.cn>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF2D2C159A1D; Thu, 9 Feb 2023 00:46:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVnXG0E8QS24; Thu, 9 Feb 2023 00:46:07 -0800 (PST)
Received: from mail-m121145.qiye.163.com (mail-m121145.qiye.163.com [115.236.121.145]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E17C14F72D; Thu, 9 Feb 2023 00:46:04 -0800 (PST)
Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m121145.qiye.163.com (Hmail) with ESMTPA id AFBA2800147; Thu, 9 Feb 2023 16:45:57 +0800 (CST)
From: Aijun Wang <wangaijun@tsinghua.org.cn>
To: mohamed.boucadair@orange.com, "'Jeffrey (Zhaohui) Zhang'" <zzhang=40juniper.net@dmarc.ietf.org>, adrian@olddog.co.uk, 'can' <can@ietf.org>
Cc: 'tcpm' <tcpm@ietf.org>, 'JACQUENET Christian INNOV/NET' <christian.jacquenet@orange.com>
References: <tencent_32B63FADD3332B6265234AFB42B2BB27CE08@qq.com> <03b301d9372b$1ef1ba20$5cd52e60$@olddog.co.uk> <26636_1675411555_63DCC063_26636_244_1_f9f47354d2054423aad97f4377df3e09@orange.com> <BL0PR05MB5652399C0832FAF4757573C0D4DB9@BL0PR05MB5652.namprd05.prod.outlook.com> <00d701d93b90$d5985540$80c8ffc0$@tsinghua.org.cn> <12949_1675848237_63E36A2D_12949_125_1_b91655c7984f48c4b541337f7d89fa56@orange.com>
In-Reply-To: <12949_1675848237_63E36A2D_12949_125_1_b91655c7984f48c4b541337f7d89fa56@orange.com>
Date: Thu, 09 Feb 2023 16:45:56 +0800
Message-ID: <013001d93c62$ed7994d0$c86cbe70$@tsinghua.org.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0131_01D93CA5.FBA31660"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGIFX9hAerfIvoT5R2l5ckIh8BCmAIdeNt1AsTjTzwBtauTngKiAuhKAauNdtKvEWnGkA==
Content-Language: zh-cn
X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFKTEtLSjdXWS1ZQUlXWQ8JGhUIEh9ZQVlDSh4aVkgYGk4fSUIYTEkeGVUTARMWGhIXJB QOD1lXWRgSC1lBWUlKQlVKT0lVTUJVTE5ZV1kWGg8SFR0UWUFZT0tIVUpKS09ISFVKS0tVS1kG
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6OAg6ARw*ST0cSS4yTCwSPgsK UUlPCQhVSlVKTUxOQkhJSE5DTkNLVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQU9DTktDNwY+
X-HM-Tid: 0a86355a5533b03akuuuafba2800147
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/vBgTZjX8vPov4d6ScbyvmyqVp3I>
Subject: Re: [tcpm] [Can] draft-wang-tcpm-tcp-service-affinity-option (RE: Proposed CAN WG charter for discussion)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Feb 2023 08:46:11 -0000
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 Servers 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: can-bounces@ietf.org <can-bounces@ietf.org> On Behalf Of mohamed.boucadair@orange.com Sent: Wednesday, February 8, 2023 5:24 PM To: Aijun Wang <wangaijun@tsinghua.org.cn>; 'Jeffrey (Zhaohui) Zhang' <zzhang=40juniper.net@dmarc.ietf.org>; adrian@olddog.co.uk; 'can' <can@ietf.org> Cc: 'tcpm' <tcpm@ietf.org>; JACQUENET Christian INNOV/NET <christian.jacquenet@orange.com> 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 dont 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 Im 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 <wangaijun@tsinghua.org.cn <mailto:wangaijun@tsinghua.org.cn> > Envoyé : mercredi 8 février 2023 08:42 À : 'Jeffrey (Zhaohui) Zhang' <zzhang=40juniper.net@dmarc.ietf.org <mailto:zzhang=40juniper.net@dmarc.ietf.org> >; BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com> >; adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> ; 'can' <can@ietf.org <mailto:can@ietf.org> > Cc : 'tcpm' <tcpm@ietf.org <mailto:tcpm@ietf.org> > 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: can-bounces@ietf.org <mailto:can-bounces@ietf.org> <can-bounces@ietf.org <mailto:can-bounces@ietf.org> > On Behalf Of Jeffrey (Zhaohui) Zhang Sent: Wednesday, February 8, 2023 12:06 AM To: mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com> ; adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> ; 'can' <can@ietf.org <mailto:can@ietf.org> > 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 peoples 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 <can-bounces@ietf.org <mailto:can-bounces@ietf.org> > On Behalf Of mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com> Sent: Friday, February 3, 2023 3:06 AM To: adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> ; 'can' <can@ietf.org <mailto:can@ietf.org> > 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 <can-bounces@ietf.org <mailto:can-bounces@ietf.org> > De la part de Adrian Farrel Envoyé : jeudi 2 février 2023 18:24 À : 'can' <can@ietf.org <mailto:can@ietf.org> > Objet : Re: [Can] Proposed CAN WG charter for discussion Hi John, all, Ive 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 cant 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.
- Re: [tcpm] [Can] Proposed CAN WG charter for disc… Aijun Wang
- [tcpm] draft-wang-tcpm-tcp-service-affinity-optio… mohamed.boucadair
- Re: [tcpm] [Can] draft-wang-tcpm-tcp-service-affi… Aijun Wang