[conex] Feedback on draft-ietf-conex-tcp-modifications-05

Nandita Dukkipati <nanditad@google.com> Tue, 22 July 2014 06:29 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 3740E1A050E for <conex@ietfa.amsl.com>; Mon, 21 Jul 2014 23:29:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.48
X-Spam-Status: No, score=-0.48 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 4_xhT6eQf38E for <conex@ietfa.amsl.com>; Mon, 21 Jul 2014 23:29:07 -0700 (PDT)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F250B1A0366 for <conex@ietf.org>; Mon, 21 Jul 2014 23:29:06 -0700 (PDT)
Received: by mail-oi0-f48.google.com with SMTP id h136so4059481oig.7 for <conex@ietf.org>; Mon, 21 Jul 2014 23:29:06 -0700 (PDT)
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=vwGVI++iXdOHiy5tpDlDqGbuXydilSDS0KC51WGZdCE=; b=pJIVhqNDV6YrtBI5OGYqfL5Vl1sbYFv1iuRmQT0WfBVelDID2ZBviTTagAYZFqYtrx 9/mFauro1R30NJWk9j/eb4kB0jX28lNZuCL8Hla9G6RFM1Ze10WYQdB9w6AK3pdpbeLB 11+q1twyLR4u/beePY8ClmmjMCU7b/ihERyF0lc8lsPQcFyc++YNuqmRlAWrLE0JfVYn jWd6+AeuSWgfmZxgzmwWWbvCg0oETRJi811liKoL5sMc2vKLtXHRuTYSBdJgnbZP+mfM YNfvAWsFRjJJZQUJ8DAulCgJ+YC3DsEZOW+Jxeu63CPlO7sQpWSwBn79CBgLR/mQ9zir 4pXA==
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=vwGVI++iXdOHiy5tpDlDqGbuXydilSDS0KC51WGZdCE=; b=MtHVispyfHMroeEQPqN0v0erPnvGzKQopfVqz0jVVsdQFRKElnfyoJ1qghYmktlmHx G3L1eRcl5l0FMfUPfpmsf2lyn/ReZQM8wNqmsk5qbMpU+7vC8xXVOk1NrDJ+Ci33j7Qp Dsq3GPdnmfUyvRFek8vtPMdATh4w+CtNpq1O/tBolTsiidmPM8H/RP8OVD/tJYihP4Ea 527NxRpg6M0aRVxqZppdx47n3gaLQ2vEelwfregtRDEDh29/qpL+HWUZmkbdWgiaF7HF sAufS8ZcXq/5BTQARYugqgy/5ZGm2R3ji64uxa8NTlzrgqfFXvncAeBYAkAeMRMMjVkV PkMA==
X-Gm-Message-State: ALoCoQk2KEu17s910objcQ4mPQTrdR8UnN2+lM0pljyz3tcX09gv4Sepqqq3w0fQylVo8PX+bVu6
MIME-Version: 1.0
X-Received: by with SMTP id j2mr45871249oef.32.1406010546259; Mon, 21 Jul 2014 23:29:06 -0700 (PDT)
Received: by with HTTP; Mon, 21 Jul 2014 23:29:06 -0700 (PDT)
Date: Mon, 21 Jul 2014 23:29:06 -0700
Message-ID: <CAB_+Fg4Y1d6g0Lz7o_vo9b2uwh7YOo4h=LKBzEB=rXXPWVyKjA@mail.gmail.com>
From: Nandita Dukkipati <nanditad@google.com>
To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= <mirja.kuehlewind@ikr.uni-stuttgart.de>, "Scheffenegger, Richard" <rs@netapp.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/conex/yK6iGZyqSVVBerzF1SbM1GwYhBg
Cc: Jana Iyengar <janardhani@google.com>, "conex@ietf.org" <conex@ietf.org>
Subject: [conex] Feedback on draft-ietf-conex-tcp-modifications-05
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, 22 Jul 2014 06:29:08 -0000

(feedback as individual contributor)

No need to sugar coat: this draft needs lot more work. But happy to
help to shape it to its final form.


Table of Contents

* Section 2 is Sender side changes. I was looking for equivalent
Receiver side changes, but there's no section for that. Should there
be one?

* Section 3 My suggestion is to swap the ECN and loss detection
sections, because loss detection methods are implicit and can be used
today, while ECN requires... well ECN to be deployed.


* At the end of Introduction lay out the organization of the remainder
of the draft so a reader is informed of how the flow looks like.

* Need to set up the problem being addressed
Jumping to Section 2 on Sender side modifications felt abrupt. What's
missing is a setup of the problem that the draft is proposing TCP
changes for. Can we place this problem setup either in the Intro. or a
separate section in itself. An example of what might go into the
problem set up is: Algorithms for a ConEx sender to keep track of byte
wise congestion.

Section 2. Sender-side modifications

* "A ConEx sender MUST negotiate for both SACK and ECN.... Thus a
ConEx SHOULD also implement SACK and ECN".
The para appears incorrect to me. If you mandate a MUST for SACK/ECN
negotiation, then shouldn't there be a MUST also for implementing SACK
and ECN?

* Pseudo code.
Section 2 begs for pseudo code to succinctly describe the proposal.
Else the text is unnecessarily wordy.

* Section 2 ends abruptly. It sets up the problem and I was looking
for more details, but I guess they are punted to the other sections in
the draft.

Section 3. Accounting congestion

* "... ConEx marked either with the E bit or the L bit..."
AFAICT this is the first occurrence of E and L bits, and hence should
define them.

* Section 3 uses "outstanding bytes" often to describe the algorithms.
On immediate reading it was confusing, because in TCP implementations
outstanding bytes refers to the data that's been sent out but not
ACKed yet.

What you really mean by outstanding bytes here is a count of the
remaining bytes that are yet to be ConEx marked with either ECN or
loss bits. It's worthwhile having an explicitly and precisely efined
term here.

Section 3.1

* The algorithmic description of DeliveredData is laborious. Can you
see if you can simplify the description. Also take a look at [PRR RFC]
and see how DeliveredData is described there.

* Is Section 3.1 the best place to describe DeliveredData?
DeliveredData is trivial when there's no loss - it's just the number
of bytes acked. So clearly the value of DeliveredData is when there
are packet losses. So then shouldn't you be describing in the loss
sesction and using that definition in the ECN section.

This also goes back to an earlier comment I made that you should
consider swapping the two placement of these two sections, 3.1 and

* For ease of reading and simplicity, please split up the equation for
DeliveredData into the SACK and non-SACK case.

Section 3.1.2 Classic ECN support

* ".... it will receive one full RTT of delayed ACKs with the ..."
I don't remember exactly, but some implementations may disable delayed
ACKs on receiving a CE mark. What's the significance of mentioning
delayed ACKs here?

* Why not recommend (SHOULD?) to turn off delayed ACKs when rceiving
CE marks. May be this belongs to another draft and not here?

* The description of the more sophisticated heuristic to extract
congestion notification at the end of Section 3.1.2 sounds half
hearted to me. My suggestion: either describe it nicely and clearly
with pseudo code etc., or give a high level idea here and ditch the
details to an Appendix. At least that way the flow of the draft is

Section 3.2 Loss Detection

* Do retransmitted packets carry ConEx L bit or just the original data
segments? Whatever the answer is, why?

Section 3.2.1 Without SACK Support

* Isn't this the right place to discuss DeliveredData w/o SACK support?

Section 3.2.1 Without SACK support

* General comment that's not sepcific to this section: LEC and LEG are
very close in naming, but mean different things. Can we coose better

* Is there any implicit relation between LEC and LEG counters? Seems
like there is, otherwise why do you say that LEG shoul be increased by

* It seems to me that you have a nice algorithm here, but sorry you
totally lost me. My only suggestion would be to try and put the algo
in a nice pseudo code.

Section 4

* A lot of what appears in this section seems like should be in the
sendder side changes.

Section 4.1

* What's the reasoning behind: "If the CEG or LEG counter is negative,
the respective counter SHOULD be reset to sero within one RTT after it
was decreased..."

Section 4.2

* Please clarify the relation between credit counter and the previous
counters LEG/LEC? Are they independent?

* Could you expand more on how you arrived at: every fourth packet
will allow teh respective number of credits in Slow Start..." I can
see how it works. Is there a formulae connecting the Slow Start
exponent and the the nth packet that needs to be marked?

* Mention how credits should be replenished in congestion avoidance phase.

Section 6 Timeliness of the ConEx Signals

* You discuss the event when receiving both ECN and loss signals. But
how should the sender respond? Send ConEx signals for summation of
both ECN/loss (I would think not) or choose the max?

Editorial changes

I have tons of editorial changes marked all over the draft - too many
to spend time to cut+paste in this email. I'll just scan the sheets
and send them to you.