Re: [alto] Iotdir telechat review of draft-ietf-alto-new-transport-17

[[e-mail]]

Hi Wesley,

Sorry for the delay. Here are the follow-up updates of your telechat review.

Regarding the relationship between TIPS and ALTO/SSE, we think that they can both transport incremental updates but offer different and complementary capabilities: TIPS is optimizing for throughput and ALTO/SSE is optimizing for latency (as server can push multiple updates without waiting for new requests from the client). As a matter of fact, these two extensions can be combined. Thus, our decision is that TIPS does not obsolete ALTO/SSE.

We propose some new text in Sec 1 to talk about the differences and relations and in Sec 6 to specify how they can be combined with an example. The proposed text in the introduction is as follows:

NEW:
   While ALTO/SSE [RFC8895] and TIPS both can transport incremental
   updates of ALTO information resources to clients, they have different
   design goals.  The TIPS extension enables more scalable and robust
   distribution of incremental updates, but is missing the session
   management and built-in server push capabilities of ALTO/SSE.  From
   the performance perspective, TIPS is optimizing throughput by
   leveraging concurrent and out-of-order transport of data, while ALTO/
   SSE is optimizing latency as new events can be immediately
   transferred to the clients without waiting for another round of
   communication when there are multiple updates.  Thus, we do not see
   TIPS as a replacement but as a complement of ALTO/SSE.  One example
   of combining these two extensions is as shown in Section 6.3.3.

Please let us know if this addresses your comments. Thanks!

Best,
Kai

> -----Original Messages-----
> From: [e-mail]
> Send time:Tuesday, 10/24/2023 21:22:45
> To: [e-mail]
> Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
> Subject: Re: [alto] Iotdir telechat review of draft-ietf-alto-new-transport-17
> 
> Hi Med and Wesley,
> 
> Thanks for the comments! I already fix nits 1 & 3 and we will propose some new texts for Issue 1) and Nits 2) as soon as possible.
> 
> Best,
> Kai
> 
> 
> > -----Original Messages-----
> > From: [e-mail]
> > Send time:Tuesday, 10/24/2023 13:40:02
> > To: "Wesley Eddy" <[e-mail]>, "[e-mail]" <[e-mail]>
> > Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
> > Subject: RE: [alto] Iotdir telechat review of draft-ietf-alto-new-transport-17
> > 
> > Hi Wes, 
> > 
> > On your first point, the WG discussed that point and the conclusion was to not obsolete SSE: 
> > https://datatracker.ietf.org/meeting/117/materials/slides-117-alto-alto-charter-items-issues-01
> > 
> > Re-reading the text in the draft, I do agree that your comment is fair and NEW text is needed to better clarify this. I trust the authors will take care of this.
> > 
> > Thank you for tagging this.
> > 
> > Cheers,
> > Med
> > (Doc Shepherd)
> > 
> > > -----Message d'origine-----
> > > De : alto <[e-mail]> De la part de Wesley Eddy via
> > > Datatracker
> > > Envoyé : lundi 23 octobre 2023 19:13
> > > À : [e-mail]
> > > Cc : [e-mail]; [e-mail]; last-
> > > [e-mail]
> > > Objet : [alto] Iotdir telechat review of draft-ietf-alto-new-
> > > transport-17
> > > 
> > > Reviewer: Wesley Eddy
> > > Review result: Ready with Issues
> > > 
> > > I only found 1 real "issue" in reading this document, and a few
> > > smaller nits, described below.  None of these comments are
> > > specifically related to IoTDIR type of concerns, and it doesn't seem
> > > like the protocol would be intended for use in IoT.
> > > 
> > > Issues:
> > > 
> > > 1) The placement of TIPS relative to other ALTO standards is unclear.
> > > This became evident to me on page 4, reading the bottom paragraph with
> > > "Despite the benefits, however, ...".  Is the gist of this paragraph
> > > supposed to be that the WG does not think that TIPS should totally
> > > replace ALTO/SSE?  It's not clear to me what the recommendation or
> > > applicability statement for these is in practical terms.  The WG
> > > should convey more clearly what it believes implemenentations and
> > > deployments should be using, under what circumstances.  If both
> > > protocols are maintained as standards track, then it should be clearly
> > > stated why that needs to be the case and that this does not obsolete
> > > ALTO/SSE.  It seems to be created as another option, with unclear
> > > guidance provided to implementers about what to do.
> > > 
> > > Nits:
> > > 
> > > 1) page 4
> > > from
> > > "no capability it transmits incremental"
> > > to
> > > "no capability to transmit incremental"
> > > 
> > > 2) I don't know if this is typical for other ALTO documents, but the
> > > usage of the term "transport protocol" in the first paragraph of
> > > section 1 is not consistent with the Internet architecture where
> > > "transport protocols" are TCP,
> > > UDP, SCTP, etc., nor is it "transport" in the sense of MPLS, etc.   I
> > > would
> > > suggest using the alternative term "transfer" to be less jarring.  Of
> > > course, if this is already the standard terminology for ALTO that the
> > > IETF has accepted, then this comment can be ignored.
> > > 
> > > 3) In the section 5.4 example, should "my-networkmap" in some of the
> > > "uses"
> > > values by "my-network-map" that was defined at the top?
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > alto mailing list
> > > [e-mail]
> > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > > ietf.org%2Fmailman%2Flistinfo%2Falto&data=05%7C01%7Cmohamed.boucadair%
> > > 40orange.com%7C93e98812d3d24b3bfc3308dbd3eb5e71%7C90c7a20af34b40bfbc48
> > > b9253b6f5d20%7C0%7C0%7C638336780069384460%7CUnknown%7CTWFpbGZsb3d8eyJW
> > > IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
> > > 7C%7C%7C&sdata=JrptPk%2B4cEymd%2B3eVM21n9Sn8kmxDApvsj%2Bx2%2FisuZ4%3D&
> > > reserved=0
> > ____________________________________________________________________________________________________________
> > 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto