Re: [iccrg] Prague improvements (AND RE: [tsvwg] [CCWG] New Internet Draft: Congestion Signaling (CSIG))

[Ingemar Johansson S <[e-mail]>]

Hi
Thanks for the explanation. Perhaps it is me who needs a pair of new glasses, I was trying to find the updated PragueJ in https://github.com/L4STeam/linux/releases/tag/testing-build  but I don't seem to find it.
It would be interesting to try this out in our 5G system simulator to start with.

//Ingemar


From: Bob Briscoe <[e-mail]>
Sent: Tuesday, 19 September 2023 12:51
To: Ingemar Johansson S <ingemar.s.johansson=[e-mail]>; Toerless Eckert <[e-mail]>
Cc: K. K. Ramakrishnan <[e-mail]>; Christian Huitema <[e-mail]>; iccrg IRTF list <[e-mail]>; Ingemar Johansson S <[e-mail]>
Subject: Re: [iccrg] Prague improvements (AND RE: [tsvwg] [CCWG] New Internet Draft: Congestion Signaling (CSIG))

Ingemar,

I've changed 'was' to 'AND' in the subject line, 'cos by the end, I get back to the original thread topic... see [BB]
On 19/09/2023 07:54, Ingemar Johansson S wrote:

Hi Bob + others



Interesting to hear about PragueJ. The paper was somehow below radar coverage.

[BB] That's 'cos it's only a draft tech report - not published yet (and we might not end up using the algo depending on further testing), but I thought the list would be interested in early sight.





We see a bit of an issue with the normal additive increase when we experiment with mmWave access (only simulations) where blockage to a smaller or greater extent can cause the link throughput to drop dramatically. Normal additive increase is quite slow to converge to e.g 2Gbps throughput, even though the RTT is low.

[BB] See https://datatracker.ietf.org/meeting/99/materials/slides-99-iccrg-iccrg-presentation-4-part-2-00 for our presentation to ICCRG in 2017 about this problem and plans for scalable CCAs to solve it.



To overcome the problem I implemented in Prague a multiplicative increase of CWND where the CWND can increase by up to for instance 5% of the CWND per RTT. The degree of multiplicative increase is scaled based on the number of rounds since the last congestion event. This makes the rate converge considerably faster but there is a certain amount of overshoot.

The delay detection that you suggest can solve this issue.

[BB] To be clear, the delay detection is intended to solve a different problem. The "delay preserving scalable additive increase" calculates an additive increase each round that should not overshoot more than the chosen delay limit.

Over multiple rounds, it is in effect a multiplicative increase, because the base cwnd at the start of each round has obviously grown because of the last round. But it's more correct to call it additive, 'cos the parameters are measured continuously so it's not a constantly multiplicative increase.



One possible challenge I can see is that wireless access can have delay jitter not only due to retransmissions on the MAC layer but also on the RLC later, although the latter is typically less common. How would the delay option handle such outliers.

[BB] Two complementary mechanisms:

  1.  Prague (and PragueJ, both inheriting from DCTCP) run the congestion signals through an EWMA with characteristic smoothing time of 16 RTT. So, when there are occasional outlying low-rate periods, a long-running flow deliberately bounces off them from below, at an average rate under the average capacity.
  2.  The two modes I talked about earlier in this thread: overload mode to react to sudden but persistent high delay, and acceleration mode to pick up unused capacity.

Nonetheless, there is a limit to how well e2e capacity seeking can track variable capacity without undue delay overshoot. Signalling from the network to help was where this thread started.

But my opinion is that network-based signalling support for acceleration is never going to happen, 'cos it has an inherent incremental deployment problem, in two parts:

  1.  Any source that accelerates because one link says it's OK is likely to sometime/often overshoot a bottleneck at another link where the signalling is yet to be deployed.
  2.  If there's some mechanism that detects lack of support at any hop on the path (like Quick-Start had), it will certainly prevent such overshoot, but deployment will also never get to the point where it is usable - because few companies will implement or deploy something that is never going to be useful until it has been universally deployed.



That said.. It would be very good to come up with improved scalable congestion controls that exploit the potential with L4S better.

[BB] Working on it.


Bob








/Ingemar







-----Original Message-----

From: Bob Briscoe <[e-mail]><mailto:[e-mail]>

Sent: Monday, 18 September 2023 23:38

To: Toerless Eckert <[e-mail]><mailto:[e-mail]>

Cc: K. K. Ramakrishnan <[e-mail]><mailto:[e-mail]>; Christian Huitema

<[e-mail]><mailto:[e-mail]>; iccrg IRTF list <[e-mail]><mailto:[e-mail]>

Subject: Re: [iccrg] [tsvwg] [CCWG] New Internet Draft: Congestion Signaling

(CSIG)



Toerless,





On 18/09/2023 19:43, Toerless Eckert wrote:

Nice explanation, Bob, thanks.



I guess there is also a discovery of a non-ECN capable congestion

point along the path and fall-back to a less aggressive (non scalable)

signaling ?



[BB] Currently, Prague is only more responsive (less aggressive) to loss ,

but just for one response - there is no 'mode change' longer term.



Nonetheless, Joakim's experimental modifications to Prague (called PragueJ

from here on) are more responsive to delay too. But, like the acceleration

mode, the response to delay is a one-off overload response, not using delay

as a continual congestion avoidance signal, as Vegas or BBR do. If PragueJ

sees both ECN and delay, it does a once-off 'overload' response aiming to

remove all the delay (and no more than

all) in one RTT.



What is todays best timing of a) discovering that, and b)

undiscovering that

(aka: returning to ECN control once the non-ECN hop is not a

congestion point anymore).



For the overload response, the discovery threshold is not primarily time,

just an increase in delay, altho it does use an EWMA of delay with a

characteristic time of less than a round trip.



The discovery / undiscovery time before entering or leaving acceleration

mode are particularly interesting.



Discovery: PragueJ keeps EWMAs of the round trips between ECN marks and of

the absolute deviation. Then it starts acceleration mode after multiples of

these EWMAs. So the discovery time is not hard-coded, but depends on a

departure from the recent norm of the environment. {Note 1}



Undiscovery: The EWMAs continue to be maintained during the acceleration,

then the variables being averaged (but not the averages

themselves) are reset once an ECN signal is received. This ensures that the

algorithm can only enter acceleration mode again once there has been a long

enough period of stability, taking account of how much it moved from its

previous period of stability (see §3 for details).



Finally, the acceleration itself is nice. During acceleration mode, PragueJ

does additive increase by 'a' segments, where 'a' is calculated so that the

overshoot after one RTT of feedback delay cannot cause greater than a

certain amount of queue delay, called Q in the paper (e.g. 1ms).



Each flow scales its additive increase assuming the bottleneck link's

capacity is filled solely by its own window. So, with multiple flows, the

delay due to all the overshoots added together still cannot exceed Q.





Note 1: (Joakim and I developed a principle where we try to measure all

first-order parameters and only use 'magic numbers'  as second-order

parameters to control the dynamics of the measurements that collect the

first-order parameters.)



Cheers





Bob





Cheers

     Toerles



On Mon, Sep 18, 2023 at 07:04:28PM +0100, Bob Briscoe wrote:

KK, Christian,



I want to focus for a moment on the problem of how a flow in progress

knows that available capacity has increased (e.g. because other

flow(s) have departed or bottleneck link capacity has increased).

Current congestion control algorithms (CCAs) take so long to detect

an absence of signals (loss, delay or ECN), that they use the same

probing algorithm that they use in their congestion avoidance phase to

fill any available capacity.



With Reno, Cubic, etc. the time between congestion episodes in steady

state for a single flow is now hundreds of RTT. So, it takes even

more than that before you can be sure there is a real absence of

congestion signals.



Scalable CCAs do a lot better. The target average time between

signals in stable conditions is half an RTT. You can sustain such a

high signalling rate with ECN, but you couldn't do it with loss,

which is why L4S is tightly associated with ECN. So, after just a few

RTT of no signals you can start probing for more capacity more

aggressively than you would want to in congestion avoidance phase.



This is the critical point - the CCAs of all flows that notice the

absence of signals briefly enter a separate acceleration mode where

convergence is a non-goal. Then, when they find a closed loop signal

again, they return to their congestion avoidance mode to converge

with each other from wherever they got to when they 'broke loose'.



Before Joakim Misund decided to move on from his doctoral research

into getting up to speed fast, he did some nice experiments on this

acceleration mode.

For instance, look at Fig 5 in this draft tech report he wrote:

https://bobbriscoe.net/projects/latency/04-delay_bound_faster_additiv<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-08a09051c2faf846&q=1&e=d9705e4d-fa16-4e98-b8dd-5b3533890602&u=https%3A%2F%2Fbobbriscoe.net%2Fprojects%2Flatency%2F04-delay_bound_faster_additiv>

e_increase_when_unterutilize_tr.pdf



In Fig 5 capacity alternates between 20 Mb/s and 200 Mb/s in a square

wave.

It compares his modified TCP Prague (the pink plot) with BBRv2 &

unmodified Prague.  The legend calls the pink plot "Prague w/both"

because it has an acceleration mode and an overload mode to rapidly

decrease when there is both ECN and heavy delay.





Bob





On 16/09/2023 12:13, K. K. Ramakrishnan wrote:

I agree. This was the original idea  for a "faster" ramp up

initially, Christian. It is (if available on the end-end path) a

relatively benign solution that doesn't stomp out existing flows.

If ECN is not available on the path, it is easy enough to not ramp up.



On Fri, Sep 15, 2023 at 9:19 PM Christian Huitema

<[e-mail]><mailto:[e-mail]>

wrote:



     RFC 9049 is an interesting read. Reading it, I was nodding my

head...

     until it went to the ECN section. The big change we are seeing is

     that

     deploying ECN now is mostly safe -- QUIC, for example, can test for

     end-to-end availability of ECN, and measurements show that it is

     available on many paths. It may not be actively implemented by all

     elements in the path, but at least nothing crashes, and we can see

     deployments. It only took two decades to get there.



     Which means that maybe we should start fully exploiting ECN for

     what it

     is worth. Probably not a complete solution to the "quick start"

     problem,

     but at least a partial solution, one that would complement packet

     loss

     detection and delay increase measurements. That seems more

promising

     than trying to deploy another solution across all Internet routers.



     And maybe we can make creative use of ECN, even in cases of long

     delay

     links. Combine it with chirping, maybe as in "send a chirp at a

quick

     rate, and check whether that chirp elicited ECN feedback?"



     -- Christian Huitema



     On 9/15/2023 1:58 AM, Gorry Fairhurst wrote:

     > I wonder if RFC 9049 - Path Aware Networking: Obstacles to

     Deployment (A

     > Bestiary of Roads Not Taken), section 6.3, might have some

thoughts

     > relevant to why some approaches in DC research diverge from the

     > end-to-end approaches described in published RFCs.

     >

     > Best wishes,

     > Gorry

     >

     >

     > On 15/09/2023 08:37, Hesham ElBakoury wrote:

     >> Speaking of Internet congestion control, have you looked at this

     >> paper: Future Internet Congestion Control: The Diminishing

     Feedback

     >> Problem [https://arxiv.org/pdf/2206.06642]? The abstract of

     this paper

     >> says: /<we argue that congestion control mechanisms should move

     away

     >> from their strict “end-to-end”/

     >> /adherence. This change would benefit from avoiding a “one size

     fits

     >> all circumstances” approach, and moving towards a more/

     >> /selective set of mechanisms that will result in a better

     performing

     >> Internet./>

     >>

     >> Hesham

     >>

     >> On Thu, Sep 14, 2023, 3:23 AM Sebastian Moeller

     <[e-mail]><mailto:[e-mail]> wrote:

     >>

     >>     Hi Ruediger,

     >>

     >>

     >>     > On Sep 14, 2023, at 09:25, <[e-mail]><mailto:[e-mail]>

     >>     <[e-mail]><mailto:[e-mail]> wrote:

     >>     >

     >>     > Sebastian, Ingemar,

     >>     >

     >>     > the draft says "limited domain". The method suggested

     resembles

     >>     IPPM's IOAM (but the packet size remains fixed, certainly an

     >>     advantage). Information like a port ID only makes sense, if

the

     >>     evaluation unit is aware of the domain-topology.

     >>

     >>             [SM] Not sure I understand this, if on an internet-

wide

     >>     path all nodes would simply include the minimum of their

egress

     >>     bitrate (that is only include this if it is lower than the

     >>     existing value), then an end-2end protocol like TCP could

     even as

     >>     part of the initial 3 way handshake figure out a hard limit

for

     >>     maximum rasinsable cwin (by simply calculating the BDP).

     SUre that

     >>     would not stop slow-start fuully from overshooting, but it

     should

     >>     limit the maximum overshoot considerably....

     >>

     >>

     >>     > That will be restricted to a single domain, I think.

     >>

     >>             [SM] As long as the forward and collection path

     requires

     >>     L2 elements, sure this will not work over the internet.

     >>

     >>

     >>     > I'm also not sure, what is to be optimized on an

operational

     >>     carrier backbone.

     >>

     >>             [SM] I trust you on this, as that is out of my

league.

     >>

     >>

     >>     > Under expectable conditions, these are operated without

     >>     congestion. Bottlenecks are likely at the access and, in a

     rather

     >>     limited number of cases, at peering. There you'd need to

     know the

     >>     RTT so that the available bandwidth calculation makes sense.

     >>

     >>             [SM] But the protocol that is supposed to consume

the

     >>     congestion information will know the RTT, so can take this

into

     >>     account, the network really only needs to give information

     about

     >>     its current state. That said, I can see network nodes that

     might

     >>     want to know a flow's RTT, but I do not think there is a way

of

     >>     supplying that this is not both easy and efficient and not

     easily

     >>     gamed. Passing on congestion informatin however is far less

     >>     abusable (after all the node could just as well have

     dropped the

     >>     packet instead of bothering to fudge the congestion info).

     >>

     >>

     >>     > Or you need to calculate several values for several RTTs

and

     >>     provide this information (RTTs and corresponding available

     >>     bandwidths). Requires a fair amount of bytes, so then trust

     may be

     >>     an issue (I'm not sure whether a carrier would be willing

     to add

     >>     an extended Ethernet header to every encrypted IP packet

     >>     indicating interest in getting CSIG information on

     bottleneck links).

     >>

     >>             [SM] Yes encryption/privacy are reasons to stick to

     L2/L3.

     >>     I would guess in a limited domain deploying CSIG as a

     pseudo VLAN

     >>     header seems like a nice work-around, but this information

     really

     >>     should be inside IP header to go end to end. IMHO it also

     should

     >>     not be in an optional header, but should have been part of

the

     >>     mandatory header, but that ship has sailed long ago... It

turns

     >>     out that the mechanism intended here IPv6 extension headers

was

     >>     mis-deployed... (It should have been initiated with a really

     >>     desirable use-case so it would actrually see usage

immediately,

     >>     protocol design is a bit like evolution, in both cases "use

     it or

     >>     loose it" applies to some degree.)

     >>

     >>     Regards

     >>             Sebastian

     >>

     >>

     >>     >

     >>     > Regards, Ruediger

     >>     >

     >>     > -----Ursprüngliche Nachricht-----

     >>     > Von: Sebastian Moeller <[e-mail]><mailto:[e-mail]>

     >>     > Gesendet: Donnerstag, 14. September 2023 08:49

     >>     > An: Ingemar Johansson S <[e-mail]><mailto:[e-mail]>

     >>     > Cc: Geib, Rüdiger <[e-mail]><mailto:[e-mail]>;

[e-mail]<mailto:[e-mail]>;

     >> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>

     >>     > Betreff: Re: [tsvwg] [iccrg] New Internet Draft:

Congestion

     >>     Signaling (CSIG)

     >>     >

     >>     > Hi Ingemar

     >>     >

     >>     >> On Sep 14, 2023, at 08:42, Ingemar Johansson S

     >>     <[e-mail]><mailto:[e-mail]> wrote:

     >>     >>

     >>     >> Hi Ruediger

     >>     >>

     >>     >> Even though CSIG is on ethernet, it appears to be e2e as

the

     >>     feedback is on L4. So I guess somehow the CSIG info needs

     to jump

     >>     from domain to domain somewhow, and that sounds to me like

L3,

     >>     albeit perhaps brief jumps ?

     >>     >

     >>     >       [SM] rfc3168 and L4S ECN signaling faces the same

     hurdle,

     >>     forward path uses a different layer than feed-back path.

     And I do

     >>     not think that it is conceptually all that cleaner to have

     fewer

     >>     layers between forward and reverse signaling... "clean"

     would be

     >>     to put both forward and reverse information into the same

     layer,

     >>     but that is not on the table as far as I can see.

     >>     >       The other difference however, richness of signal, is

a

     >>     clear difference between 1 bit ECN and multibit CSIG (and

     >>     alternatives). (Side-note, sure the ECN bitfield is two

     bits but

     >>     it only carries 2 congestion states when ECN is in use,

which

     >>     makes it IMHO a 1-bit information channel, if we had

     followed the

     >>     SCE proposal with its 3 congestion states we would be at

     1.5 bits ;))

     >>     >

     >>     > Regards

     >>     >       Sebastian

     >>     >

     >>     >

     >>     >

     >>     >>

     >>     >> /Ingemar

     >>     >>

     >>     >>> -----Original Message-----

     >>     >>> From: [e-mail]<mailto:[e-mail]>

<[e-mail]><mailto:[e-mail]>

     >>     >>> Sent: Wednesday, 13 September 2023 14:20

     >>     >>> To: [e-mail]<mailto:[e-mail]>; Ingemar Johansson S

     >>     >>> <[e-mail]><mailto:[e-mail]>

     >>     >>> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;

     [e-mail]<mailto:[e-mail]>;

     >>     >>> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;

[e-mail]<mailto:[e-mail]>;

     >>     >>> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;

[e-mail]<mailto:[e-mail]>;

     >>     >>> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;

[e-mail]<mailto:[e-mail]>

     >>     >>> Subject: AW: [tsvwg] [iccrg] New Internet Draft:

Congestion

     >>     Signaling

     >>     >>> (CSIG)

     >>     >>>

     >>     >>> Hi Ingemar, hi Sebastian,

     >>     >>>

     >>     >>> Skimming over the draft only, isn't CSIG about

     Ethernet-domains,

     >>     >>> while L4S is E2E?

     >>     >>>

     >>     >>> Regards,

     >>     >>>

     >>     >>> Ruediger

     >>     >>>

     >>     >>> -----Ursprüngliche Nachricht-----

     >>     >>> Von: tsvwg <[e-mail]><mailto:[e-mail]> Im Auftrag von

     Sebastian

     >>     Moeller

     >>     >>> Gesendet: Mittwoch, 13. September 2023 13:42

     >>     >>> An: Ingemar Johansson S

     >>     >>> <ingemar.s.johansson=[e-mail]><mailto:ingemar.s.johansson=[e-mail]>

     >>     >>> Cc: Vidhi Goel <vidhi_goel=[e-mail]><mailto:vidhi_goel=[e-mail]>;

     >>     >>> Shihang(Vincent)

     <shihang9=[e-mail]><mailto:shihang9=[e-mail]>; tsvwg

     >>     >>> <[e-mail]><mailto:[e-mail]>; Jai Kumar <[e-mail]><mailto:[e-mail]>;

IETF

     >>     IPPM WG

     >>     >>> <[e-mail]><mailto:[e-mail]>; Tom Herbert

     >>     <tom=[e-mail]><mailto:tom=[e-mail]>;

     >>     >>> [e-mail]<mailto:[e-mail]>; Abhiram Ravi

     >>     <abhiramr=[e-mail]><mailto:abhiramr=[e-mail]>;

     >>     >>> Nandita Dukkipati <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;

     >>     Huangyihong

     >>     >>> (Rachel) <rachel.huang=[e-mail]><mailto:rachel.huang=[e-mail]>;

     Naoshad

     >>     Mehta

     >>     >>> <[e-mail]><mailto:[e-mail]>

     >>     >>> Betreff: Re: [tsvwg] [iccrg] New Internet Draft:

Congestion

     >>     Signaling

     >>     >>> (CSIG)

     >>     >>>

     >>     >>> Hi Ingemar,

     >>     >>>

     >>     >>>

     >>     >>>> On Sep 13, 2023, at 12:30, Ingemar Johansson S

     >>     >>> <ingemar.s.johansson=[e-mail]><mailto:ingemar.s.johansson=[e-mail]>

wrote:

     >>     >>>>

     >>     >>>> Hi

     >>     >>>>

     >>     >>>> I agree with Vihdi

     >>     >>>>

     >>     >>>> L4S is recently standardised

     >>     >>>

     >>     >>>     [SM] In experimental track, the goal is currently

     to test

     >>     whether it

     >>     >>> can/should be deployed at scale....

     >>     >>>

     >>     >>>> and it is definitely gaining traction also in 3GPP. We

     have

     >>     an echo

     >>     >>> system that is looking forward to having L4S widely

     deployed.

     >>     >>>> Still, the congestion control aspects are not fully

     explored

     >>     yet.

     >>     >>>> One

     >>     >>> interesting topic is if L4S allows to more safely

     deviate from

     >>     >>> additive increase to make congestion control algorithms

     more

     >>     quickly

     >>     >>> converge to higher link capacity. There are a number of

     study

     >>     topics

     >>     >>> around L4S congestion control that are listed in e.g

     the TCP

     >>     Prague draft.

     >>     >>>>

     >>     >>>> I cannot dictate what others should do with their time

and

     >>     money but

     >>     >>> personally I'd prefer that the IETF explores L4S and its

     >>     >>> possibilities and downsides before jumping on the next

     idea.

     >>     >>>

     >>     >>>     [SM] L4S can be described as taking the ideas

     behind DCTCP

     >>     and

     >>     >>> making them fit for use over the internet*. Yet the

     signaling

     >>     >>> discussed here is to be used in e.g. data center

contexts

     >>     where DCTCP

     >>     >>> is already used and found lacking compared to newer

methods

     >>     operating

     >>     >>> on richer congestion information (HPCC, Swift,

     Poseidon, ...).

     >>     >>>     Given that L4S essentially uses a multi-packet

     signal(**)

     >>     to report

     >>     >>> the "queue filling state" that is then stochastically

     distributed

     >>     >>> over all concurrent flows, it seems obvious to me that

     >>     reconstructing

     >>     >>> a reliable estimate of on-path queueing will take some

     time and

     >>     >>> averaging for each individual flow, I would guess that

     in some

     >>     >>> environments this delay simply is too costly.

     >>     >>>     So L4S and CSIG seem complementary and in no way

     mutually

     >>     exclusive.

     >>     >>>

     >>     >>>

     >>     >>> Regards

     >>     >>>     Sebastian

     >>     >>>

     >>     >>>

     >>     >>>

     >>     >>> *) I will not further discuss whether that is achieved

     or not

     >>     as it

     >>     >>> seems irrelevant here.

     >>     >>> **) In essence transmission of congestion state via a 1-

bit

     >>     serial

     >>     >>> channel, clocked at the (variable***) packet rate at the

     >>     bottleneck.

     >>     >>> ***) as packets are not of uniform size

     >>     >>>

     >>     >>>>

     >>     >>>> CSIG sounds to me like something that belongs more in

     ICCRG or ?

     >>     >>>>

     >>     >>>> /Ingemar

     >>     >>>>

     >>     >>>> From: tsvwg <[e-mail]><mailto:[e-mail]> On Behalf Of

     Vidhi Goel

     >>     >>>> Sent: Wednesday, 13 September 2023 00:59

     >>     >>>> To: Shihang(Vincent)

     <shihang9=[e-mail]><mailto:shihang9=[e-mail]>

     >>     >>>> Cc: Huangyihong (Rachel)

     >>     <rachel.huang=[e-mail]><mailto:rachel.huang=[e-mail]>;

     >>     >>> Tom Herbert <tom=[e-mail]><mailto:tom=[e-mail]>;

     Abhiram Ravi

     >>     >>> <abhiramr=[e-mail]><mailto:abhiramr=[e-mail]>; IETF IPPM WG

     >>     <[e-mail]><mailto:[e-mail]>;

     >>     >>> tsvwg <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;

     Nandita

     >>     >>> Dukkipati <[e-mail]><mailto:[e-mail]>; Naoshad Mehta

     >>     <[e-mail]><mailto:[e-mail]>;

     >>     >>> Jai Kumar <[e-mail]><mailto:[e-mail]>

     >>     >>>> Subject: Re: [tsvwg] [iccrg] New Internet Draft:

     Congestion

     >>     >>>> Signaling

     >>     >>> (CSIG)

     >>     >>>>

     >>     >>>> 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.

     >>     >>>>

     >>     >>>> Vidhi

     >>     >>>>

     >>     >>>>

     >>     >>>> On Sep 12, 2023, at 3:12 AM, Shihang(Vincent)

     >>     >>> <shihang9=[e-mail]><mailto: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]><mailto:[e-mail]> On Behalf Of

     Huangyihong

     >>     (Rachel)

     >>     >>>> Sent: Tuesday, September 12, 2023 5:41 PM

     >>     >>>> To: Tom Herbert <tom=[e-mail]><mailto:tom=[e-mail]>;

     >>     Abhiram Ravi

     >>     >>> <abhiramr=[e-mail]><mailto:abhiramr=[e-mail]>

     >>     >>>> Cc: IETF IPPM WG <[e-mail]><mailto:[e-mail]>; tsvwg

<[e-mail]><mailto:[e-mail]>;

     >>     >>> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Nandita Dukkipati

     >>     >>> <[e-mail]><mailto:[e-mail]>; Naoshad Mehta

     <[e-mail]><mailto:[e-mail]>; Jai

     >>     Kumar

     >>     >>> <[e-mail]><mailto:[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]><mailto:[e-mail]> 代表 Tom Herbert

     >>     >>>> 发送时间: 2023年9月10日 0:10

     >>     >>>> 收件人: Abhiram Ravi

     <abhiramr=[e-mail]><mailto:abhiramr=[e-mail]>

     >>     >>>> 抄送: IETF IPPM WG <[e-mail]><mailto:[e-mail]>; tsvwg

     <[e-mail]><mailto:[e-mail]>;

     >>     >>> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Nandita Dukkipati

     >>     >>> <[e-mail]><mailto:[e-mail]>; Naoshad Mehta

     <[e-mail]><mailto:[e-mail]>; Jai

     >>     Kumar

     >>     >>> <[e-mail]><mailto:[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]><mailto: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

     >>     >>

     >>     >

     >>     > _______________________________________________

     >>     > iccrg mailing list

     >>     > [e-mail]<mailto:[e-mail]>

     >>     > https://www.irtf.org/mailman/listinfo/iccrg<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-058e9947a4f3b84a&q=1&e=d9705e4d-fa16-4e98-b8dd-5b3533890602&u=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Ficcrg>

     >>

     >>     --     CCWG mailing list

     >> [e-mail]<mailto:[e-mail]>

     >> https://www.ietf.org/mailman/listinfo/ccwg

     >>

     >

     >

     > _______________________________________________

     > iccrg mailing list

     > [e-mail]<mailto:[e-mail]>

     > https://www.irtf.org/mailman/listinfo/iccrg<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-058e9947a4f3b84a&q=1&e=d9705e4d-fa16-4e98-b8dd-5b3533890602&u=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Ficcrg>



     _______________________________________________

     iccrg mailing list

     [e-mail]<mailto:[e-mail]>

     https://www.irtf.org/mailman/listinfo/iccrg<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-058e9947a4f3b84a&q=1&e=d9705e4d-fa16-4e98-b8dd-5b3533890602&u=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Ficcrg>







--

K. K. Ramakrishnan



_______________________________________________

iccrg mailing list

[e-mail]<mailto:[e-mail]>

https://www.irtf.org/mailman/listinfo/iccrg<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-058e9947a4f3b84a&q=1&e=d9705e4d-fa16-4e98-b8dd-5b3533890602&u=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Ficcrg>

--

________________________________________________________________

Bob Briscoehttp://bobbriscoe.net/<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-60c0becec43f4914&q=1&e=d9705e4d-fa16-4e98-b8dd-5b3533890602&u=http%3A%2F%2Fbobbriscoe.net%2F>

_______________________________________________

iccrg mailing list

[e-mail]<mailto:[e-mail]>

https://www.irtf.org/mailman/listinfo/iccrg<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-058e9947a4f3b84a&q=1&e=d9705e4d-fa16-4e98-b8dd-5b3533890602&u=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Ficcrg>





--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-60c0becec43f4914&q=1&e=d9705e4d-fa16-4e98-b8dd-5b3533890602&u=http%3A%2F%2Fbobbriscoe.net%2F>









_______________________________________________

iccrg mailing list

[e-mail]<mailto:[e-mail]>

https://www.irtf.org/mailman/listinfo/iccrg<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-058e9947a4f3b84a&q=1&e=d9705e4d-fa16-4e98-b8dd-5b3533890602&u=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Ficcrg>



--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-60c0becec43f4914&q=1&e=d9705e4d-fa16-4e98-b8dd-5b3533890602&u=http%3A%2F%2Fbobbriscoe.net%2F>