Subject: [tsvwg] WGLC for draft-ietf-tsvwg-byte-pkt-congest-10 - to conclude 28th June 2013

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 19 Jun 2013 16:25:23 +0100

This email announces the beginning of a short working group last call 
for draft-ietf-tsvwg-byte-pkt-congest-10, "Byte and Packet Congestion 
Notification". This document is now thought by the authors to be ready 
to proceed to be published as a Proposed Standard, it completed  a 
former WGLC and has since received review by the IESG and was 
subsequently revised. Please send any comments on version -10 to the 
TSVWG list.

The draft is available at:
http://tools.ietf.org/html/draft-ietf-tsvwg-byte-pkt-congest

The last call will run for one week, ending Friday, 28th June 2013.
Emails saying "I support" or "I don't support" are also most helpful in
judging the consensus.

James, David and Gorry
(TSVWG Chairs)

---

From: John Leslie <[email-masked]>
Date: Wed, 19 Jun 2013 12:08:24 -0400

Gorry Fairhurst <[email-masked]> wrote:
> Notification".

   First of all, I wish to applaud the authors for expanding the question
of scaling congestion control signals and responses to include queue
length in time.

   I agree with the authors that _when_ queue size cannot be measured in
time, the remaining question is whether to measure bytes or packets.

   Alas, I do not agree with the authors that measuring queue size in
_payload_ bytes is useful -- the measurement should be bytes-on-the-wire.
It is because of the difficulties in measuring byte-on-the-wire that I
tend to prefer measuring the queue length in packets.

   But arguing that becomes pointless when queue size can be measured in
time.

   Considering the current work in progress on CoDel and PIE, etc., I
wonder whether it actually makes sense to nail down the question of
what to do when we can't measure queue length in time.

   Thus, I do not favor trying to finish this draft at this time.

   If we do wish to finish this draft at this time, I have other questions
that I hope we will consider.

   I also note the Fred Baker draft revising RFC2309 being considered
in the proposed AQM WG. These two drafts overlap so much that I believe
a single co-ordinated draft revising 2309 is wiser.

--
John Leslie <[email-masked]>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 19 Jun 2013 18:04:07 +0000

I would agree that it makes little sense to almost-simultaneously update and obsolete RFC 2309. If we are going to have a working group whose job is to rewrite the AQM recommendation, which is what Wes said to TSVAREA that he wanted to do (and hence my draft) at IETF 86, it would be best to collaborate.

> a single co-ordinated draft revising 2309 is wiser.

-----------------------------------
"We are learning to do a great many clever things...The next great task
will be to learn not to do them."

- G. K. Chesterton (1874-1936)

---

From: [email-masked]
Date: Wed, 19 Jun 2013 19:40:17 +0100

The intended purpose of the WGLC was to confirm the final changes made by
the IESG. I'm happy to see discussion on these important topics, however
in considering this we also need to note the set of issues that were
raised during the original WGLC.

If this is in conflict with new individual submission, then maybe we have
a potential charter problem that should also perhaps be considered.

Gorry

> I would agree that it makes little sense to almost-simultaneously update
> and obsolete RFC 2309. If we are going to have a working group whose job
> is to rewrite the AQM recommendation, which is what Wes said to TSVAREA
> that he wanted to do (and hence my draft) at IETF 86, it would be best to
> collaborate.
>

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 19 Jun 2013 22:30:40 -0400

> time, the remaining question is whether to measure bytes or packets.

I also agree with this.

> tend to prefer measuring the queue length in packets.

The document explains why packets are generally a less useful metric,
and why bytes are preferred and won the recommendation.

Clearly you're right that bytes on-the-wire might in several cases be
difficult to infer in code looking only at layer-3 packets, but this
isn't impossible, nor does it seem to lead to an unusably bad
approximation in many common cases.

So, I think the recommendation as-is is perfectly valid, and would not
sacrifice recommending the best thing in order to recommend something
that's easy but known to have pathologies.

Since this isn't a protocol with compatibility requirements, any piece
of equipment or software is free to disregard that advice and the
analysis if it seems too difficult, and the Internet will survive.

-- 
Wes Eddy
MTI Systems

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 19 Jun 2013 22:30:47 -0400

> a potential charter problem that should also perhaps be considered.

I'm not sure that there has to be any conflict.

This document already mentions sojourn time as a possible dimension to
measure, as an alternative to length in bytes of packets.  It makes
pretty clear statements that time is the desirable metric, if it can
be used, and that the majority of this document only pertains to the
algorithms that don't use time (see first paragraph of section 2.1).

This document is a focused piece of work on that particular issue of
bytes versus packets as a measure of length.  Fred's AQM document is
much higher-level, and tries to fold in the full set of things learned
since 2309.  This byte/packet topic is only one of several.

It seems obvious that the take-away recommendation here about bytes
rather than packets can be inserted into Fred's document with reference
to this one for the full details.

So ... yeah, there is a separate WG trying to be born to deal with AQM,
but I don't understand why that would hold this up at all.  Sorting out
the family tree of documents (and documents coming out of a not yet
even formed WG) and who updates or obsoletes who and how they all
relate is good to do, but this one is a WG item for TSVWG and can be
completed now ... we'll worry about the metadata on the AQM WG docs
when there is actually an AQM WG.

Just my 2 cents.

-- 
Wes Eddy
MTI Systems

---

From: <[email-masked]>
Date: Thu, 20 Jun 2013 08:18:49 +0200

I support progress of the document.

I also agree, that measuring queues by delay as proposed by Codel and PIE is desireable. These mechanisms are no commodity yet.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gorry Fairhurst
Sent: Wednesday, June 19, 2013 5:25 PM
To: tsvwg WG
Cc: tsvwg chair
Subject: [tsvwg] WGLC for draft-ietf-tsvwg-byte-pkt-congest-10 - to conclude 28th June 2013

James, David and Gorry
(TSVWG Chairs)

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 20 Jun 2013 07:06:20 +0000

> approximation in many common cases.

I can only speak for one implementation, but that one implementation looks at link-layer bytes (including VPN-overhead bytes), not network-layer bytes. With all due respect, this entire discussion is pretty academic once one gets away from packets.

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 20 Jun 2013 08:19:19 +0000

Hi,

On Jun 19, 2013, at 20:04, Fred Baker (fred) <[email-masked]> wrote:
> I would agree that it makes little sense to almost-simultaneously update and obsolete RFC 2309.

I think you're vastly optimistic in terms of seeing an RFC out of the AQM WG-to-be :-)

> If we are going to have a working group whose job is to rewrite the AQM recommendation, which is what Wes said to TSVAREA that he wanted to do (and hence my draft) at IETF 86, it would be best to collaborate.

I think we should ship draft-ietf-tsvwg-byte-pkt-congest now, and figure out what to do with it and RFC2309 when the AQM is underway.

Lars

---

From: Dave Taht <[email-masked]>
Date: Thu, 20 Jun 2013 02:04:53 -0700

> I think we should ship draft-ietf-tsvwg-byte-pkt-congest now, and figure out what to do with it and RFC2309 when the AQM is underway.

I do not support this draft for the reasons I outlined in:

http://www.ietf.org/mail-archive/web/tsvwg/current/msg12003.html

the least of which was the competing updates to rfc2039.

As noted therein, byte-congest might be useful if it were specifically
narrowed down to focus on best current practices for RED and came with
operational advice from an actual deployment and data from actual
traffic (rather than the theoretical argument at it core), backing
references for section 6, had updates for more modern protocols, and
so on.

and I'd made a few other comments.

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

---

From: "Black, David" <[email-masked]>
Date: Thu, 20 Jun 2013 08:57:53 -0400

> the least of which was the competing updates to rfc2039.

That would be 2309, and I agree with Lars that holding this draft up because
a new WG-to-be aspires to replace 2309 is not a good idea.

> traffic (rather than the theoretical argument at its core), backing

Actually, it's somewhat broader than that, as I think Dave T. hit the nail
on the head in this line in his other message:

> And if we can agree that AQM = Active queue *length* management

That appears to exactly right - the byte-pkt-congest draft applies to
algorithms that manage queues primarily by size (length), not time.  A
little bit of clarifying text in the draft would go a long way in that
regard.  In contrast, I would not impose a corresponding restriction
on the AQM BOF in Berlin - that effort is starting from a problem and
should have flexibility in figuring out what to do to address it.

I think this draft has done something useful; the algorithms to which it
applies are extensively deployed and far from obsolete, and I'd be
disappointed if we lose the results that apply to existing algorithms
courtesy of strong interest in working on new ones.

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave
> Taht
> Sent: Thursday, June 20, 2013 5:05 AM
> To: Eggert, Lars
> Cc: Gorry Fairhurst; Fred Baker (fred); tsvwg WG
> Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-byte-pkt-congest-10 - to
> conclude 28th June 2013
> 
> and obsolete RFC 2309.
> >> If we are going to have a working group whose job is to rewrite the AQM
> recommendation, which is what Wes said to TSVAREA that he wanted to do (and
> hence my draft) at IETF 86, it would be best to collaborate.
> >
> > I think we should ship draft-ietf-tsvwg-byte-pkt-congest now, and figure out
> what to do with it and RFC2309 when the AQM is underway.
> 
> Fixing bufferbloat with cerowrt:
> http://www.teklibre.com/cerowrt/subscribe.html

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 20 Jun 2013 14:40:10 +0000

> I think we should ship draft-ietf-tsvwg-byte-pkt-congest now, and figure out what to do with it and RFC2309 when the AQM is underway.

I'm in favor of that.

---

From: John Leslie <[email-masked]>
Date: Fri, 28 Jun 2013 14:09:24 -0400

Gorry Fairhurst <[email-masked]> wrote:
> to proceed to be published as a Proposed Standard...

   Alas, we do need clarity about the intended status.

   I cannot see how this draft would qualify for Proposed Standard; so
I will not discuss that further unless someone confirms that that indeed
is the status that will be proposed.

   The document itself claims Intended status: BCP.

   IMHO, we have been overtaken by events over the last six years; and
to publish a BCP on this topic today would require considerable review
and discussion. I am willing to participate in such review; but I am
doubtful we will see quick progress with the current authors. :^(

   I suggest instead publishing pretty much as-is with intended status:
Informational. Surely the effort which has gone into it so far justifies
a WG Informational RFC. (I'd be happiest with an added note of the
expected work in AQM; but I certainly won't insist on that.)

   I do encourage everyone interested in this to attend the AQM BoF at
1700 on Tuesday, July 30th.

   (As a brief suggestion of issues deserving our work to publish this
as a BCP today, I'll mention:
- whether we are attempting to estimate time-on-the-wire when we count
  bytes and/or packets;
- what AQM has come to mean over the last few years; and
- how byte and/or packet counting will interact with time-in-queue AQM.)