[conex] Comments on WGLC for draft-ietf-conex-tcp-modifications-06

Nandita Dukkipati <nanditad@google.com> Tue, 25 November 2014 06:17 UTC

Return-Path: <nanditad@google.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 8BC2F1A6F21 for <conex@ietfa.amsl.com>; Mon, 24 Nov 2014 22:17:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.311
X-Spam-Level:
X-Spam-Status: No, score=0.311 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 pHw2sNsWwmzD for <conex@ietfa.amsl.com>; Mon, 24 Nov 2014 22:17:40 -0800 (PST)
Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35DFF1A1B94 for <conex@ietf.org>; Mon, 24 Nov 2014 22:17:40 -0800 (PST)
Received: by mail-qg0-f52.google.com with SMTP id a108so8002230qge.11 for <conex@ietf.org>; Mon, 24 Nov 2014 22:17:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=6ngAIszkyDvaj4E65K+YpF38E3tGbwhE0kNIQW8UrTs=; b=G+4N//H9rI/i5ZP8vjyWs/wF2ttO5KPmsE5f+Desnsx7n40a3kRkxL8aywF0sqUiNN whp408n/MuXLjrxS6wz0VqICSTxVYS71Q6/Dsrf3KQyktRQYrsFWsQRRvDlD89JPLkmv x0iqAo7+IMW+4oNlKBixiKMbf7GZN8f/5DM/9vMi9mHP7FPrzzLiEFjLCLHkhq+0xh0I 5fYKo93qdCMD0LbfhCnOzdCaKM03RTkAvCbyeG/h3Map1Id/SeR2RUkJS7GXAaS3Ug5A yZis9MOUG7FIJIAm0xdgxSIYWCJZ3IZUORn6Q2B1GCceEVX5eB793p1knfYqzRDk6hhr i0dg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=6ngAIszkyDvaj4E65K+YpF38E3tGbwhE0kNIQW8UrTs=; b=R4Iee8OvCK7vfNuuhLYMcsFiYgpAulVu8ghm+jrUlVrCocsigjKW3XGuSRcO7FWYOI WFdtnnvdSDB6mdg/XOq+kAel/cLn/RSQERVfnzAh9skCOOKXF6Xc2Uge306pviafX+tl yNG0H1FsfCw00FePyXWvIMi8HT+n2eSjve94ItswPDpKX9Sv30qA9vYrs+f5fq9s0qLh NYun5BO+DcbnmPjuuQwzbDtmh2c4gaovs0y0pVRM8rXNrRjvzk0OUgwrxCPJs589kDxv 1srVO2vYeifowaI3TvMN02bTBAvuMP0nXPZS2IgU28KOgMctndBTZnJQDcZ3DlwgNTHK SCdA==
X-Gm-Message-State: ALoCoQlMXYGDtWpgsC9kaXjnDCa5y99hF8CKYbRHcq/N8ztg4RNHXhhRfo4OxbQD5Bo9HFg7hzh7
MIME-Version: 1.0
X-Received: by 10.229.40.71 with SMTP id j7mr34342480qce.21.1416896259412; Mon, 24 Nov 2014 22:17:39 -0800 (PST)
Received: by 10.229.183.201 with HTTP; Mon, 24 Nov 2014 22:17:39 -0800 (PST)
Date: Mon, 24 Nov 2014 22:17:39 -0800
Message-ID: <CAB_+Fg4OLA=+p59V9VLqmr1Bj1WiNKP2tbddf_cbtZKWwW+iRg@mail.gmail.com>
From: Nandita Dukkipati <nanditad@google.com>
To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>, "Scheffenegger, Richard" <rs@netapp.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/conex/ewVuEgVytEAx37F-Lx48nSFIwuc
Cc: "conex@ietf.org" <conex@ietf.org>
Subject: [conex] Comments on WGLC for draft-ietf-conex-tcp-modifications-06
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: Tue, 25 Nov 2014 06:17:41 -0000

Mirja and Richard,

Thanks! for the draft. Some comments below:

* Introduction

"First congestion information have to be extracted from loss or ECN
feedback in TCP as described in section 3"... ".
Remove the extra quotes.

*
"It is therefore recommend to use the SACK extension when using TCP with ConEx."
It is therefore recommended...

* " This document describes congestion accounting for both TCP with
and without the Selective Acknowledgment (SACK) extension [RFC2018] in
section 3.1.
...
The detailed mechanism to respectively set the L bit in response to
loss- based congestion feedback signal is given in section 4.1."

"The congestion accounting for both, with the classic ECN feedback as
well as a more accurate ECN feedback are explained in detail in
section 3.2 while the setting of the E bit in response to ECN-based
congestion feedback is again detailed in section 4.1."

This jumps around around describing Section 3.1 -> Section 4.1 ->
Section 3.2 -> and back to Section 4.1

Suggestion is to consolidate to keep all the Section 3 material by
itself and Section 4 material by itself.

Also the last three paragraphs of the Intro. seem disconnected with
the rest. The para starting with "Section 2 provides an overview of
the needed modifications for TCP senders to implement ConEx..."
already laid out the Section contents.

* Accounting Congestion
Reword the first sentence.

A ConEx sender maintains two counters: one that accounts congestion
byte-wise based on the congestion information received by loss
detection, and a second that accounts for ECN based congestion
feedback.

* 3.1.1 Without SACK Support

The last para of Section 3.1.1:

"At this point of time in the transmission, in the worst case, all
packets in flight minus three that trigged the dupACks could have been
lost.  For each retransmission that is sent, the LEG will still be
increased but the LEC will also be decreased by the payload size of
the retransmission.  During the following RTT, LEC should be reduced
by SMSS for each ACK that is received.  Thus after one RTT the LEC
estimates the number of outstanding bytes that should be ConEx L
marked.  To not further delay this information, now LEG should be
increased by LEC.  From then on every following retransmission should
only reduce the LEC and not increase the LEG until the LEC is zero, as
those bytes were already accounted."

Have you considered putting the above in a pseudo code:

On a retransmission:
    XXX

On receipt of ACK:
    XXX

* 5.  Loss of ConEx information
"Of course also packets..."
-> Packets carrying ConEx can also get lost.

6.  Timeliness of the ConEx Signals
nodewith -> node with
avoiad -> avoid