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

Hi Dirk,

On 2021-02-23, at 10:13, Dirk Trossen <dirk.trossen@huawei.com> 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 [mailto:dyncast-bounces@ietf.org] On Behalf Of Carsten Bormann
> Sent: 22 February 2021 23:28
> To: dyncast@ietf.org
> 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:         https://datatracker.ietf.org/doc/draft-bormann-dyncast-affinity/
>> Html:           https://www.ietf.org/archive/id/draft-bormann-dyncast-affinity-00.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@ietf.org
> https://www.ietf.org/mailman/listinfo/dyncast