From nobody Sun Mar  8 08:42:28 2015
Return-Path: <bob.briscoe@bt.com>
X-Original-To: conex@ietfa.amsl.com
Delivered-To: conex@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E92FD1A19F2 for <conex@ietfa.amsl.com>; Sun,  8 Mar 2015 08:42:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.411
X-Spam-Level: 
X-Spam-Status: No, score=-0.411 tagged_above=-999 required=5 tests=[MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJcHMiy8ExeE for <conex@ietfa.amsl.com>; Sun,  8 Mar 2015 08:42:24 -0700 (PDT)
Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82E6A1A19F8 for <conex@ietf.org>; Sun,  8 Mar 2015 08:42:24 -0700 (PDT)
Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.348.2; Sun, 8 Mar 2015 15:42:18 +0000
Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.348.2; Sun, 8 Mar 2015 15:42:21 +0000
Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Sun, 8 Mar 2015 15:42:21 +0000
Received: from BTP075694.jungle.bt.co.uk ([10.111.32.142])	by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id t28FgI1v005117; Sun, 8 Mar 2015 15:42:18 GMT
Message-ID: <201503081542.t28FgI1v005117@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Sun, 8 Mar 2015 15:42:18 +0000
To: Mirja =?iso-8859-1?Q?K=C3=BChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>, Richard Scheffenegger <rs@netapp.com>
From: Bob Briscoe <bob.briscoe@bt.com>
In-Reply-To: <7.1.0.9.2.20150307100706.0cdf6e48@bt.com>
References: <54D11DA4.9000402@tik.ee.ethz.ch> <7.1.0.9.2.20150307100706.0cdf6e48@bt.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
Archived-At: <http://mailarchive.ietf.org/arch/msg/conex/WM2itHMOfNCWAwkFq3eCT6s5jEo>
Cc: ConEx IETF list <conex@ietf.org>
Subject: Re: [conex] Friendly Reminder: ConEx TCP mods
X-BeenThere: conex@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Congestion Exposure working group discussion list <conex.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/conex>, <mailto:conex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/conex/>
List-Post: <mailto:conex@ietf.org>
List-Help: <mailto:conex-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/conex>, <mailto:conex-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Mar 2015 15:42:27 -0000

Mirja, Richard,

I've written my review comments into the XML.=20
Sorry I didn't get this done earlier.

.xml .txt and a diff from draft-07 are here:
<http://bobbriscoe.net/projects/conex/draft-ietf-conex-tcp-modifications-07-=
bb.xml>
<http://bobbriscoe.net/projects/conex/draft-ietf-conex-tcp-modifications-07-=
bb.txt>
<http://bobbriscoe.net/projects/conex/draft-ietf-conex-tcp-modifications-07-=
DIFF-07-bb.html>


* I've put all the editorial suggestions (mostly=20
english grammar) directly into the XML.
* I've made some changes I thought would be=20
non-controversial directly in the text.
   Some involve moving paragraphs into sections that seemed more relevant.
* I've added comments as <cref> elements within the XML.
   These appear as footnotes, which you can turn off with <?rfc=
 comments=3D"no"?>

Feel free to reject any changes you don't like.

My overarching suggestion is that, if you want to=20
keep any algorithm that adds incremental=20
precision, put it in an appendix. Then the base=20
document will be really simple.

I've added all my most significant concerns in my=20
<cref> comments, rather than changing the text. I've summarised them here:

1) ConEx Loss marking: Just mark retransmissions. Simple.
    Rationale: TCP never retransmits less data than is lost.
    Any attempt to identify lost bytes more=20
accurately or with less delay than the universe=20
of TCP researchers and developers over the last=20
two decades seems rather obsessive-compulsive.
    I know this seems harsh, but... if you want=20
to keep the algo you've written, pls shift it to=20
an appendix. But I would strongly urge removal.

2) The text in destopt says that the X flag will=20
only be turned off "...if no congestion feedback=20
is (currently) available e.g. in TCP if one=20
endpoint has been receiving data but sending=20
nothing but pure ACKs (no user data) for some time."
    draft-07 still says X is turned off if the=20
packet in question has no payload, which I thought we agreed was wrong.

3) I've added a para saying that experimentation=20
in credit algorithms is encouraged, and the ones=20
given are mainly to be concrete.
    Nonetheless, I think the ones given need to=20
be stated as absolute worst-case. They allow for=20
the /absolute/ worst case, rather than the=20
/likely/ worst case. E.g. the worst case during=20
congestion avoidance is taken as "all packets in=20
flight might suddenly be dropped".
    I know you're trying to say something=20
concrete, so I suggest we keep these suggestions=20
but make it clear that they cover the absolute worst-case.

4) The suggested test to detect a re-route onto=20
an audit function with no flow state (i.e. at=20
least a loss in two consecutive RTTs) is surely far too over-sensitive.
    Actually, I think no specific detection of=20
this event is needed. I believe an audit function=20
would drop a significant proportion of packets,=20
but in the next round the normal rules you've=20
specified will cause the sender to replenish the=20
credit while responding to these losses. Perhaps I'm wrong though.

5) IMO, resetting negative balance after one RTT=20
ought to be a MAY, not a SHOULD. I think we=20
should care more about simplicity than precision.

I also added some security considerations text=20
you might want to use (and I suggested moving the=20
existing para under security considerations to=20
Classic ECN Support, because it was about=20
protocol safety during heavy congestion, not security against attackers).


Bob

At 10:08 07/03/2015, Bob Briscoe wrote:
>Mirja,
>
>Starting this now...
>
>Sorry I've delayed it until just before the IETF=20
>deadline - BT and European project guff has just taken over my life since=
 xmas.
>
>
>Bob
>
>At 19:12 03/02/2015, Mirja K=C3=BChlewind wrote:
>>Hi Bob!
>>
>>Can you please, please do the ConEx TCP mods review...? Please!
>>
>>Thanks,
>>Mirja
>
>________________________________________________________________
>Bob Briscoe,                                                  BT

________________________________________________________________
Bob Briscoe,                                                  BT=20