[tsvwg] Re: New Version Notification for draft-kwbdgrr-tsvwg-net-collab-rqmts-03.txt

[Kaippallimalil John <[e-mail]>]

Hi Michael,
Thanks for the detailed review and happy to hear that it is going in the right direction.

Will look at reducing the length - repetitions (like text around Octopus research in two sections, etc) and other editorial corrections.

Regarding the host-to-network aspects: 
This draft has both server-to-network (S2N, section 4.1, 6.2) and client-to-network signaling (C2N, section 4.2, 6.1).
The rationale for conveying per-packet requirements ((priority, delay) in the S2N direction is described in section 3, and the C2N signals are to indicate what metadata transport/priorities the network should honor. Figure 2 illustrates the interaction between the S2N and C2N signaling.

The API requirement and relation to TAPs is something that is useful to point out. Will add in the next update.

Regarding the Appendix sections, the aim was to keep less important aspects there temporarily while the working group considers.
We'll note your preference to have it deleted.

Best Regards,
John


> -----Original Message-----
> From: Michael Welzl <[e-mail]>
> Sent: Monday, October 7, 2024 8:08 AM
> To: [e-mail]
> Subject: [tsvwg] Re: New Version Notification for draft-kwbdgrr-tsvwg-net-
> collab-rqmts-03.txt
> 
> Hi !
> 
> I have read this updated document; as before, I find it useful and think that
> this is going into a good direction - but also, as before, I think it’s unnecessarily
> long.
> 
> Here are some specific comments:
> 
> Title:  It's good that this draft is clearly about the host-to-network direction
> only, not the other direction. However, the title doesn't clarify this: "network
> collaboration signaling" could go both ways. I would strongly encourage
> changing this to something like "host-to-network signaling".
> 
> Regarding the length, it’s just quite wordy, and in some places very repetitive.
> Here comes some example text highlighting this unnecessary repetition:
> 
> ***********************************************************
> 
> Section 3 above figure 1:
> 
>    End-to-end congestion control algorithms are far from being optimal
>    when the link quality is highly variable in sub-RTT timeframes and
>    the application demands both low latency and high bandwidth (e.g.,
>    Section 2.1 of [RFC6077]).  In these conditions, applications settle
>    for a lower throughput when latency is prioritized, or for higher
>    throughput at the expense of much higher delays.
> 
> (..)
> 
>    For example, [_5G-Octopus] has
>    shown for volumetric video packets and a rate controller that errs on
>    the side of overestimation, that the network shaper can drop low
>    priority frames of a group of pictures (corresponding to transient
>    wireless link bandwidth drops) and still achieve significantly better
>    performance than state-of-the-art based on feedback.
> 
> 
> Section 3 below figure 2:
> 
>    Congestion control algorithms (CCAs) are generally
>    conservative and settle to a steady rate that avoids excessive packet
>    loss.  In networks where link conditions (between Client and Router)
>    vary significantly at timescales well below the RTT, this results in
>    unused (wasted) bandwidth at short timescales.
> 
>    There is some research (e.g., [_5G-Octopus]) to indicate that media
>    applications can obtain better Quality of Experience (QoE) when
>    sending at a higher rate (less conservative than current CCA) and the
>    media application is willing to tolerate some packet loss or delay of
>    low priority packets.
> 
> Beginning of Section 5:
> 
>    In such networks where variations in link quality is
>    well below RTT, congestion control algorithms settle to a steady rate
>    that avoids excessive packet loss.
> 
> (btw, there's a missing article before "RTT")
> 
> and:
> 
>    There is some research [_5G-Octopus] to indicate that media
>    applications can obtain better measured application quality when
>    sending at a higher rate (less conservative than current CCA) and
>    allowing the network to delay or drop low priority packets.
> 
> ***********************************************************
> 
> Personally (probably biased  ;-)   ), I think that the section on the API (4.3)
> should point at TAPS, where the "capacity profile" and per-message priorities
> could supply the information needed here.
> 
> It's strange that Figure 3 is not referenced in the text; also, why is this an "API
> Framework"? Such signaling need not be exposed in an API.
> 
> Appendix A: it appears you significantly shortened the main part of the draft
> by moving everything you consider less important to an appendix. What's
> weird is that, as a reader, I don't know what to make of the appendix: why
> does it exist? Is that text adding useful information that helps me better
> understand the rest, but is just too lengthy?  It doesn't seem like it - it just
> seems like less important extra information. But then, why is it even there?
> 
> Perhaps you should just delete this appendix?
> 
> 
> Some nits:
> 
> Section 4.3: Missing full stop after "The API framework uses the medium
> negotiated under Section 5.3 to send/receive the signals"
> 
> Section 5.1 use case 1: "Majority of"...  => "The majority of ..."
> I'm not sure the nomenclature of "partial frames" and "full frames" is common
> in video. If you think of P-Frames, the "P" stands for prediction, I believe, not
> "partial". Unless this is common terminology, I would rather just say that there
> are messages (or perhaps "application data chunks" ?  Blocks, frames... all
> make one think of a specific video encoding) of varying importance.
> 
> 
> I hope this helps!
> 
> Cheers,
> Michael
> 
> 
> 
> > On Sep 30, 2024, at 3:37 PM, Kaippallimalil John
> <[e-mail]> wrote:
> >
> > Hi all,
> >
> > We just posted a new version of Requirements for Network Collaboration
> Signaling
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-kwbdgrr-tsvwg-net-collab-
> rqmts%2F&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7C41b
> 0895c73d14053b76c08dce6d13359%7C0fee8ff2a3b240189c753a1d5591fe
> dc%7C1%7C0%7C638639033429426784%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> D%7C0%7C%7C%7C&sdata=scIQD%2FOF8aBtIII4VpwiFASkCDbO11X15QaOf
> 8%2B46AQ%3D&reserved=0 that attempts to address all comments in tsvwg
> (IETF 120 session).
> >
> > The comments were to reduce requirements, bring the two requirements
> docs (h2n, s2n) together, focus on what IETF should do, what is covered by
> existing mechanisms in IETF and examples/research of what has been done.
> (see detailed notes at
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fminutes-120-tsvwg-
> 202407261630%2F&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.co
> m%7C41b0895c73d14053b76c08dce6d13359%7C0fee8ff2a3b240189c753
> a1d5591fedc%7C1%7C0%7C638639033429447855%7CUnknown%7CTWFp
> bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV
> CI6Mn0%3D%7C0%7C%7C%7C&sdata=7AsT8FqBpJXhJTnpSeTdJUXw7qO6uF
> PvYrGGdTCf41w%3D&reserved=0 ).
> >
> > Some of the main revisions:
> > - Focus on per-packet requirements and is complementary to reactive
> congestion/rate derivation with L4S/ECN/ACK (RTT vs sub-RTT timeframes,
> see section 3 - Rationale for Per-packet metadata).
> > - Defines clearly that these per-packet requirements are for any
> wireless/highly variable rate networks and not specific to 3GPP (see section
> 6.2)
> > - Reference (see 5G-Octopus on in-network content adaptation to control
> congestion...) that points use of metadata to enhance performance in highly
> variable rate networks.
> > - Overall, the requirements are reduced by 70% (total of 5 requirements for
> S2N and C2N and a well-defined model of how they interact - see section 3,
> Figure 2)
> >
> > Please have a look at the new version, and we would appreciate any
> feedback.
> >
> > Best Regards,
> > John
> >
> >
> >
> > -----Original Message-----
> > From: [e-mail] <[e-mail]>
> > Sent: Monday, September 30, 2024 12:36 AM
> > To: Dan Wing <[e-mail]>; Kaippallimalil John
> <[e-mail]>; Mohamed Boucadair
> <[e-mail]>; Spencer Dawkins
> <[e-mail]>; Sri Gundavelli <[e-mail]>;
> Sridharan Rajagopalan <[e-mail]>; Sridharan Rajagopalan
> <[e-mail]>
> > Subject: New Version Notification for draft-kwbdgrr-tsvwg-net-collab-
> rqmts-03.txt
> >
> > A new version of Internet-Draft draft-kwbdgrr-tsvwg-net-collab-rqmts-
> 03.txt
> > has been successfully submitted by Mohamed Boucadair and posted to the
> IETF repository.
> >
> > Name:     draft-kwbdgrr-tsvwg-net-collab-rqmts
> > Revision: 03
> > Title:    Requirements for Network Collaboration Signaling
> > Date:     2024-09-30
> > Group:    Individual Submission
> > Pages:    27
> > URL:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> w.ietf.org%2Farchive%2Fid%2Fdraft-kwbdgrr-tsvwg-net-collab-rqmts-
> 03.txt&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7C41b089
> 5c73d14053b76c08dce6d13359%7C0fee8ff2a3b240189c753a1d5591fedc
> %7C1%7C0%7C638639033429459610%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C0%7C%7C%7C&sdata=8UW%2FrrdkT65J8TjnXrpqWW4dIwJT5PgKbund
> oq1fG0k%3D&reserved=0
> > Status:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-kwbdgrr-tsvwg-net-collab-
> rqmts%2F&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7C41b
> 0895c73d14053b76c08dce6d13359%7C0fee8ff2a3b240189c753a1d5591fe
> dc%7C1%7C0%7C638639033429470624%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> D%7C0%7C%7C%7C&sdata=Te3jdBER2Xkmc4sMPw63qpnXRUJcatlTFtveeVcx
> bPE%3D&reserved=0
> > HTML:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> w.ietf.org%2Farchive%2Fid%2Fdraft-kwbdgrr-tsvwg-net-collab-rqmts-
> 03.html&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7C41b08
> 95c73d14053b76c08dce6d13359%7C0fee8ff2a3b240189c753a1d5591fedc
> %7C1%7C0%7C638639033429481568%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C0%7C%7C%7C&sdata=emeA0xoSueG8hizDDz0TVdWb2EOcHMURAHdsu
> H1sQeA%3D&reserved=0
> > HTMLized:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-kwbdgrr-tsvwg-net-collab-
> rqmts&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7C41b089
> 5c73d14053b76c08dce6d13359%7C0fee8ff2a3b240189c753a1d5591fedc
> %7C1%7C0%7C638639033429493196%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C0%7C%7C%7C&sdata=yIc5AaRUNn8cPnq3IM4u1sO%2FnDvGn%2FDOk
> ygeF0Vl07k%3D&reserved=0
> > Diff:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth
> or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-kwbdgrr-tsvwg-net-collab-rqmts-
> 03&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7C41b0895c7
> 3d14053b76c08dce6d13359%7C0fee8ff2a3b240189c753a1d5591fedc%7C
> 1%7C0%7C638639033429503905%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> 0%7C%7C%7C&sdata=Qnf1vthgi5G309pcL0OS6SBPRu%2FaHEhDIuomhWim
> PFI%3D&reserved=0
> >
> > Abstract:
> >
> >   Collaborative signaling from client-to-network and server-to-network
> >   can improve the user experience by informing the network about the
> >   nature and relative importance of packets (frames, streams, etc.)
> >   without having to disclose the content of the packets.  Moreover, the
> >   collaborative signaling may be enabled so that clients and servers
> >   are aware of the network's treatment of incoming packets.  Also,
> >   client-to-network collaboration can be put in place without revealing
> >   the identity of the remote servers.  This collaboration allows for
> >   differentiated services at the network (e.g., packet discard
> >   preference), the sender (e.g., adaptive transmission), or through
> >   cooperation of server/client and the network.
> >
> >   This document lists some use cases that illustrate the need for a
> >   mechanism to share metadata and outlines requirements for both
> >   client-to-network and server-to-network.  The document focuses on
> >   signaling information about a UDP transport flow (UDP 4-tuple).
> >
> >
> >
> > The IETF Secretariat
> >
> >