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

From: Michael Welzl <[email-masked]>
Date: Wed, 8 Jun 2016 09:48:48 +0200

Dear John,

Thank you very much for taking the time to read and comment on this, and very sorry for my long delay in getting back to you. Busy days...
More below; in my answers, I try to focus on comments that concern the current draft:

> On 01 Jun 2016, at 03:51, John Leslie <[email-masked]> wrote:
> 
> Michael Welzl <[email-masked]> wrote:
>> On 31. mai 2016, at 22.34, John Leslie <[email-masked]> wrote:
>>> Michael Welzl <[email-masked]> wrote:
>>> 
>>>> 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).
>> 
>> Sorry - I did, but only in the corresponding email that went to TSVWG only.
>> => TSVWG is the place for that.
> 
>   So, this email is going to TSVWG...
>> 
>>> Thus, I would prefer that alternativebackoff-ecn not limit us to the
>>> scheme in ecn-response.
>> 
>> 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".

RFC3168 has some text that isn't specific to TCP and just talks about "congestion control algorithms followed at the end systems".
This text doesn't specify how the information about a CE-mark is reflected from the receiver to the sender, because it can't - e.g. the text probably applies to QUIC just as well as TCP.

Then, it has a TCP-specific section, in which it describes how TCP reflects the CE-mark, and how a TCP sender responds to it.
We change both these text pieces in this draft.

You say you were confused by the early mention of "cwnd" and "ssthresh". I suggest to address this in the introduction by being explicit there about what I just wrote here - that there is a generic statement about the behavior of congestion controls, and a TCP-specific section in RFC3168, and we're changing both. Then, we can continue to talk about TCP as an example.

>   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.

This seems to be related to your confusion about how the ECE-mark "magically" gets back to the sender. I hope that I was able to clarify this enough here - this text necessarily leaves this open because it's not about TCP alone.

>   I must note that the eighth paragraph is much better -- except for
> having to guess where the end-quote is.

Okay, thanks for pointing this out: the last sentence (after the end quote) should be a paragraph on its own.

> 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.

Ok, we can probably remove this bit about the semantics. The point was to say the same as section 2.2 does.

>   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.

My short answer is that this surely isn't the point of the current draft.

>   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!)

IIUC this is about RFC3168, not our draft.

> ===============
> 
>   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.

I thought our draft does exactly that - with the difference that it still says MUST react / reduce the rate, but without the "as if a packet was lost" thing.

>   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.

This is not written in section 3.3 but in our RFC3168 text update (section 3.2), where we require a rate reduction by at least 15%.

> =================
> 
>   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...
> 
> --
> John Leslie <[email-masked]>

Cheers,
Michael