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

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. 

Best,

Dirk

-----Original Message-----
From: Dyncast [mailto:dyncast-bounces@ietf.org] On Behalf Of Carsten Bormann
Sent: 23 February 2021 10:54
To: Dirk Trossen <dirk.trossen@huawei.com>
Cc: dyncast@ietf.org
Subject: 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

--
Dyncast mailing list
Dyncast@ietf.org
https://www.ietf.org/mailman/listinfo/dyncast