Re: [alto] [art] Second early ART ART review of draft-ietf-alto-new-transport (-07)

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Mon, 05 June 2023 20:23 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B13C151524; Mon, 5 Jun 2023 13:23:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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, FREEMAIL_FROM=0.001, 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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 C1AC3ZoPUomM; Mon, 5 Jun 2023 13:23:32 -0700 (PDT)
Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 80F3EC14CE22; Mon, 5 Jun 2023 13:23:32 -0700 (PDT)
Received: by mail-pj1-x1033.google.com with SMTP id 98e67ed59e1d1-256a41d3e81so4511143a91.1; Mon, 05 Jun 2023 13:23:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685996612; x=1688588612; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=kbPLnM0vvDPkaxAff/JEMe3Tlc7SGtKyHfqjIksGCGs=; b=AOji2QLhJ9uR9r34bhBIwAME2JWVWG8fj55G1jPsi7PmMU3fImAAR9ILXPA1/ykwhz dpxb7AvPI0TfRbfdBd0/bz7gOGYsCrznRl1MPo9XWs0B8fNDXShsWJSh+iPQwMHhlpwT /06N8dnOXFnyv2cAqoXBaAUbMtiy33/SBl8i9Lu3qxpf13gDz2wz0N4Jr4AQvCnTZEg0 ocM7DV7yRUlKg+gkUwCZep9YMU4Eb6ddUEYJZWgAtxDJWiXnZIlQgCKLYWrBMkFYxJZq AjKHc8FooNGCN/tP0X8QzmwjmK9CJTzCFekeVHaMHwhC3lWa0giD8qEPpJuYHFndZlT2 HGCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685996612; x=1688588612; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=kbPLnM0vvDPkaxAff/JEMe3Tlc7SGtKyHfqjIksGCGs=; b=GqqjyneMAxOzQF2/rRd0s+lfTHoRxsAmMaSFgyK3IDEefyY7SGXotlLnEmWUcU7Jpi cHrEjtR7zKfvqGnVx/VGdIYijvQZK7wQFCp85SWab20XSIKtWg6/gxaMuNld6Nsay7Yc xh4EKhwgK3vNOEZJRB08R1TXvEpbh8rnFZhPJVSRDp9f3gX+xnhsnTlFUfv7u7/JVQAT rqbMYcg36ALals/FsmQDqg/TVc50NgA6HxD+4zpoAzqJ9+HAsoh+3V9oEXZqofAZ6e9u nxlOmarmzt+tOchVfFbKd4lcGGySd4ZQqszrXxS9VKoLVGiogPoKYel/KASi+rv6AVNH jP+g==
X-Gm-Message-State: AC+VfDxzgQ2swWnxgEarxj5jt4x+NHUzw6NI1e+Ealudf7AAQscJzzhC x77BIqH7EhOUAb2X81qOW5SiXYFzHZlgbmVg7el8Yy4BmW4=
X-Google-Smtp-Source: ACHHUZ4MchtCD6cpxFx4+OBKDWJEhhcACJQogStbvVgack0muFWSGd8aJ5G1ob8PbNckoQJhTED7OS9gxWmz/M0NH08=
X-Received: by 2002:a17:90a:11:b0:255:d878:704a with SMTP id 17-20020a17090a001100b00255d878704amr8580042pja.4.1685996611581; Mon, 05 Jun 2023 13:23:31 -0700 (PDT)
MIME-Version: 1.0
References: <CAKKJt-fiKTuycc2mAfMo1xWUnTaN42JfhkPfQzSwrMBCdDMnOg@mail.gmail.com> <12661_1679081730_6414C101_12661_142_1_7bba9e2d050d4ea69ff3380b0cfd37b9@orange.com> <4c60dc2c.1bfaf.1870750385b.Coremail.kaigao@scu.edu.cn> <58664799.26a7d.187bb77cd33.Coremail.kaigao@scu.edu.cn>
In-Reply-To: <58664799.26a7d.187bb77cd33.Coremail.kaigao@scu.edu.cn>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Mon, 05 Jun 2023 15:23:04 -0500
Message-ID: <CAKKJt-dx8uFjx6zj=03_XGJkNpi+BN4aaOCVn_OcmsqHMQk9zw@mail.gmail.com>
To: kaigao@scu.edu.cn
Cc: "alto@ietf.org" <alto@ietf.org>, mohamed.boucadair@orange.com, "draft-ietf-alto-new-transport@ietf.org" <draft-ietf-alto-new-transport@ietf.org>, "art@ietf.org" <art@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000203ce705fd67ad14"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/JGR_WNq3-cT-MU6V1lXsdxcFVic>
Subject: Re: [alto] [art] Second early ART ART review of draft-ietf-alto-new-transport (-07)
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Jun 2023 20:23:36 -0000

Hi, Kai,

On Tue, Apr 25, 2023 at 9:50 PM <kaigao@scu.edu.cn> wrote:

> Hi Spencer,
>
>
> We have prepared a pre-release of the new transport document. You can see
> the diffs with the link below, and the details are inline.
>
>
> Please let us know if the updates address your comments. We look forward
> to your feedback!
>

I've looked at your responses, and I'm happy. with them, and
especially with the addition of the last sentence in
https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-09#name-tips-with-different-http-ve,
which does explicitly explain how to make use of HTTP/3 in TIPS.

I apologize for my slow response - COVID-19 plus more travel wasn't helping
me focus!

Best luck with this draft.

Spencer


> Diff with -07:
>
>
> https://author-tools.ietf.org/diff?doc_1=draft-ietf-alto-new-transport-07&url_2=https://github.com/ietf-wg-alto/draft-ietf-alto-new-transport/releases/download/draft-ietf-alto-new-transport-08-snapshot-20230426/draft-ietf-alto-new-transport-08.txt
>
>
> Best,
>
> Kai
>
> -----Original Messages-----
> *From:*kaigao@scu.edu.cn
> *Sent Time:*2023-03-22 11:15:10 (Wednesday)
> *To:* "alto@ietf.org" <alto@ietf.org>, "Spencer Dawkins at IETF" <
> spencerdawkins.ietf@gmail.com>, mohamed.boucadair@orange.com
> *Cc:* "draft-ietf-alto-new-transport@ietf.org" <
> draft-ietf-alto-new-transport@ietf.org>, "art@ietf.org" <art@ietf.org>
> *Subject:* Re: RE: [art] Second early ART ART review of
> draft-ietf-alto-new-transport (-07)
>
> Hi Spencer,
>
>
> Thanks for the review. Please see our responses below
>
>
> -----Original Messages-----
> *From:*mohamed.boucadair@orange.com
> *Sent Time:*2023-03-18 03:35:29 (Saturday)
> *To:* "Spencer Dawkins at IETF" <spencerdawkins.ietf@gmail.com>, "
> alto@ietf.org" <alto@ietf.org>, "draft-ietf-alto-new-transport@ietf.org" <
> draft-ietf-alto-new-transport@ietf.org>
> *Cc:* "art@ietf.org" <art@ietf.org>
> *Subject:* RE: [art] Second early ART ART review of
> draft-ietf-alto-new-transport (-07)
>
> Hi Spencer,
>
>
>
> Thanks for providing the review in a timely manner. Much appreciated.
>
>
>
> Unless I’m mistaken, the review was not forwarded to the ALTO WG list. I’m
> adding the missing lists, fwiw.
>
>
>
> One quick comment on your previous comment about SETTINGS_ENABLE_PUSH, I
> remember the authors provided a detailed discussion of the issues your
> raised (see Slide 13 of
> https://datatracker.ietf.org/meeting/114/materials/slides-114-alto-alto-over-new-transport-01
> ).
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* art <art-bounces@ietf.org> *De la part de* Spencer Dawkins at IETF
> *Envoyé :* vendredi 17 mars 2023 00:53
> *À :* art@ietf.org
> *Objet :* [art] Second early ART ART review of
> draft-ietf-alto-new-transport (-07)
>
>
>
> This is my second early review of this document - the first was a review
> of -01.
>
>
>
> My "Ready with Issues" is based solely on the number of references to
> HTTP/3 server PUSH usage, which was tagged in my earlier review.
>
>
>
> Beyond that, and the following nits, the document was easy and pleasant
> for me to follow.
>
>
>
> Best wishes to the working group!
>
>
>
> I know a lot of things changed in this draft since I early-reviewed -01 -
> I'm now early-reviewing -07 - but I'm not sure that my previous observation
> about this HTTP setting
>
>
>
> 0x02     SETTINGS_ENABLE_PUSH (a BCP14 “MUST”)
>
>
>
> has been addressed.
>
>
>
> As I pointed out in my previous review RFC 9114 reserves this value in the
> parallel HTTP/3 registry (
> https://www.rfc-editor.org/rfc/rfc9114.html#iana-setting-table), and says
> this about these reserved values in
> https://www.rfc-editor.org/rfc/rfc9114.html#section-7.2.4.1:
> 7.2.4.1. <https://datatracker.ietf.org/doc/html/rfc9114#section-7.2.4.1>Defined
> SETTINGS Parameters
> <https://datatracker.ietf.org/doc/html/rfc9114#name-defined-settings-parameters>
>
>
>
> Setting identifiers that were defined in [HTTP/2
> <https://datatracker.ietf.org/doc/html/rfc9113>] where there is no
> corresponding HTTP/3 setting have also been reserved (Section 11.2.2
> <https://datatracker.ietf.org/doc/html/rfc9114#iana-settings>). These
> reserved settings *MUST NOT* be sent, and their receipt *MUST* be treated
> as a connection error
> <https://datatracker.ietf.org/doc/html/rfc9114#errors> of type
> H3_SETTINGS_ERROR
> <https://datatracker.ietf.org/doc/html/rfc9114#H3_SETTINGS_ERROR>.¶
> <https://datatracker.ietf.org/doc/html/rfc9114#section-7.2.4.1-5>
>
>
>
> I don't know what needs to be changed in this specification to reflect
> this, but even the abstract and the last paragraph of the Introduction
> refer to "native HTTP/2 or HTTP/3 server push".
>
>
>
> Section 2.4 and 2.5 address the use of TIPS inside an HTTP/1.x connection,
> which doesn't support server push, so I know you folks have thought about
> how that works.Do you need to address this for HTTP/3 as well?
>
>
>
> More strategically, should you be encouraging clients to add support for
> server PUSH in a new application protocol, if it's already been removed
> from HTTP/3? But I see this document is in WGLC now, so you can think about
> that and Do The Right Thing.
>
>
> KAI: Thanks for the comment. The current text does not work for HTTP/3, as
> you mentioned that the initialization of server push has changed in HTTP/3.
> However, it does not mean that the support for server push is removed in
> HTTP/3. We will update section 7.2 to specify how to enable server push in
> HTTP/3 using the procedure in
> https://www.rfc-editor.org/rfc/rfc9114.html#name-server-push.
>
>
> KAI: The process of enabling server push in HTTP/2 or /3 is now specified
> in Section 8.1.1.
>
>
> I have some BCP 14 questions about this text in
>
>
>
> *3.3. *
> <https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#section-3.3>
> *Uses*
> <https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#name-uses>
>
>
>
> This set may be any subset of the ALTO server's network information
> resources and may include resources defined in linked IRDs. However, it is
> RECOMMENDED that the ALTO server selects a set that is closed under the
> resource dependency relationship. That is, if a TIPS' "uses" set includes
> resource R1 and resource R1 depends on ("uses") resource R0, then the TIPS'
> "uses" set SHOULD include R0 as well as R1. For example, a TIPS for a cost
> map SHOULD also provide a TIPS view for the network map upon which that
> cost map depends.
>
>
>
> I have the same question about R1 and R0, but let's start with a specific
> case. If a TIPS for a cost map does not also provide a TIPS view for the
> underlying network map, what happens next?
>
>
> KAI: Thanks for the comment. If the TIPS (service) only provides a TIPS
> view for the cost map but not for the network map, the client will not be
> able to receive incremental updates about the network map. Thus, when there
> is a change to the network map, the change will be reflected in a TIPS
> incremental update of the cost map where the "depentdent-vtags" field will
> be updated (see
> https://datatracker.ietf.org/doc/html/rfc7285#section-11.2.3.6). Then,
> the client knows the mapping between IP prefixes and the PID values has
> changed but does not know the details. The client needs to query the
> dependent network map resource to get the new mapping.
>
>
> KAI: The paragraph is now in Section 5.3. We add a paragraph to clarify
> the case if the set is not closed.
>
>
>
> (Nit) is there a missing term after TIPS in "a TIPS for a cost map" in
> this paragraph?
>
>
> KAI: Not exactly but the text is a bit unclear. We propose to use the
> following text instead:
>
>
> ..., if a TIPS service provides a TIPS view for a cost map, it SHOULD also
> provide a TIPS view for the network map upon which that cost map depends.
>
>
> KAI: The proposed text is in Section 5.3.
>
>
>
> In *4.4. *
> <https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#section-4.4>*Close
> Request*
> <https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#name-close-request>
>
>
>
> An ALTO client can indicate it no longer desires to pull/receive updates
> for a specific network resource by "deleting" the TIPS view using the
> returned tips-view-uri and the HTTP DELETE method. Whether or not the
> server actually deletes the TIPS view is implementation dependent. Likely,
> a server will remove the client from a dependency set associated with the
> TIPS view. A server will not want to delete a TIPS view if another client
> is using it.
>
>
>
> I'm guessing here, but this looks like it's conflating client usage with
> server storage management. If client A says "delete the TIPS view", and no
> other client is using it, that view is deleted, but if another client is
> using it, and the view is not deleted, what happens next? I could imagine
> that a server might delete the underlying TIPS view when all clients who
> were using it have deleted it. Does server behavior in this case need to be
> implementation dependent?
>
>
> KAI: Thanks for the comment. From a client's point of view, it sees only
> one copy of the TIPS view for any resource. However, on the server side,
> there are different implementation options, especially for common resources
> (e.g., network map or cost map) that may be frequently queried by many
> clients:
>
>
> - create multiple copies, one for each client --> when the client deletes
> the view, delete it in the server storage
>
> - create one copy for all clients
>
>   - maintain a refcount --> when refcount == 0, delete
>
>   - never delete (thus no need to maintain the client usage)
>
>
> I think this is implementation dependent. Maybe the text is somehow
> misleading, how about the following?
>
>
> ...Whether or not the server actually deletes the TIPS view is
> implementation dependent. For example, an ALTO server may maintain a set of
> clients that subscribe to the TIPS view of a resource: a client that
> deletes the view is removed from the set, and the TIPS view is only removed
> when the dependent set becomes empty.
>
>
> KAI: Managing a shared view is in Section 9.7, which summarizes the cases
> that we discussed in the previous response.
>
>
>
> In this text,
> 8.1.
> <https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#section-8.1>Considerations
> for Load Balancing
> <https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#name-considerations-for-load-bal>
>
> TIPS allow clients to make concurrent pulls of the incremental updates
> potentianlly through different HTTP connections. As a consequence, it
> introduces additional complexties when the ALTO server is being load
> balanced -- a feature widely used to build scalable and fault-tolerant web
> services. For example, a request may be incorrectly processed if
>
>
>
>    - the backend servers are stateful, i.e., the TIPS view is created and
>    stored only on a single server;
>
>
>
>    - the ALTO server is using layer-4 load balancing, i.e., the requests
>    are distributed based on the TCP 5-tuple.
>
>
>
> are these conditions ANDed, or ORed? Is either condition sufficient to
> cause a problem, or are both required?
>
>
> KAI: The two conditions need to both be true to cause the problem. We
> propose to make this clear with the following text:
>
>
> .... For example, a request may be incorrectly processed if the following
> conditions both hold:
>
>
> KAI: The section is moved to Section 9.1 and we fixed the nits.
>
>
>
> Also, in the last paragraph of this section,
>
>
>
>    - For example, the ALTO server may configure layer-7 load balancers
>    that distribute requests based on URL or cookies.
>
>
>
> Isn't this talking something that an operator or provider of the ALTO
> server would do, rather than the ALTO server itself?
>
>
> KAI: Yes, it should be the operator/provider of the ALTO server than the
> server itself. Here is the proposed text:
>
>
> For example, the operator or the provider of the ALTO server may configure
> layer-7 load balancers that distribute requests based on URLs or cookies.
>
>
>
> I have a similar question about
> 8.2.
> <https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#section-8.2>Considerations
> for Choosing Updates
> <https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#name-considerations-for-choosing>
>
> TIPS should be cognizant of the effects of its update schedule, which
> includes both the choice of timing (i.e., when/what to trigger an update on
> the updates graph) and the choice of message format (i.e., given an update,
> send a full replacement or an incremental change).
>
>
>
> and
>
>
>
> Therefore, each TIPS may decide on its own whether to use JSON merge patch
> or JSON patch according to the changes in network maps.
>
>
>
> is TIPS thinking, or is that up to a human?
>
>
> KAI: It should be up to a human or the running code. The proposed text is
> as below:
>
>
> When implementing TIPS, a developer should be cognizant of the effects of
> the update schedule...
>
>
> and
>
>
> Therefore, each TIPS service instance may choose to encode the updates
> using JSON merge patch or JSON patch based on the changes in network maps.
>
>
>
> And in
> 8.6.
> <https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#section-8.6>Considerations
> for Updates to Ordinal Mode Costs
> <https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#name-considerations-for-updates-t>
>
> While this document allows TIPS to offer incremental updates for ordinal
> mode cost maps, TIPS implementors should be aware that incremental updates
> for ordinal costs are more complicated than for numerical costs, and ALTO
> clients should be aware that small changes may result in large updates.
>
>
>
> I'm guessing that ALTO clients aren't aware.
>
>
> KAI: Yes, indeed. We will fix similar issues. The proposed text is as
> below:
>
>
> and developers should be aware that small changes may result in large
> updates when adding TIPS support for an ALTO client.
>
>
>
> I'm not sure I've caught all of these occurrences, but perhaps the GenArt
> reviewer will notice others, if they are present!
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>