Subject: Re: [tsvwg] [tcpm] Fwd: New Version Notification for draft-khademi-tcpm-alternativebackoff-ecn-00.txt

From: John Leslie <[email-masked]>
Date: Tue, 31 May 2016 16:34:36 -0400

Michael Welzl <[email-masked]> wrote:
> 
> Following my presentation to, and the related discussion in TSVWG in BA:
> https://www.ietf.org/proceedings/95/slides/slides-95-tsvwg-13.pdf
> we have split the ABE draft ( draft-khademi-alternativebackoff-ecn )
> into two documents:
> 
> 1) a document that only makes the necessary update to RFC3168 to allow a
> reaction to ECN that differs from the reaction to loss:
> This is draft-khademi-tsvwg-ecn-response, which I just posted.

   Three cheers!!!

> 2) a document that only contains the concrete change to TCP that we
> suggest (the new multiplication factor):
> This is draft-khademi-tcpm-alternativebackoff-ecn, with details below.
> 
> Please read and discuss item 2 here in TCPM - thanks!!   :)

   You don't specify where to discuss item 1).

   IMHO, the actual reduction of sending-rate _must_ be Experimental
(as it is); this implies that some other mechanism _might_ prove better.

   Thus, I would prefer that alternativebackoff-ecn not limit us to the
scheme in ecn-response.

   There are various ways to manage this: I won't advocate strongly for
any particular one yet (but I can certainly propose one or two if somebody
questions whether it is "possible" to separate these).

__
John Leslie <[email-masked]>

---

From: Michael Welzl <[email-masked]>
Date: Wed, 1 Jun 2016 00:01:12 +0200

> On 31. mai 2016, at 22.34, John Leslie <[email-masked]> wrote:
> 

Sorry - I did, but only in the corresponding email that went to TSVWG only.
=> TSVWG is the place for that.

>   Thus, I would prefer that alternativebackoff-ecn not limit us to the

You mean the other way round, right?  If so, then that’s how it is - draft-khademi-tsvwg-ecn-response just mentions draft-khademi-tcpm-alternativebackoff-ecn as one example.

> questions whether it is "possible" to separate these).

I’m not sure I get what you mean but I believe this is probably already in line with what you wish…

Cheers,
Michael

---

From: John Leslie <[email-masked]>
Date: Tue, 31 May 2016 21:51:45 -0400

> => TSVWG is the place for that.

   So, this email is going to TSVWG...
> You mean the other way round, right?

   I'll take your word for it. (The interconnection of documents between
two WGs is enough to confuse me when I'm trying to get out the door to a
dinner meeting!)

> If so, then that???s how it is - draft-khademi-tsvwg-ecn-response just
> mentions draft-khademi-tcpm-alternativebackoff-ecn as one example.

   I was pretty thoroghly confused when reading ecn-response too quickly.

   There's an inherent problem talking about ECN: it involves router
action on the internetworking layer (IP) and sender action on the
transport layer (e.g. TCP). Reading Section 1, it's hard to separate
what RFCs 3168 and 5681 say from what we will propose.

   In particular, I question whether the "congestion window" is an
appropriate concept for the internetworking layer. Routers (or other
"forwarders") simply mark congestion experienced within the two bits
allocated to ECN in the IP header. It can only confuse folks to
couple this with what the sender will do when it receives notice of
the congestion marking.

   I understand this pretty well (IMHO); but _I_ was confused. "cwnd"
and "ssthresh" are internal details of the TCP treatment of congestion
marking, and we _do_ have to specify _that_ we are changing these; but
mentioning them in Section 1, but not explaining the changes until
Section 3, is unnecessarily confusing.

   When I got to Section 3, I was running out of time. :^(

   The actual 3168 text in Section 3.2 has _always_ been problemmatic.
The concept of "ECN-Capable transport" is poorly defined; bordering
on PFM "pure f-ing magic" of how the sender is supposed to "receive
a CE-marked packet".

   I don't think it's a good idea to try to minimize the text changes
to RFC 3168. So, IMHO, the fourth paragraph of Section 3.2 is not
helpful.

   I must note that the eighth paragraph is much better -- except for
having to guess where the end-quote is. However "the semantics defined
in [RFC3168]" seems less than helpful. It's hard to find exactly what
3168 text is being referenced here: most, at least, require exact
duplication of the reaction to loss.

   BTW, "should be treated just as a congestion loss" isn't even
possible IMHO; and we really-should simply excise every occurance
of this text from 3168-as-modified.

   As I read Section 3.2 quickly, I assumed it intended to specify
that "the TCP source halves the congestion window 'cwnd' and reduces
the slow start threshhold 'ssthresh' " -- subject only to substituting
some other fraction for "halves".

   (I'm not sure the more-careful reading I'm doing now actually
changes this!)

===============

   I could continue this, but most readers would die of boredom...

===============

   What I actually wanted to see was a clear statement that ecn-response
was revising 3168 by removing the "MUST" requirement for these algorithms
when the congestion is marked by the ECN CE instead of packet loss; and
that _an_ experiment is being separately proposed by alternativebackoff-ecn
to experiment with a different reaction by the sender.

   There's still a lot of hand-waving (however we phrase ecn-response)
about how to tell whether an experiment is working and is safe to deploy
on the big-I Internet. I'm happy to work on that; but it doesn't belong
in this email. Section 3.3 pretty much says that; but the description
of what limits there may be to experiments is missing. IMHO, it's a
bad idea to let each experiment change anything it pleases -- there
should be limits in ecn-response to what is permissible to change.

=================

   There's yet another issue: how observers of these experiments can
know what they're observing. I _really_don't_ want to discuss that in
this email...

--