Discussion of explicit congestion notification's impact on the Internet
 help / color / mirror / Atom feed
From: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
To: "Toke H?iland-J?rgensen" <toke@toke.dk>
Cc: ecn-sane@lists.bufferbloat.net
Subject: Re: [Ecn-sane] Using the ECN bits as signalling for explicit congestion control
Date: Wed, 15 May 2019 08:43:33 -0700 (PDT)	[thread overview]
Message-ID: <201905151543.x4FFhXrA051657@gndrsh.dnsmgr.net> (raw)
In-Reply-To: <87zhno25g0.fsf@toke.dk>

> This popped up in my Google scholar: "ABC: A Simple Explicit Congestion
> Control Protocol for Wireless Networks" - https://arxiv.org/pdf/1905.03429
> 
> Basically, they propose an explicit congestion control mechanism that
> uses signalling from the bottleneck router to slow down or speed up, and
> they re-purpose ECT(0) and ECT(1) as the signalling mechanism. I do
> believe the end result is rather similar to SCE, isn't it?
> 
> The appendix contains what appears to be an extensive stability
> analysis.

It appears to indeed be similiar, though they solved
the hard problem with:
	To this end, ABC routers
	separate ABC and non-ABC flows into two queues, and
	use a simple algorithm to schedule packets from these
	queues. ABC makes no assumptions about the conges-
	tion control algorithm of non-ABC flows, is robust to
	the presence of short or application-limited flows, and
	requires a small amount of state at the router.

Thus they require a 2 queue AQM, something the SCE work
knows is the easy way out, and are trying to solv 
in ways that do not require this added complexity.

Also they seem to be miss named the actual bits and
confused the bit names with the meaning of the 4 possible
code values.  The bits, per RFC are ECT(0) and ECT(1)
and can be used to signal the 4 states non-ECN, ECN cable,
unused, and CE (by current RFC, we intened to consume
the unused as SCE)

I find it interesting that the apparent publication
date is ~16 days after the SCE ietf/104 presentation
and some months after the SCE work had become semi public.

Regards,
-- 
Rod Grimes                                                 rgrimes@freebsd.org

      reply	other threads:[~2019-05-15 15:43 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-14 19:37 Toke Høiland-Jørgensen
2019-05-15 15:43 ` Rodney W. Grimes [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/ecn-sane.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201905151543.x4FFhXrA051657@gndrsh.dnsmgr.net \
    --to=4bone@gndrsh.dnsmgr.net \
    --cc=ecn-sane@lists.bufferbloat.net \
    --cc=toke@toke.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox