[tcpm] ECN fall-back: draft-kuehlewind-tcpm-ecn-fallback-01

Bob Briscoe <bob.briscoe@bt.com> Wed, 18 June 2014 12:32 UTC

Return-Path: <bob.briscoe@bt.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D60C1A01CC for <tcpm@ietfa.amsl.com>; Wed, 18 Jun 2014 05:32:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.252
X-Spam-Level:
X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 K5DvzxVJcwuJ for <tcpm@ietfa.amsl.com>; Wed, 18 Jun 2014 05:32:47 -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 1F23C1A0127 for <tcpm@ietf.org>; Wed, 18 Jun 2014 05:32:45 -0700 (PDT)
Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 18 Jun 2014 13:32:43 +0100
Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 18 Jun 2014 13:32:43 +0100
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; Wed, 18 Jun 2014 13:32:42 +0100
Received: from BTP075694.jungle.bt.co.uk ([10.215.130.93]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s5ICWfjN003732; Wed, 18 Jun 2014 13:32:41 +0100
Message-ID: <201406181232.s5ICWfjN003732@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 18 Jun 2014 13:15:58 +0100
To: Mirja KUEHLEWIND <mirja.kuehlewind@ikr.uni-stuttgart.de>, Brian Trammell <trammell@tik.ee.ethz.ch>
From: Bob Briscoe <bob.briscoe@bt.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/LJ0zUY75rVox7OAEXe6U5KliR10
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: [tcpm] ECN fall-back: draft-kuehlewind-tcpm-ecn-fallback-01
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Jun 2014 12:32:49 -0000

Mirja, Brian,

I had an idea to be able to test ECN in the initial window rather 
than after it:

Send the initial window with 4 extra CE pkts at the start with sizes 
as follows:

         start   size    IP-ECN
__________________________
A          1       1    CE
B          1       2    CE
C          1    1466    ECT0
D       1467       1    CE
E       1467    1465    ECT0
F       2932       1    CE
G       2932    1466    ECT0
etc.

This doesn't work for some unfortunate patterns of re-ordering. Aside 
from that,...
* If the CE packets get through, each one pushes forward the 
cumulative ack boundary, so it should elicit an ACK.
* Even if some box drops the CE pkts, the ECT0 packets overlap the CE 
packets, so there won't be any sequence gaps, so none of the incoming 
side of the slow-start code has to be changed to ignore losses.
* Some receiver implementations delay ACKs during slow start (BSD, 
Windows), so the CE packets are inserted every second segment so they 
should be the ones that trigger the ACKs.
* If the receiver delays ACKs for 2 full-sized segments (as per 
RFC5681), packet (F) is the first one that goes beyond that limit.
* Only 5 extra bytes of payload are sent.

If any of the CE ACKs do not feedback ECE, you know CE is getting re-written.
If all the CE ACKs do not cause an ACK, you know CE is getting dropped.


I've got some other niggles about the draft, but I'll send them separately.

Cheers


Bob


________________________________________________________________
Bob Briscoe,                                                  BT