Re: [alto] AD comments on draft-ietf-alto-new-transport-15

[kaigao]

Hi Martin,

I'm holding the revision -17 as there is a GENART LC review. I will submit once 
the proposed change is acked or there is no respond before Saturday night.

Best,

Kai




-Original Messages-
From:"Martin Duke" 
Send time:Thursday, 10/19/2023 21:20:47
To: kai...@scu.edu.cn
Cc: draft-ietf-alto-new-transport@ietf.org, "Martin Thomson" 
, "IETF ALTO" 
Subject: Re: Re: Re: Re: Re: AD comments on draft-ietf-alto-new-transport-15


Sounds good to me. 



On Wed, Oct 18, 2023 at 10:34 PM  wrote:


Hi Martin,

I would like to change the wording a bit to make sure they guidelines are 
interpreted as applicable only when the resources are sufficient:




OLD:


If resources allow, servers SHOULD avoid closing TIPS views that have active 
polling edge requests. Servers also SHOULD avoid closing TIPS views that have 
recently served responses, until clients have had a reasonable interval to 
request the next update.

NEW:

If resources allow, servers SHOULD avoid closing TIPS views that have active 
polling edge requests or have recently served responses until clients have had 
a reasonable interval to request the next update.




I will update the document in my evening and post if you think it's OK.





Best,

Kai




-Original Messages-
From:"Martin Duke" 
Send time:Thursday, 10/19/2023 00:46:46
To:kai...@scu.edu.cn
Cc:draft-ietf-alto-new-transport@ietf.org, "Martin Thomson" 
, "IETF ALTO" 
Subject: Re: Re: Re: Re: AD comments on draft-ietf-alto-new-transport-15


Sounds good. I'm going to move this forward, but here are some nits for the 
next iteration. If you can post an update in the next few days, that would be 
ideal.


(S4.1) I think this change is clearer about the intent here:
OLD
It must be noted that a server may close a TIPS view, e.g., under high system 
load or due to inactivity. It is RECOMMENDED that a client detects the liveness 
and declares interests of the TIPS view by sending a polling edge request. For 
example, as long as the polling request to /ug// does 
not receive error code 404, the TIPS view is still alive.



NEW
A server MAY close a TIPS view at any time, e.g., under high system load or due 
to client inactivity. In the event that a TIPS view is closed, an edge request 
will receive error code 404 in response, and the client will have to request a 
new TIPS view URI.


If resources allow, servers SHOULD avoid closing TIPS views that have active 
polling edge requests. Servers also SHOULD avoid closing TIPS views that have 
recently served responses, until clients have had a reasonable interval to 
request the next update.


(S8.7) 
OLD 
the ALTO server maintains the set of clients that have sent a polling request 
to the TIPS view, and only removes the view from the storage when the set 
becomes empty.



NEW
the ALTO server maintains the set of clients that have sent a polling request 
to the TIPS view, and only removes the view from the storage when the set 
becomes empty and no client immediately issues a new edge request



Let me know if you have issues with those changes.
Martin






On Tue, Oct 17, 2023 at 6:23 PM  wrote:




-Original Messages-
From:"Martin Duke" 
Send time:Tuesday, 10/17/2023 22:45:05
To:kai...@scu.edu.cn
Cc:draft-ietf-alto-new-transport@ietf.org, "Martin Thomson" 
, "IETF ALTO" 
Subject: Re: Re: Re: AD comments on draft-ietf-alto-new-transport-15






On Sat, Oct 14, 2023 at 8:15 PM  wrote:

I do agree that this could create a behavior where the client doesn't actually 
need 102/103 but puts in the request just to keep the TIPS view alive.  From 
your previous reply, it seems like not having an open edge request on a 
resource is an edge case. I think I would prefer that we recommend that a 
client that doesn't need an update right away just be prepared for the TIPS 
view to go away.
 
[KAI] My previous reply is arguing that guideline <2>, i.e., TIPS views with 
recent responses, may lead to unintended client behavior, which may increase 
the server complexity to mitigate.



The point of "tracking recent responses" is that you don't want to respond to 
an open request and then close the TIPS view because there are no open requests 
-- the server needs to give the client a few RTTs to request the new edge. What 
unintended client behavior arises from this?

 [KAI] OK, I get it. I thought the recent response would apply to not only the 
open request but to previous request as well. The unintended behavior is that 
clients compete by sending unnecessary requests to refresh the time of recent 
response, which I mentioned in previous replies. If we restrict guideline <2> 
to open requests, then there is no problem.





Another potential issue is that creating new TIPS views with customized filters 
(unshareable) is likely to be more computationally expensive than computing the 
incremental updates. If there is a resource concern, I would anticipate that 
allocating the resources to a steady set of TIPS views 

Re: [alto] fw Genart last call review of draft-ietf-alto-new-transport-15

[kaigao]

Hi Linda,

Different clients can request different incremental updates and the load 
balancing is applied to all requests. However, here the issue is mainly for a 
single user whose requests may be distributed through different HTTP 
connections (and eventually different TCP connections). The argument is that 
some requests may arrive at a server that does not have the TIPS view if 1) 
only one backend server hosts a specific TIPS view and 2) layer-4 load 
balancing is used.


To eliminate the ambiguity, we propose the following text (to be included in 
the next revision -17):

NEW:

   TIPS allows a client to make concurrent pulls of incremental updates
   for the same TIPS view potentially through different HTTP
   connections.  As a consequence, it introduces additional complexities
   when the ALTO server is being load balanced.  For example, a request
   may be directed to a wrong backend server and get incorrectly
   processed if the following two conditions both hold:





The server does not necessarily keep the state of each (client, TIPS view) 
combination. It only manages states of the TIPS views (e.g., what incremental 
updates are available, perf & usage statistics) and clients are responsible to 
keep track of their states (e.g., which updates of a TIPS view they already 
have).

Please let us know if that solves your problem. Thanks!


Best,

Kai


-Original Messages-
From:mohamed.boucad...@orange.com
Send time:Thursday, 10/19/2023 01:22:25
To: "IETF ALTO (alto@ietf.org)" , 
"draft-ietf-alto-new-transport@ietf.org" 

Cc: "Linda Dunbar  (linda.dun...@futurewei.com)" 
, gen-art 
Subject: fw Genart last call review of draft-ietf-alto-new-transport-15



Hi all,

 

It seems this review didn’t make it to the ALTO list: 
https://mailarchive.ietf.org/arch/msg/gen-art/3q-ds8awHTaNIK4FRv1xTI_eqs8/

 

Cheers,

Med


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.___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Dnsdir telechat review of draft-ietf-alto-oam-yang-14

[Jensen Zhang]

Hi Scott,

Many thanks for catching the typo. The -15 version should fix it.

Thanks,
Jensen


On Fri, Oct 20, 2023 at 7:53 AM Scott Rose via Datatracker 
wrote:

> Reviewer: Scott Rose
> Review result: Ready with Nits
>
> There does not appear to be any change to the text that relates how the
> DNS RRs
> are to be provisioned and queried. So the review from the -12 version still
> applies.  This draft does not impact the DNS protocol and is ready in that
> respect.
>
> I will note that since the text hasn't changed, the misspelled word still
> exists.  In Section 5.3.1.2 "The initial version..." ends with "...server
> discovery as sugested by [RFC7286] and [RFC8686]."  "sugested" should be
> "suggested".
>
> Scott
>
>
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] I-D Action: draft-ietf-alto-oam-yang-15.txt

[internet-drafts]

Internet-Draft draft-ietf-alto-oam-yang-15.txt is now available. It is a work
item of the Application-Layer Traffic Optimization (ALTO) WG of the IETF.

   Title:   YANG Data Models for the Application-Layer Traffic Optimization 
(ALTO) Protocol
   Authors: Jingxuan Jensen Zhang
Dhruv Dhody
Kai Gao
Roland Schott
Qiufang Ma
   Name:draft-ietf-alto-oam-yang-15.txt
   Pages:   79
   Dates:   2023-10-19

Abstract:

   This document defines a YANG data model for Operations,
   Administration, and Maintenance (OAM) & Management of the
   Application-Layer Traffic Optimization (ALTO) Protocol.  The operator
   of an ALTO server can use this data model to (1) set up the ALTO
   server, (2) configure server discovery, (3) create, update and remove
   ALTO information resources, (4) manage the access control of each
   ALTO information resource, and (5) collect statistical data from the
   ALTO server.  The application provider can also use this data model
   to configure ALTO clients to communicate with known ALTO servers.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-alto-oam-yang/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-alto-oam-yang-15.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-alto-oam-yang-15

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Dnsdir telechat review of draft-ietf-alto-oam-yang-14

[Scott Rose via Datatracker]

Reviewer: Scott Rose
Review result: Ready with Nits

There does not appear to be any change to the text that relates how the DNS RRs
are to be provisioned and queried. So the review from the -12 version still
applies.  This draft does not impact the DNS protocol and is ready in that
respect.

I will note that since the text hasn't changed, the misspelled word still
exists.  In Section 5.3.1.2 "The initial version..." ends with "...server
discovery as sugested by [RFC7286] and [RFC8686]."  "sugested" should be
"suggested".

Scott


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Note to draft authors

[Martin Duke]

Please make sure that there has been a reply to all of the Last Call
reviews.
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Intdir telechat review of draft-ietf-alto-new-transport-16

[Bob Halley via Datatracker]

Reviewer: Bob Halley
Review result: Not Ready

I am an assigned INT directorate reviewer for draft-ietf-alto-new-transport.
These comments were written primarily for the benefit of the Internet Area
Directors. Document editors and shepherd(s) should treat these comments just
like they would treat comments from any other IETF contributors and resolve
them along with any other Last Call comments that have been received. For more
details on the INT Directorate, see
https://datatracker.ietf.org/group/intdir/about/
.

Based on my review, if I was on the IESG I would ballot this document as
DISCUSS.

While I don't know much about ALTO, I have worked extensively with
sequence-number-based versioning systems with both snapshots and incremental
updates.

I have the following DISCUSS/ABSTAIN level issues:

I think the basic design is sound; my problem is really with the way the
document is written.  Some sections are repetitive, some are well-specified,
and others seem to be examples with explanatory (but also normative) text.  The
example-type sections felt fuzzy and underspecified.  For example, if I do

  GET /tips/2718281828459/ug/102/105

in a case where there is no "optional" incremental update edge from 102 to 105,
i.e. I have to get 102->103, 103->104, and 104->105 individually, then it is
not clear to me what happens.  Do I get 404?  I think this document would be
very frustrating for prospective implementers.

An architectural worry is that I didn't see any notion of a "generation id" or
"database id" or other unique name for the whole version history.  Generally
speaking there is always a possibility of the replacement/regeneration of the
entire database due to a catastrophic server failure or operator error.  As
part of the recovery, new content is loaded and the prior version history is
invalidated.  Ideally a client connecting would realize this and start from 0
again, as opposed to asking from incremental changes from a history that
doesn't exist any more.  The issue is that the sequence number spaces of the
two histories might overlap, and thus the client might be given a nonsensical
diff that would not apply instead of learning it needs to resync from scratch. 
In some cases, this can lead to subtle and hard-to-detect content divergence.

Dependencies between different versioned objects, as discussed in 8.3, is
understandable but also seems to undercut simple long pulling of individual
URIs.  I'm not objecting to the dependencies themselves, as this is
unavoidable.  I wonder if this might have been addressed in some other way that
was less burdensome to clients, e.g. some sort of "versioned set of versions",
though I grant this is not an easy problem.  It just felt late to hear about it
in section 8.3 when the rest of the text seems to be encouraging me to long
pull without other concerns.

On the nit level, I found the use of "prefetch" as a synonym for "long pull"
confusing, as for me "prefetching" is a speculative caching term.  There is no
speculation or caching going on here, we're just trying to do a "push" style of
pubsub via "long polling" instead of repetitive polling or another form of push
notification.



___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] AD comments on draft-ietf-alto-new-transport-15

[Martin Duke]

Sounds good to me.

On Wed, Oct 18, 2023 at 10:34 PM  wrote:

> Hi Martin,
>
> I would like to change the wording a bit to make sure they guidelines are
> interpreted as applicable only when the resources are sufficient:
>
>
> OLD:
>
> If resources allow, servers SHOULD avoid closing TIPS views that have
> active polling edge requests. Servers also SHOULD avoid closing TIPS views
> that have recently served responses, until clients have had a reasonable
> interval to request the next update.
>
> NEW:
>
> If resources allow, servers SHOULD avoid closing TIPS views that have
> active polling edge requests or have recently served responses
> until clients have had a reasonable interval to request the next update.
>
>
> I will update the document in my evening and post if you think it's OK.
>
>
> Best,
>
> Kai
>
>
> -Original Messages-
> *From:* "Martin Duke" 
> *Send time:* Thursday, 10/19/2023 00:46:46
> *To:* kai...@scu.edu.cn
> *Cc:* draft-ietf-alto-new-transport@ietf.org, "Martin Thomson" <
> m...@lowentropy.net>, "IETF ALTO" 
> *Subject:* Re: Re: Re: Re: AD comments on draft-ietf-alto-new-transport-15
>
> Sounds good. I'm going to move this forward, but here are some nits for
> the next iteration. If you can post an update in the next few days, that
> would be ideal.
>
> (S4.1) I think this change is clearer about the intent here:
> OLD
> It must be noted that a server may close a TIPS view, e.g., under high
> system load or due to inactivity. It is RECOMMENDED that a client detects
> the liveness and declares interests of the TIPS view by sending a polling
> edge request. For example, as long as the polling request to
> /ug// does not receive error code 404, the TIPS view
> is still alive.
>
> NEW
> A server MAY close a TIPS view at any time, e.g., under high system load
> or due to client inactivity. In the event that a TIPS view is closed, an
> edge request will receive error code 404 in response, and the client will
> have to request a new TIPS view URI.
>
> If resources allow, servers SHOULD avoid closing TIPS views that have
> active polling edge requests. Servers also SHOULD avoid closing TIPS views
> that have recently served responses, until clients have had a reasonable
> interval to request the next update.
>
> (S8.7)
> OLD
> the ALTO server maintains the set of clients that have sent a polling
> request to the TIPS view, and only removes the view from the storage when
> the set becomes empty.
>
> NEW
> the ALTO server maintains the set of clients that have sent a polling
> request to the TIPS view, and only removes the view from the storage when
> the set becomes empty and no client immediately issues a new edge request
>
> Let me know if you have issues with those changes.
> Martin
>
>
>
> On Tue, Oct 17, 2023 at 6:23 PM  wrote:
>
>>
>>
>>
>> -Original Messages-
>> *From:* "Martin Duke" 
>> *Send time:* Tuesday, 10/17/2023 22:45:05
>> *To:* kai...@scu.edu.cn
>> *Cc:* draft-ietf-alto-new-transport@ietf.org, "Martin Thomson" <
>> m...@lowentropy.net>, "IETF ALTO" 
>> *Subject:* Re: Re: Re: AD comments on draft-ietf-alto-new-transport-15
>>
>>
>>
>> On Sat, Oct 14, 2023 at 8:15 PM  wrote:
>>
>>> I do agree that this could create a behavior where the client doesn't
>>> actually need 102/103 but puts in the request just to keep the TIPS view
>>> alive.  From your previous reply, it seems like not having an open edge
>>> request on a resource is an edge case. I think I would prefer that we
>>> recommend that a client that doesn't need an update right away just be
>>> prepared for the TIPS view to go away.
>>>
>>>
>>> [KAI] My previous reply is arguing that guideline <2>, i.e., TIPS views
>>> with recent responses, may lead to unintended client behavior, which may
>>> increase the server complexity to mitigate.
>>>
>>
>> The point of "tracking recent responses" is that you don't want to
>> respond to an open request and then close the TIPS view because there are
>> no open requests -- the server needs to give the client a few RTTs to
>> request the new edge. What unintended client behavior arises from this?
>>
>>  [KAI] OK, I get it. I thought the recent response would apply to not
>> only the open request but to previous request as well. The unintended
>> behavior is that clients compete by sending unnecessary requests to refresh
>> the time of recent response, which I mentioned in previous replies. If we
>> restrict guideline <2> to open requests, then there is no problem.
>>
>>
 Another potential issue is that creating new TIPS views with customized
 filters (unshareable) is likely to be more computationally expensive than
 computing the incremental updates. If there is a resource concern, I would
 anticipate that allocating the resources to a steady set of TIPS views is
 more efficient. While this may be addressed by using a smarter scheduler,
 the client developers cannot know that and may also program defensively,
 e.g., by making frequent 

[alto] I-D Action: draft-ietf-alto-oam-yang-14.txt

[internet-drafts]

Internet-Draft draft-ietf-alto-oam-yang-14.txt is now available. It is a work
item of the Application-Layer Traffic Optimization (ALTO) WG of the IETF.

   Title:   YANG Data Models for the Application-Layer Traffic Optimization 
(ALTO) Protocol
   Authors: Jingxuan Jensen Zhang
Dhruv Dhody
Kai Gao
Roland Schott
Qiufang Ma
   Name:draft-ietf-alto-oam-yang-14.txt
   Pages:   79
   Dates:   2023-10-18

Abstract:

   This document defines a YANG data model for Operations,
   Administration, and Maintenance (OAM) & Management of the
   Application-Layer Traffic Optimization (ALTO) Protocol.  The operator
   of an ALTO server can use this data model to (1) set up the ALTO
   server, (2) configure server discovery, (3) create, update and remove
   ALTO information resources, (4) manage the access control of each
   ALTO information resource, and (5) collect statistical data from the
   ALTO server.  The application provider can also use this data model
   to configure ALTO clients to communicate with known ALTO servers.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-alto-oam-yang/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-alto-oam-yang-14.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-alto-oam-yang-14

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto