Re: [conex] Review of draft-ietf-conex-tcp-modifications-02

Mirja Kuehlewind <> Mon, 03 June 2013 12:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 958B021F96ED for <>; Mon, 3 Jun 2013 05:59:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.76
X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DE=0.35]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iwunWza20Lpw for <>; Mon, 3 Jun 2013 05:59:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CDEF821F965A for <>; Mon, 3 Jun 2013 05:59:32 -0700 (PDT)
Received: from (netsrv1-c []) by (Postfix) with ESMTP id E5D8B601C9; Mon, 3 Jun 2013 14:59:30 +0200 (CEST)
Received: from vpn-2-cl195 (vpn-2-cl195 []) by (Postfix) with ESMTP id DEDB7601C8; Mon, 3 Jun 2013 14:59:30 +0200 (CEST)
From: Mirja Kuehlewind <>
Organization: University of Stuttgart (Germany), IKR
Date: Mon, 03 Jun 2013 14:59:30 +0200
User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316)
References: <>
In-Reply-To: <>
X-KMail-QuotePrefix: >
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <>
Subject: Re: [conex] Review of draft-ietf-conex-tcp-modifications-02
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Congestion Exposure working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 03 Jun 2013 12:59:37 -0000

Hi Jana,

thank you for your feedback. We just uploaded a new version for addressing 
quickly the last two ToDo:

1. Sending Credits
   -> A ConEx sender should maintain flightsize number of packets as credits 
	(in CA)
2. Loss of ConEx infos
   -> A ConEx sender should detect this case and send further credits

But there are actually still some open questions mainly regarding the credits:

1) What's the right reaction if ConEx markings get lost?
2) How to detect false positives of the audit at the sender?
3) How to incentives a sender to send right markings at the right time (e.g. 
to not send credits instead of L/E markings)?

I'm going to send separate emails now to further explain these points and 
hopefully discuss these questions on the list.


On Friday 31 May 2013 19:55:06 Janardhan Iyengar wrote:
> Mirja, Richard, all
> A bit late, I'm sending along my review
> of draft-ietf-conex-tcp-modifications-02. I noticed that -03 came along
> while I was reading the -02 version; I'm also happy to review later
> versions.
> Overall, the text could use some tightening up. Some text may need to be
> rewritten (I've suggested some below), and some could be eliminated
> altogether. My major feedback at this time would be that the draft should
> focus on mechanisms that are clear and are to be specified (such as LEG and
> CEG counts, for example). Other mechanisms that are either nascent or are
> not yet fully specified ought to be left out from this document (such as
> the more accurate ECN marking). More specific details follow.
> 1. Introduction:
> - "ConEx is a ...": cite RFC 6789. For someone who hits this draft, it is
> not clear where to go to find more about ConEx itself.
> - End paragraph after "use ConEx with the Transmission Control Protocol
> (TCP)."
> - Suggested restructuring:
>   + Move last paragraph "ConEx is currently/will be defined as an
> destination option for IPv6..." up here to the beginning of the second
> paragraph.
>   + Continue paragraph with "The ConEx signal is based on loss or ECN marks
> ..."
>   + Modify "loss or ECN marks" in the above sentence to "Explicit
> Congestion Notification (ECN) marks".
> - Suggested rewording for paragraph "With standard TCP ...":
> "This document describes mechanisms for TCP both with and without the
> Selective Acknowledgment (SACK) extension [RFC2018]. However, ConEx
> benefits from more accurate information about the number of packets dropped
> in the network. We therefore recommend using the SACK extension when using
> TCP with ConEx."
> - Modify: "Explicit Congestion Notification (ECN) is defined in such a way
> ..." to "ECN is defined in such a way ..."
> - This paragraph about more information than ECN seems unnecessarily
> detailed. One sentence ought to be enough. Something like: "In addition to
> standard ECN and SACK feedback, an extension described in [
> draft-kuehlewind-conex-accurate-ecn] shows how more accurate ECN feedback,
> especially useful in the case of multiple markings within the same
> roundtrip time (RTT),  can be obtained."
> 2: Sender-side Modifications:
> - "MUST negotiate for both SACK and ECN or the more accurate ECN feedback
> ..." : This strikes me as an odd MUST. SHOULD seems adequate.
> - Using "SACK-accECN-Conex" instead of "Full-Conex" seems better
> descriptive.
> - "A ConEx sender MUST expose congestion to the network...": A compliant
> Conex sender has to follow a Conex spec for exposing congestion; that can
> be assumed here, without having a MUST in this document. Perhaps cite the
> v6 options draft here without specifying here what a Conex sender MUST do.
> - "A TCP sender SHOULD account congestion byte-wise (and not packet-wise)":
> Cite draft-ietf-tsvwg-byte-pkt-congest or justify otherwise.
> - "As network congestion is usually byte-congestion ...": Is this really
> the case? Cite.
> 3: Accounting Congestion:
> - The writing in this section can be cleaned up. For instance, "... is
> explained in the next section." should specify the section number.
> - "A TCP sender SHOULD account congestion byte-wise (and not packet-wise)
> ...": Cite draft-ietf-tsvwg-byte-pkt-congest.
> - "The subtraction of bytes which have been ConEx marked from both counters
> is explained in the next section.": What does "subtraction of bytes" mean?
> - "If equal sized packets ...": This sentence needs to be rewritten.
> Difficult to read and follow.
> - "If a sender sends different sized packets ...": difficult to follow as
> well. I understand what it says, but it needs to be rewritten to be clear.
> - "ECN is an IP/TCP mechanism ...": cite RFC3168.
> - "A receiver can support the accurate ECN feedback scheme ...": cite. It
> may be better to structure
> - "Note the change in in the SACK information can also be negative if the
> number of acknowledged bytes increases.": Not clear. Do you mean to say if
> the number of acked bytes decreases?
> - What are the variables is_after_dup and num_dup in the DeliveredData
> expression? Please describe them before the equation or immediately after.
> 3.1.2: Classic ECN Support:
> - It is non-trivial for a sender to determine when delayed acks will be
> sent by the receiver, in particular with bidirectional data transfer. I
> would be careful about suggesting such heuristics without getting into
> details. Is this "Advanced Compatibility" really practical or necessary?
> 3.2: Loss detection with/without SACK:
> - "assuming equal sized segments such that the retransmitted packet will
> have the same number of header as the original ones." You cannot make this
> assumption. There are commonly used stacks that will retransmit differently
> sized segments, and even combine retransmitted bytes with new bytes within
> a segment. This assumption is not critical, and so I would suggest dropping
> it from the text.
> - jana

Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973