Subject: [aqm] Status of the GSP AQM?

From: Roland Bless <[email-masked]>
Date: Thu, 14 Dec 2017 22:35:47 +0100

Hi folks,

I was wondering what happened to the GSP AQM proposal
(draft-lauten-aqm-gsp see
(https://tools.ietf.org/html/draft-lauten-aqm-gsp).
Discussion seems to have ended after IETF 93 and we probably
missed the point of discussing WG adoption.
IMHO this AQM should also be documented as RFC. It performs extremely
well in some settings (better than CoDel or PIE) and its implementation
complexity is also lower. Wolfram, are you interested in finishing this?
Should we continue in tsvwg?

Regards,
 Roland

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 14 Dec 2017 16:59:45 -0500

> Should we continue in tsvwg?

I mentioned GSP as a possible work item, back when we were discussing 
rechartering, but apparently it was not compelling to the group at that 
time.

When we did the AQM algorithm adoption call ~2014, GSP appeared to be 
basically viable technically, but there wasn't evidence that multiple 
parties were interested in working with it enough to go forward (not 
just working the document, but implementing, simulating, testing, 
analyzing, deploying, etc).   There is a thread in the archives with 
subject "[aqm] adoption call: algorithm drafts".

I haven't noticed a change in activity around GSP since then, but 
apologize if I'm just ignorant of it!

---

From: Michael Welzl <[email-masked]>
Date: Fri, 15 Dec 2017 08:26:55 +0100

> On Dec 14, 2017, at 10:59 PM, Wesley Eddy <[email-masked]> wrote:
> 
> I mentioned GSP as a possible work item, back when we were discussing rechartering, but apparently it was not compelling to the group at that time.
> 
> When we did the AQM algorithm adoption call ~2014, GSP appeared to be basically viable technically, but there wasn't evidence that multiple parties were interested in working with it enough to go forward (not just working the document, but implementing, simulating, testing, analyzing, deploying, etc).   There is a thread in the archives with subject "[aqm] adoption call: algorithm drafts”.

I agree, I also remember lack of activity / interest, but I would like to encourage people to at least take a look at this.
In my opinion, it was an extremely interesting proposal, and I felt I learned something new from listening to Wolfram  (I had become conditioned to believe that removing synchronization requires randomness).

Cheers,
Michael

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Fri, 15 Dec 2017 09:25:51 +0100

Hi Wesley,

> subject "[aqm] adoption call: algorithm drafts".

Thanks for the pointer! At that point in time there was not enough
experience with it.

> apologize if I'm just ignorant of it!

That's right, maybe Wolfram was busy with other stuff.
Our group, however, worked with it at speeds of 1 Gbit/s
and also 10 Gbit/s and we can confirm that its performance is comparable
to - and w.r.t. loss desynchronization - even better than CoDel or PIE
in many of our tested scenarios. Since it's heading for just an
experimental status, the bar shouldn't be too high to get this finished.

Regards,
 Roland

---

From: "Francini, Andrea (Nokia - US/Murray Hill)" <[email-masked]>
Date: Fri, 15 Dec 2017 15:55:54 +0000

I know Wolfram is on vacation until January 8. I am sure he will provide input when he comes back.

I believe the interest of the working group in GSP faded because there was not a public implementation available for testing. If the GSP version mentioned by Roland can be made public, it is definitely worth testing it.

Regards,

Andrea

-----Original Message-----
From: aqm [mailto:[email-masked]] On Behalf Of Bless, Roland (TM)
Sent: Friday, December 15, 2017 3:26 AM
To: Wesley Eddy <[email-masked]>; [email-masked]; Lautenschlaeger, Wolfram (Nokia - DE/Stuttgart) <[email-masked]>
Subject: Re: [aqm] Status of the GSP AQM?

Hi Wesley,

Regards,
 Roland

_______________________________________________
aqm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/aqm

---

From: Jonathan Morton <[email-masked]>
Date: Fri, 15 Dec 2017 18:15:48 +0200

Reading the spec, it looks very much as though it's tuned for
implementation in relatively simple, high-speed nodes.  It doesn't look at
all like it would work in conjunction with flow isolation, which is
inherently a much more effective idea when feasible to deploy - which it
should be at speeds up to at least 1Gbps.

However, I could see some use for GSP when combined with host isolation, at
nodes aggregating a large number of subcriber hosts' traffic and thus
requiring very high aggregate throughput.  Host isolation doesn't require
as many resources as full flow isolation, and is typically implemented
anyway as part of per-subscriber provisioning.

If tests are carried out, that might be the best scenario to start with.

- Jonathan Morton

---

From: "Francini, Andrea (Nokia - US/Murray Hill)" <[email-masked]>
Date: Fri, 15 Dec 2017 17:19:39 +0000

The paper we published at HPSR 2015 (http://ieeexplore.ieee.org/document/7483103/ ) indeed emphasizes the application of GSP to high-speed links, where the simplicity of the scheme is most beneficial.

If “conjunction with flow isolation” means combination of the algorithm with a flow queueing arrangement, there is logically no restriction in realizing it. We tested FQ-GSP on ns2, getting similar results as with other FQ-AQM schemes (never worse, never overwhelmingly better in the scenarios we looked at). Since the algorithmic simplicity is not as critical in lower-speed links, we thought there was little value in trying to add one more scheme to an already crowded space.

Also (and this is just my opinion), I don’t think that combining FQ and AQM is a good idea, because it imposes a single policy on all flows despite the variety of their needs. I like a plain FQ with large buffer much better, because it guarantees bandwidth fairness and makes every application solely responsible for the queuing delay it gets.
Andrea

From: Jonathan Morton [mailto:[email-masked]]
Sent: Friday, December 15, 2017 11:16 AM
To: Francini, Andrea (Nokia - US/Murray Hill) <[email-masked]>
Cc: Roland Bless <[email-masked]>; Wesley Eddy <[email-masked]>; [email-masked]; Lautenschlaeger, Wolfram (Nokia - DE/Stuttgart) <[email-masked]>
Subject: Re: [aqm] Status of the GSP AQM?

Reading the spec, it looks very much as though it's tuned for implementation in relatively simple, high-speed nodes.  It doesn't look at all like it would work in conjunction with flow isolation, which is inherently a much more effective idea when feasible to deploy - which it should be at speeds up to at least 1Gbps.

However, I could see some use for GSP when combined with host isolation, at nodes aggregating a large number of subcriber hosts' traffic and thus requiring very high aggregate throughput.  Host isolation doesn't require as many resources as full flow isolation, and is typically implemented anyway as part of per-subscriber provisioning.

- Jonathan Morton

---

From: Jonathan Morton <[email-masked]>
Date: Fri, 15 Dec 2017 22:04:33 +0200

On 15 Dec 2017 19:19, "Francini, Andrea (Nokia - US/Murray Hill)" <
[email-masked]> wrote:
>
> If “conjunction with flow isolation” means combination of the algorithm
with a flow queueing arrangement, there is logically no restriction in
realizing it. We tested FQ-GSP on ns2, getting similar results as with
other FQ-AQM schemes (never worse, never overwhelmingly better in the
scenarios we looked at). Since the algorithmic simplicity is not as
critical in lower-speed links, we thought there was little value in trying
to add one more scheme to an already crowded space.

Perhaps a better wording would be, "it seems very unlikely to outperform
existing AQMs in conjunction with FQ".

> Also (and this is just my opinion), I don’t think that combining FQ and
AQM is a good idea, because it imposes a single policy on all flows despite
the variety of their needs. I like a plain FQ with large buffer much
better, because it guarantees bandwidth fairness and makes every
application solely responsible for the queuing delay it gets.

I have a couple of compelling arguments in favour of an AQM-FQ combination:

1: ECN aware flows are able to avoid incurring packet losses, by receiving
and acting on information about link congestion when they reach their
fair-share throughput.  That should be music to the ears of those industry
members who are apparently allergic to packet loss.

2: When it is unfortunately necessary to put the shaper downstream of the
physical bottleneck link (ie. when consumers must compensate for an ISP's
bufferbloat), AQM is the only reliable way to keep the bottleneck queue
empty.  Combining it with FQ ensures that only the saturating flows receive
congestion signals and potentially lose packets.

- Jonathan Morton