[Bloat] Fwd: [CCWG] ETC: An Elastic Transmission Control Using End-to-End Available Bandwidth Perception

[Bloat] Fwd: [CCWG] ETC: An Elastic Transmission Control Using End-to-End Available Bandwidth Perception

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 2154 bytes --]

very encouraging

---------- Forwarded message ---------
From: Hesham ElBakoury <helbakoury@gmail.com>
Date: Wed, Jul 10, 2024 at 1:34 PM
Subject: [CCWG] ETC: An Elastic Transmission Control Using End-to-End
Available Bandwidth Perception
To: <ccwg@ietf.org>


This paper [1] is published in this week USENIX ATC 2024. It is an
interesting paper with surprising results.

*Paper Abstract*
"Researchers and practitioners have proposed various transport protocols to
keep up with advances in networks and the applications that use them.
Current Wide Area Network protocols strive to identify a congestion signal
to make distributed but fair judgments. However, existing congestion
signals such as RTT and packet loss can only be observed after congestion
occurs. We therefore propose Elastic Transmission Control (ETC). ETC
exploits the instantaneous receipt rate of N consecutive packets as the
congestion signal. We refer to this as the pulling rate, as we posit that
the receipt rate can be used to “pull” the sending rate towards a fair
share of the capacity. Naturally, this signal can be measured prior to
congestion, as senders can access it immediately after the acknowledgment
of the first N packets. Exploiting the pulling rate measurements, ETC
calculates the optimal rate update steps following a simple elastic
principle: the further away from the pulling rate, the faster the sending
rate increases. We conduct extensive experiments using both simulated and
real networks. Our results show that ETC outperforms the state-of-the-art
protocols in terms of both throughput (15% higher than Copa) and latency
(20% lower than BBR). Besides, ETC shows superiority in convergence speed
and fairness, with a 10× im-provement in convergence time even compared to
the protocol with the best convergence performance."

Hesham
[1] https://www.usenix.org/conference/atc24/presentation/han
-- 
CCWG mailing list -- ccwg@ietf.org
To unsubscribe send an email to ccwg-leave@ietf.org


-- 
https://www.linkedin.com/feed/update/urn:li:activity:7203400057172180992/
Donations Drive.
Dave Täht CSO, LibreQos

[-- Attachment #2: Type: text/html, Size: 3161 bytes --]

Re: [Bloat] Fwd: [CCWG] ETC: An Elastic Transmission Control Using End-to-End Available Bandwidth Perception

[David Collier-Brown]

[-- Attachment #1: Type: text/plain, Size: 2733 bytes --]

One of those papers that make you go "why didn't I think of that?"

Of course, it does have to work (;-))

--dave

On 2024-07-10 16:40, Dave Taht via Bloat wrote:
> very encouraging
>
> ---------- Forwarded message ---------
> From: *Hesham ElBakoury* <helbakoury@gmail.com>
> Date: Wed, Jul 10, 2024 at 1:34 PM
> Subject: [CCWG] ETC: An Elastic Transmission Control Using End-to-End 
> Available Bandwidth Perception
> To: <ccwg@ietf.org>
>
>
> This paper [1] is published in this week USENIX ATC 2024. It is an 
> interesting paper with surprising results.
>
> *_Paper Abstract_*
> "Researchers and practitioners have proposed various transport 
> protocols to keep up with advances in networks and the applications 
> that use them. Current Wide Area Network protocols strive to identify 
> a congestion signal to make distributed but fair judgments. However, 
> existing congestion signals such as RTT and packet loss can only be 
> observed after congestion occurs. We therefore propose Elastic 
> Transmission Control (ETC). ETC exploits the instantaneous receipt 
> rate of N consecutive packets as the congestion signal. We refer to 
> this as the pulling rate, as we posit that the receipt rate can be 
> used to “pull” the sending rate towards a fair share of the capacity. 
> Naturally, this signal can be measured prior to congestion, as senders 
> can access it immediately after the acknowledgment of the first N 
> packets. Exploiting the pulling rate measurements, ETC calculates the 
> optimal rate update steps following a simple elastic principle: the 
> further away from the pulling rate, the faster the sending rate 
> increases. We conduct extensive experiments using both simulated and 
> real networks. Our results show that ETC outperforms the 
> state-of-the-art protocols in terms of both throughput (15% higher 
> than Copa) and latency (20% lower than BBR). Besides, ETC shows 
> superiority in convergence speed and fairness, with a 10× im-provement 
> in convergence time even compared to the protocol with the best 
> convergence performance."
>
> Hesham
> [1] https://www.usenix.org/conference/atc24/presentation/han
> -- 
> CCWG mailing list -- ccwg@ietf.org
> To unsubscribe send an email to ccwg-leave@ietf.org
>
>
> -- 
> https://www.linkedin.com/feed/update/urn:li:activity:7203400057172180992/
> Donations Drive.
> Dave Täht CSO, LibreQos
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb@spamcop.net            |              -- Mark Twain

[-- Attachment #2: Type: text/html, Size: 5951 bytes --]

Re: [Bloat] Fwd: [CCWG] ETC: An Elastic Transmission Control Using End-to-End Available Bandwidth Perception

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 3637 bytes --]

On Wed, Jul 10, 2024 at 3:11 PM David Collier-Brown via Bloat <
bloat@lists.bufferbloat.net> wrote:

> One of those papers that make you go "why didn't I think of that?"
>
> Of course, it does have to work (;-))
>

No sources, no email addresses, I am tempted to drop in on the conference
to see if any source is available.

There are a lot of ideas in there that I have been advocating a while -
varying the pacing rate (e!) to get an early estimate of congestion - and
quite a few more newer ones that seem excellent, like just treating the
leading edge of an ack as part of the estimator.  Love how well it competes
with itself!

It's just a paper... no sources... agggh....

> --dave
> On 2024-07-10 16:40, Dave Taht via Bloat wrote:
>
> very encouraging
>
> ---------- Forwarded message ---------
> From: Hesham ElBakoury <helbakoury@gmail.com>
> Date: Wed, Jul 10, 2024 at 1:34 PM
> Subject: [CCWG] ETC: An Elastic Transmission Control Using End-to-End
> Available Bandwidth Perception
> To: <ccwg@ietf.org>
>
>
> This paper [1] is published in this week USENIX ATC 2024. It is an
> interesting paper with surprising results.
>
> *Paper Abstract*
> "Researchers and practitioners have proposed various transport protocols
> to keep up with advances in networks and the applications that use them.
> Current Wide Area Network protocols strive to identify a congestion signal
> to make distributed but fair judgments. However, existing congestion
> signals such as RTT and packet loss can only be observed after congestion
> occurs. We therefore propose Elastic Transmission Control (ETC). ETC
> exploits the instantaneous receipt rate of N consecutive packets as the
> congestion signal. We refer to this as the pulling rate, as we posit that
> the receipt rate can be used to “pull” the sending rate towards a fair
> share of the capacity. Naturally, this signal can be measured prior to
> congestion, as senders can access it immediately after the acknowledgment
> of the first N packets. Exploiting the pulling rate measurements, ETC
> calculates the optimal rate update steps following a simple elastic
> principle: the further away from the pulling rate, the faster the sending
> rate increases. We conduct extensive experiments using both simulated and
> real networks. Our results show that ETC outperforms the state-of-the-art
> protocols in terms of both throughput (15% higher than Copa) and latency
> (20% lower than BBR). Besides, ETC shows superiority in convergence speed
> and fairness, with a 10× im-provement in convergence time even compared to
> the protocol with the best convergence performance."
>
> Hesham
> [1] https://www.usenix.org/conference/atc24/presentation/han
> --
> CCWG mailing list -- ccwg@ietf.org
> To unsubscribe send an email to ccwg-leave@ietf.org
>
>
> --
> https://www.linkedin.com/feed/update/urn:li:activity:7203400057172180992/
> Donations Drive.
> Dave Täht CSO, LibreQos
>
> _______________________________________________
> Bloat mailing listBloat@lists.bufferbloat.nethttps://lists.bufferbloat.net/listinfo/bloat
>
> --
> David Collier-Brown,         | Always do right. This will gratify
> System Programmer and Author | some people and astonish the restdavecb@spamcop.net           |              -- Mark Twain
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>


-- 
https://www.linkedin.com/feed/update/urn:li:activity:7203400057172180992/
Donations Drive.
Dave Täht CSO, LibreQos

[-- Attachment #2: Type: text/html, Size: 7003 bytes --]

Re: [Bloat] Fwd: [CCWG] ETC: An Elastic Transmission Control Using End-to-End Available Bandwidth Perception

[Stephen Hemminger]

On Wed, 10 Jul 2024 15:28:28 -0700
Dave Taht via Bloat <bloat@lists.bufferbloat.net> wrote:

> On Wed, Jul 10, 2024 at 3:11 PM David Collier-Brown via Bloat <
> bloat@lists.bufferbloat.net> wrote:  
> 
> > One of those papers that make you go "why didn't I think of that?"
> >
> > Of course, it does have to work (;-))
> >  
> 
> No sources, no email addresses, I am tempted to drop in on the conference
> to see if any source is available.
> 
> There are a lot of ideas in there that I have been advocating a while -
> varying the pacing rate (e!) to get an early estimate of congestion - and
> quite a few more newer ones that seem excellent, like just treating the
> leading edge of an ack as part of the estimator.  Love how well it competes
> with itself!
> 
> It's just a paper... no sources... agggh....

Poking around a little, author seems to be associated with:
 FutureWei Technolgies http://futurewei.com
Which has various Open Source marketing stuff in their vision but no
github or download links.

Re: [Bloat] Fwd: [CCWG] ETC: An Elastic Transmission Control Using End-to-End Available Bandwidth Perception

[David Collier-Brown]

[-- Attachment #1: Type: text/plain, Size: 1969 bytes --]

Nor do I see them on gitlab (:-()


Changing the subject, I'd love to see /how/, but they do seem to say /what/.

Do you think there is enough information in there that one could do a 
proof-of-concept? Not even an MVP, just enough to confirm or deny the 
hypothesis, if they don't offer source.

As they're distinguishing themselves from Huawei, which owns them[1] by 
saying that they're "dedicated to pursuing openness in Research & 
Development (R&D) by embracing Open Innovation Model." I do think 
there's a good chance that they'll open-source an MVP.

--dave

[1. 
https://www.reuters.com/article/technology/exclusive-huaweis-us-research-arm-builds-separate-identity-idUSKCN1TP2DG/ 
]


On 2024-07-10 18:44, Stephen Hemminger wrote:
> On Wed, 10 Jul 2024 15:28:28 -0700
> Dave Taht via Bloat<bloat@lists.bufferbloat.net>  wrote:
>
>> On Wed, Jul 10, 2024 at 3:11 PM David Collier-Brown via Bloat <
>> bloat@lists.bufferbloat.net> wrote:  
>>
>>> One of those papers that make you go "why didn't I think of that?"
>>>
>>> Of course, it does have to work (;-))
>>>   
>> No sources, no email addresses, I am tempted to drop in on the conference
>> to see if any source is available.
>>
>> There are a lot of ideas in there that I have been advocating a while -
>> varying the pacing rate (e!) to get an early estimate of congestion - and
>> quite a few more newer ones that seem excellent, like just treating the
>> leading edge of an ack as part of the estimator.  Love how well it competes
>> with itself!
>>
>> It's just a paper... no sources... agggh....
> Poking around a little, author seems to be associated with:
>   FutureWei Technolgieshttp://futurewei.com
> Which has various Open Source marketing stuff in their vision but no
> github or download links.

-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb@spamcop.net            |              -- Mark Twain

[-- Attachment #2: Type: text/html, Size: 3820 bytes --]