Re: [Dyncast] edge capability feedback

Joel Halpern Direct <jmh.direct@joelhalpern.com> Fri, 12 March 2021 11:42 UTC

Return-Path: <jmh.direct@joelhalpern.com>
X-Original-To: dyncast@ietfa.amsl.com
Delivered-To: dyncast@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B67D3A1901 for <dyncast@ietfa.amsl.com>; Fri, 12 Mar 2021 03:42:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Level:
X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id av8ijzJvTbjJ for <dyncast@ietfa.amsl.com>; Fri, 12 Mar 2021 03:42:43 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D91E13A18FE for <dyncast@ietf.org>; Fri, 12 Mar 2021 03:42:43 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4DxkSz3sH4z6G9HM; Fri, 12 Mar 2021 03:42:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1615549363; bh=ewIDfY6fz3eiNUMIasq2W3rJ+e6lq4UmV3tv6UY3RhA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=bN+zU5EuUv6pvY4kwF2lPdKlPNsMxpjN8egN7zlqLfHziuMpW/XreuwBQZu9AhTOX OfIvHMRx+xZrBCPiC7FO3Muwl9kfTr1MZCzlCw+gOehG1Xa8Io7P6UGEoCluwXKaen 6fBBdxMYZqsHm1hPoBpWNy2OKyTRG86vxasrYSe4=
X-Quarantine-ID: <q7OeuF4T-I6v>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4DxkSy2Wblz6G7dP; Fri, 12 Mar 2021 03:42:42 -0800 (PST)
To: "Milheiro Mendes, Paulo Jorge" <paulo.mendes@airbus.com>, Carsten Bormann <cabo@tzi.org>
Cc: dyncast <dyncast@ietf.org>
References: <20210311102435132657878@chinamobile.com> <9A6BA68B-3916-413E-BD29-62D4096DF1D3@senki.org> <00CCE76F-D3F8-49DD-8E11-29E7DBB956E1@huawei.com> <5EEEA7D8-D4E7-42AE-9D40-2DF6DF744567@chinamobile.com> <ea129e08-d5b2-5edb-a5ee-8362b12dc2b5@joelhalpern.com> <B930F50D-4A0C-4DAB-A3E5-0CD308CEB67F@tzi.org> <CAD6RcJZ-vSxzEEDBDHwwqQuMWQ9Ws=vs8j4W=cAS12m+cAMj7w@mail.gmail.com>
From: Joel Halpern Direct <jmh.direct@joelhalpern.com>
Message-ID: <d85e3f5e-bbbf-757e-bd92-fac861166961@joelhalpern.com>
Date: Fri, 12 Mar 2021 06:42:40 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <CAD6RcJZ-vSxzEEDBDHwwqQuMWQ9Ws=vs8j4W=cAS12m+cAMj7w@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dyncast/A0mma47wAKY4AoBleLK_ClaSVNk>
Subject: Re: [Dyncast] edge capability feedback
X-BeenThere: dyncast@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dyncast.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dyncast>, <mailto:dyncast-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dyncast/>
List-Post: <mailto:dyncast@ietf.org>
List-Help: <mailto:dyncast-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dyncast>, <mailto:dyncast-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Mar 2021 11:42:46 -0000

You don't want the client to ask a server the question?
Are you planning to have these applications run without DNS?
Whether the server is actually DNS or is some other protocol that is 
used instead, there is no need for this problem to cause any more delay 
than DNS.

And saying that the server won't know the answer seems rather odd.  If 
we design the system so that the servers get the information, then they 
get the information.  And then can apply whatever policies, logic, 
calculation, etc that is needed to make the per-suer decision.  In fact, 
since the servers can also have user poliy information if we want, they 
are better able than the indiivdual routers to do this kind of thing.

If we are not going to go this route, then we need to get rid of the 
user state requirements and recast the flow stickiness in a way that 
does not have forwarding routers doing flow-stateful forwarding.

Separately, if we really don't think the UE can issue the queries, then 
lets use an approach like LISP where we can still decouple the 
information from routing, and use an edge encapsulation to represent the 
decision.

It just seems to me that involving the UE is simpler, particularly 
because the problem we are trying to address is new applications, not 
existing ones.

Yours,
Joel

On 3/12/2021 2:29 AM, Milheiro Mendes, Paulo Jorge wrote:
> I fully agree that the logistics of having a client "asking a server" 
> does not align with the aim of Dyncast, to the best of my understanding. 
> The advantage of any anycast type of solution is exactly having clients 
> that are agnostic of the servers that may provide an answer. The client 
> needs to ask the network itself. So it is up to D-routers at the edges 
> to get to a consensus about who should reply. Following what Tianji 
> said, the issue is about what are the “consensus selection criteria’ 
> across D-routers and not numerous UEs.
> 
> Cheers
> 
> *Dr. Paulo Mendes*
> 
> Senior Scientist
> 
> Central Research and Technology, XRC
> 
> *Airbus*
> 
> ---- AIRBUS AMBER ----
> 
> 
> 
> On Fri, Mar 12, 2021 at 7:17 AM Carsten Bormann <cabo@tzi.org 
> <mailto:cabo@tzi.org>> wrote:
> 
>     On 12. Mar 2021, at 03:29, Joel M. Halpern <jmh@joelhalpern.com
>     <mailto:jmh@joelhalpern.com>> wrote:
>      >
>      > If the UE had a way to ask an informed server, there would be no
>     need for the UE to have a "significant amount of new logics".
>      > And we would not have to worry about overloading routing with
>     behavior and data that it does not need.  And we would naturally get
>     the needed stickiness.
> 
>     As far as I understand dyncast, I see the following two reasons for
>     not simply falling back to an “ask a server” approach:
> 
>     * Just-send.  See slide 35 on [1].  This assumes that saving that
>     round-trip is a relevant consideration for some applications.  (It
>     is hard to amortize the round-trip when progress (same slide) is
>     needed; of course the client could proactively ask at the start of
>     each new service period — but that creates a constant load.)
>     * The server may not know.  Even if the server is reached using
>     anycast, it may not have a way to get input from the routing system
>     that is knowledgeable about the specific network environment of the
>     client.  This becomes relevant when the “last mile” provides choices
>     and there is more than one edge server cluster close to the client.
> 
>     It seems to me that dyncast has not previously been pursued mainly
>     because there weren’t that many applications that could actually
>     benefit from addressing these two considerations.
> 
>     Grüße, Carsten
> 
>     [1]
>     https://github.com/dyncast/ietf110/blob/main/dyncast-ietf110-side-meeting-full-deck.pdf
>     <https://github.com/dyncast/ietf110/blob/main/dyncast-ietf110-side-meeting-full-deck.pdf>
> 
>     -- 
>     Dyncast mailing list
>     Dyncast@ietf.org <mailto:Dyncast@ietf.org>
>     https://www.ietf.org/mailman/listinfo/dyncast
>     <https://www.ietf.org/mailman/listinfo/dyncast>
> 
> The information in this e-mail is confidential. The contents may not be 
> disclosed or used by anyone other than the addressee. Access to this 
> e-mail by anyone else is unauthorised.
> If you are not the intended recipient, please notify Airbus immediately 
> and delete this e-mail.
> Airbus cannot accept any responsibility for the accuracy or completeness 
> of this e-mail as it has been sent over public networks. If you have any 
> concerns over the content of this message or its Accuracy or Integrity, 
> please contact Airbus immediately.
> All outgoing e-mails from Airbus are checked using regularly updated 
> virus scanning software but you should take whatever measures you deem 
> to be appropriate to ensure that this message and any attachments are 
> virus free.