Re: [Dyncast] Instance Affinity (draft-bormann-dyncast-affinity-00.txt)

Dirk Trossen <> Tue, 23 February 2021 12:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0EECD3A2A8C for <>; Tue, 23 Feb 2021 04:25:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nZitBdmUVO-t for <>; Tue, 23 Feb 2021 04:25:26 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BD66F3A2A8A for <>; Tue, 23 Feb 2021 04:25:25 -0800 (PST)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4DlJ7R0gPMz67rlr; Tue, 23 Feb 2021 20:21:23 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2106.2; Tue, 23 Feb 2021 13:25:23 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Tue, 23 Feb 2021 12:25:22 +0000
Received: from ([]) by ([]) with mapi id 15.01.2106.006; Tue, 23 Feb 2021 12:25:22 +0000
From: Dirk Trossen <>
To: Carsten Bormann <>
CC: "" <>
Thread-Topic: [Dyncast] Instance Affinity (draft-bormann-dyncast-affinity-00.txt)
Thread-Index: AQHXCWoWU85veum6RkC4JZahG5ZjiKplc9wggAANCACAACoNgA==
Date: Tue, 23 Feb 2021 12:25:22 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [Dyncast] Instance Affinity (draft-bormann-dyncast-affinity-00.txt)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Feb 2021 12:25:28 -0000

Hi Carsten,

Thanks for the clarification, also regarding the use of a DNS 'starting point'. It seems that the way of handling (and realizing) affinity is a great topic for discussion during our side meeting. Your proposal is a good starting point for it and I can see how this could fit into the architecture that has been proposed. 



-----Original Message-----
From: Dyncast [] On Behalf Of Carsten Bormann
Sent: 23 February 2021 10:54
To: Dirk Trossen <>
Subject: Re: [Dyncast] Instance Affinity (draft-bormann-dyncast-affinity-00.txt)

Hi Dirk,

On 2021-02-23, at 10:13, Dirk Trossen <> wrote:
> What is striking is that you see this being done in a DNS-based resolution (requiring short TTLs, possibly VERY short, and no client caching).

DNS is a mechanism proposed to get naïve clients on board; which I think is necessary to get this whole thing going.
However, I would expect the main usage (and the full benefit) to be by “native” clients (that know about the rhythm and can do the service period number insertion themselves).

For clients that do use DNS, there is no need for switching off client caching, just for properly observing the short TTLs (10 s or less) in those client caches.  I know that resolvers often “round up” TTLs to ~ 300 s, but you wouldn’t use such a resolver here.

> Do you see your approach being reconcilable with the dyncast architecture, as proposed in the draft? 

Certainly.  The architecture really talks about how to do dyncast in the network, which I don’t touch (except with hints about the difference between instance and path affinity).

I was trying to define a client-network interface that enables the network to be stateless about the clients while still providing service instance affinity.  

So the state for a service invocation (close to what you call service demand) is in the client, and the client presents this state again and again with each packet (in the form of the destination address).  This means there is no need to do flow detection (to separate service invocations so a new one can switch to a more recent path), no binding tables etc.  That part of the architecture would simply not be used in my approach.  

A “D-Forwarder” can still be used for address translation into a domain with a different rhythm, but would otherwise not be needed.  The main addition to the architecture is the definition of a rhythm and the retention of the service-to-instance mapping (as such or as a routing table) for the number of service periods that constitute a service stretch.

Grüße, Carsten

> Best,
> Dirk
> -----Original Message-----
> From: Dyncast [] On Behalf Of Carsten 
> Bormann
> Sent: 22 February 2021 23:28
> To:
> Subject: [Dyncast] Instance Affinity 
> (draft-bormann-dyncast-affinity-00.txt)
> You may not see this because of the I-D frenzy, but I thought I might alert you anyway.  I have written a little draft that proposes a way to obtain service instance affinity without building network state that needs to scale with the number of clients/service invocations.  Feedback would be welcome if you like exploring ideas like this.
> Grüße, Carsten
>> Name:		draft-bormann-dyncast-affinity
>> Revision:	00
>> Title:		Providing Instance Affinity in Dyncast
>> Document date:	2021-02-22
>> Group:		Individual Submission
>> Pages:		7
>> Status:
>> Html: 
>> Abstract:
>>  Dyncast support in the network provides a client with a fresh 
>> optimal  path to a service provider instance, where optimality 
>> includes both  path and service provider characteristics.  As a 
>> service invocation  usually takes more than one packet, dyncast needs 
>> to provide instance  affinity for each service invocation.  Naive 
>> implementations of  instance affinity require per-application, per 
>> service-invocation  state in the network.
>>  The present short document defines a way to provide instance 
>> affinity  that does not require, but also does not rule out 
>> per-application  state.
> --
> Dyncast mailing list

Dyncast mailing list