[Sadcdn] Re: Fwd: Re: WG Review: Standard Communication with Network Elements (scone)

[Zaheduzzaman Sarker <[e-mail]>]

Hi Brian,

Thanks for your review and feedback.

I think your comments are something that would be useful for the working
group discussions when they will design the protocol. It would be great if
you can participate in the working group to raise those points.

Qin has already pointed out the discussions regarding the UDP 4-tuple so
that you know about the reasoning. I hope that helps, if you still feel
strongly about changing something in the charter text, please provide some
suggestions, otherwise we will keep the charter text unchanged.

//Zahed


On Wed, Oct 9, 2024 at 2:36 PM Qin Wu <bill.wu=[e-mail]>
wrote:

> Hi, Brian:
> See relevant discussion on the github issue tracker
> https://github.com/mjoras/SCONE-PROTOCL/issues/118
> https://github.com/mjoras/SCONE-PROTOCL/issues/116
> Since it is limited to QUIC protocol in the current charter, therefore 5
> tuple is reduced down into 4 tuple.
> Also DSCP seems not to work with QUIC connection, see quoted text in
> section 12 of RFC9308
> "
>    QUIC, as defined in [QUIC], has a single congestion controller and
>    recovery handler.  This design assumes that all packets of a QUIC
>    connection, or at least with the same 5-tuple {dest addr, source
>    addr, protocol, dest port, source port}, that have the same Diffserv
>    Code Point (DSCP) [RFC2475] will receive similar network treatment
>    since feedback about loss or delay of each packet is used as input to
>    the congestion controller.  Therefore, packets belonging to the same
>    connection should use a single DSCP.
> "
> Also it looks to me special treatment in the source node is needed if we
> support flow label to work together with QUIC connect,
> See quoted text in section 3 of RFC6437
> "
>    To enable Flow-Label-based classification, source nodes SHOULD assign
>    each unrelated transport connection and application data stream to a
>    new flow.
> "
> -Qin (Speak as individual)
> -----邮件原件-----
> 发件人: IESG Secretary [mailto:[e-mail]]
> 发送时间: 2024年10月9日 6:50
> 收件人: [e-mail]
> 主题: [Sadcdn] Fwd: Re: WG Review: Standard Communication with Network
> Elements (scone)
>
> To: [e-mail]
> Cc: [e-mail]
> From: Brian E Carpenter <[e-mail]>
> Subject: [Scone] Re: WG Review: Standard Communication with Network
> Elements (scone)
>
> Hi,
>
> I noticed the phrase "what bitrate is usable for a given network UDP
> 4-tuple."
>
> There seem to be two issues that this doesn't allow for:
>
> 1. In IPv6 the flow label should also be considered. (In many cases the
> flow label will not be set for a UDP flow, but nevertheless it should be
> handled in some way when it is non-zero.)
>
> 2. The DSCP should definitely be considered too. A real-time flow is very
> likely to carry a non-default DSCP and that is closely linked to rate
> limiting, especially across ISP boundaries.
>
> I don't know the implications of the flow label and the DSCP for the scone
> work, but it seems to me that the charter should specifically require them
> to be taken into account. The possible interactions with diffserv seem
> quite complex.
>
> Regards
>     Brian Carpenter
>
> On 08-Oct-24 05:27, The IESG wrote:
> > A new IETF WG has been proposed in the Web and Internet Transport. The
> > IESG has not made any determination yet. The following draft charter
> > was submitted, and is provided for informational purposes only. Please
> > send your comments to the IESG mailing list ([e-mail]) by
> 2024-10-17.
> >
> > Standard Communication with Network Elements (scone)
> > ----------------------------------------------------------------------
> > -
> > Current status: Proposed WG
> >
> > Chairs:
> >    Brian Trammell <[e-mail]>
> >    Qin Wu <[e-mail]>
> >
> > Assigned Area Director:
> >    Zaheduzzaman Sarker <[e-mail]>
> >
> > Web and Internet Transport Directors:
> >    Francesca Palombini <[e-mail]>
> >    Zaheduzzaman Sarker <[e-mail]>
> >
> > Mailing list:
> >    Address: [e-mail]
> >    To subscribe:
> https://mailman3.ietf.org/mailman3/lists/scone.ietf.org/
> >    Archive: https://mailarchive.ietf.org/arch/browse/scone
> >
> > Group page: https://datatracker.ietf.org/group/scone/
> >
> > Charter: https://datatracker.ietf.org/doc/charter-ietf-scone/
> >
> > ## Background
> >
> > Many applications are capable of adjusting their bit rate based on
> > network conditions and attempt to understand what bitrate is usable
> > for a given network UDP 4-tuple. Some networks use rate-limiters to
> > influence these applications. However, when networks enforce
> > rate-limiters, applications like video streaming or conferencing
> > struggle to adapt, leading to a suboptimal user experience.
> >
> > ## Goals
> >
> > This WG aims to establish a mechanism for network elements capable of
> > rate-limiting a UDP 4-tuple to communicate an upper bound on
> > achievable bitrate, termed "throughput advice", to the sender of
> > packets matching the UDP 4-tuple.
> >
> > This mechanism will allow an application to receive notifications
> > containing throughput advice for both upstream and downstream traffic
> > from any network elements capable of dropping or delaying packets on
> > the path of a UDP 4-tuple.
> >
> > The throughput advice serves as a guideline to enhance user experience
> > and represents the maximum bitrate manageable by a single network
> > element. It is not a strict indicator of network congestion. This
> > mechanism focuses on throughput advice intended for adaptive bitrate
> > applications and is not a replacement for congestion control
> > algorithms and mechanisms like BBR, ECN, and L4S.
> >
> > This mechanism will allow network elements to update the throughput
> > advice as needed.
> >
> > To achieve the goals listed above, the working group will determine
> > whether it is necessary for an endpoint to explicitly signal its
> > capability of receiving throughput advice, and whether it is necessary
> > for an endpoint to confirm its receipt of throughput advice.
> >
> > The working group will initially focus on developing a solution for
> > QUIC.
> >
> > ## Non-Goals
> >
> > The solution produced by the working group,
> >
> > - must not require looking inside an encryption envelope.
> > - need not be a congestion signal appropriate to be used as input to a
> > congestion control algorithm. - need not provide information other
> > than the throughput advice.
> >
> > ## Program of Work
> >
> > The WG is expected to:
> >
> > 1. Develop standard protocol to communicate an upper bound on
> > achievable bitrate — termed "throughput advice"— from network elements
> > to the endpoint.
> >
> > 2. Develop an Informational Applicability and Manageability
> > specification.
> >
> > The WG will work collaboratively with the WEBTRANS, MOQ, AVTCORE,
> > MOPS, QUIC, TSVWG, and CCWG WGs as appropriate.
> >
> > No work on APIs related to the use the "throughput advice" will be
> > carried out in the working group.
> >
> > Milestones:
> >
> >    Nov 2025 - Submit a standard track protocol to communicate "throughput
> >    advice"— from network elements  to the endpoint to the IESG for
> > publication
> >
> >    Nov 2025 - Submit an informational documentation of Applicability and
> >    Manageability for SCONE protocol to the IESG for publicatio
> >
> >
> >
> > _______________________________________________
> > IETF-Announce mailing list -- [e-mail] To unsubscribe
> > send an email to [e-mail]
>
> --
> Sadcdn mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>