Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Congestion Signaling (CSIG)

[Neal Cardwell <[e-mail]>]

On Tue, Sep 12, 2023 at 7:59 PM Vidhi Goel <vidhi_goel=
[e-mail]> wrote:

> Not sure why we are coming up with so many new techniques when ECN just
> works fine.
> ECN is a 2 bit field (not 1 bit) and seems to be sufficient to indicate
> extent of congestion by marking it per packet. Adding more complexity to
> any layer whether it is L2 or L3 doesn’t work well in deployments. Our goal
> should be to simplify things and only add new headers if absolutely
> necessary.
>

ECN is great. But it's only Explicit Congestion Notification. It only
notifies you when there's congestion. When the congestion goes away, the
signal goes away, and flows don't know whether the bottleneck link is 0.1%
utilized or 99.9% utilized.

So with only ECN and a queue-free bottleneck, flows must either (a) be
willing to increase cwnd quickly and run the risk of overshooting and
causing massive delay/loss (as with CUBIC and its ceiling of 1.5x per round
trip cwnd growth), or (b) increase very slowly to avoid significant
overshoot (as with Reno and its 1 MSS per round trip cwnd growth).

With a signal like CSIG, which provides bandwidth utilization information,
then a CC can increase its sending rate as a function of the available
bandwidth, to quickly increase the sending rate only in cases where the
bottleneck has low utilization. This allows more quickly utilizing
underutilized links with lower risk of queuing and loss damage from
overshoot.

best regards,
neal




> Vidhi
>
> On Sep 12, 2023, at 3:12 AM, Shihang(Vincent) <shihang9=
> [e-mail]> wrote:
>
> Hi,
> I agree L2 may not be the best choice to carry the congestion signaling
> end-to-end and more bits are needed. We have submitted a draft to carry the
> multi-bits congestion signaling in L3. We call it Advanced ECN. See
> https://datatracker.ietf.org/doc/draft-shi-ccwg-advanced-ecn/.
>
> Thanks,
> Hang
>
> *From:* CCWG <[e-mail]> *On Behalf Of *Huangyihong (Rachel)
> *Sent:* Tuesday, September 12, 2023 5:41 PM
> *To:* Tom Herbert <tom=[e-mail]>; Abhiram Ravi
> <abhiramr=[e-mail]>
> *Cc:* IETF IPPM WG <[e-mail]>; tsvwg <[e-mail]>; [e-mail];
> [e-mail]; Nandita Dukkipati <[e-mail]>; Naoshad Mehta <
> [e-mail]>; Jai Kumar <[e-mail]>
> *Subject:* Re: [CCWG] [iccrg] [tsvwg] New Internet Draft: Congestion
> Signaling (CSIG)
>
> Hi,
>
> I also have the same feeling. Implementing in L2 may be difficult to be
> used in e2e transport. Of course it can work well in limited domain, like
> DC or HPC clusters. However, I also look for some solutions that could be
> able to go through internet. We have submitted a draft to describe the
> transport challenges. See
> https://datatracker.ietf.org/doc/html/draft-huang-tsvwg-transport-challenges
> .
>
> I share the same opinion that the congestion signal is useful and current
> 1-bit ECN solution is not fully sufficient. But I also feel like the more
> straight way is to extend L3, or l4, like update IOAM, to carry the
> information. For L2 solution, it should be developed together with IEEE
> 802.1.
>
> BR，
> Rachel
>
> *发件人:* iccrg <[e-mail]> *代表 *Tom Herbert
> *发送时间:* 2023年9月10日 0:10
> *收件人:* Abhiram Ravi <abhiramr=[e-mail]>
> *抄送:* IETF IPPM WG <[e-mail]>; tsvwg <[e-mail]>; [e-mail];
>  [e-mail]; Nandita Dukkipati <[e-mail]>; Naoshad Mehta <
> [e-mail]>; Jai Kumar <[e-mail]>
> *主题:* Re: [iccrg] [tsvwg] New Internet Draft: Congestion Signaling (CSIG)
>
> Hi, thanks for draft!
>
> The first thing that stands out to me is the carrier of the new packet
> headers. In the forward path it would be in L2 and in reflection it would
> be L4. As the draft describes, this would entail having to support the
> protocol in multiple L2 and multiple L4 protocols-- that's going to be a
> pretty big lift! Also, L2 is not really an end-to-end protocol (would
> legacy switches in the path also forward the header)l?).
>
> The signaling being described in the draft is network layer information,
> and hence IMO should be conveyed in network layer headers. That's is L3
> which conveniently is the average of L2+L4 :-)
>
> IMO, the proper carrier of the signal data is Hop-by-Hop Options. This is
> end-to-end and allows modification of data in-flight. The typical concern
> with Hop-by-Hop Options is high drop rates on the Internet, however in this
> case the protocol is explicitly confined to a limited domain so I don't see
> that as a blocking issue for this use case.
>
> The information being carried seems very similar to that of IOAM (IOAM
> uses Hop-by-Hop Options and supports reflection). I suppose the differences
> are that this protocol is meant to be consumed by the transport Layer and
> the data is a condensed summary of path characteristics. IOAM seems pretty
> extensible, so maybe it could be adapted to carry the signals of this draft?
>
> A related proposal might be FAST draft-herbert-fast. Where the CSIG is
> network to host signaling, FAST is host to network signaling for the
> purposes of requesting network services. These might be complementary and
> options for both may be in the same packet. FAST also uses reflection, so
> we might be able to leverage some common implementation at a destination.
>
> Tom
>
> On Fri, Sep 8, 2023, 7:43 PM Abhiram Ravi <abhiramr=
> [e-mail]> wrote:
>
> Hi IPPM folks,
>
> I am pleased to announce the publication of a new internet draft,
> Congestion Signaling (CSIG):
> https://datatracker.ietf.org/doc/draft-ravi-ippm-csig/
>
> CSIG is a new end-to-end packet header mechanism for in-band signaling
> that is simple, efficient, deployable, and grounded in concrete use cases
> of congestion control, traffic management, and network debuggability. We
> believe that CSIG is an important new protocol that builds on top of
> existing in-band network telemetry protocols.
>
> We encourage you to read the CSIG draft and provide your feedback and
> comments. We have also cc'd the TSVWG, CCWG, and ICCRG mailing lists, as we
> believe that this work may be of interest to their members as well.
>
> Thank you for your time and consideration.
>
> Sincerely,
> Abhiram Ravi
> On behalf of the CSIG authors
>
>
>