Re: [conex] TCP mods: Intro

Nandita Dukkipati <nanditad@google.com> Thu, 23 October 2014 23:24 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 E48401A6EFB for <conex@ietfa.amsl.com>; Thu, 23 Oct 2014 16:24:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.828
X-Spam-Level:
X-Spam-Status: No, score=-0.828 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, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, 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 IV29vk1HZxu7 for <conex@ietfa.amsl.com>; Thu, 23 Oct 2014 16:24:41 -0700 (PDT)
Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 139471A1BC0 for <conex@ietf.org>; Thu, 23 Oct 2014 16:24:41 -0700 (PDT)
Received: by mail-yh0-f44.google.com with SMTP id i57so1226055yha.3 for <conex@ietf.org>; Thu, 23 Oct 2014 16:24:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Kg2u1m2DLBu9JwKn5zdq/CBZ8X6BBmp0w77gquUt4aI=; b=SX6MCOS/yVWmYr5b/qz7cQQLSMJn5Xw5qDtCXEMflaQQkLJE1mwl3ww6EGwOnHw3aW r02smWw0zMUwQjWBgfjaIQ8SfpGdfYg3osNxC3r9NPF5R11KiDBLOcGRZTCnXb+E2UN7 PPiJtYsiF3S2wsS8UIWBwVDOrgH6BI0pgt/tdwc4tnF1IMP5VHpn/m19WHbqFtetmxL0 lSWZeD8GmAidR8u6mMGB9WizOtBb3hEr5/Cdha9NR8+gE1Zoa1hfwpwwDguO3X9rTBZ3 2n3a4Hamqf24Apcd/TWwX3snBzPmClo21glTb4al38HEWnULStUH62B8khvdzFFbjZIG IZ0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Kg2u1m2DLBu9JwKn5zdq/CBZ8X6BBmp0w77gquUt4aI=; b=ZkksoZDaik/jm67saNoACT7gYsvHguWPYVUBFo+4YZmEg4yqO63WktUBc5sWxvdxU3 76J6MUGFY0LtHRK+ExLIlaOodBTI8AcLB6+zU4pJtC2+F9tYp21Qg+n/VucYlAKUnZwQ 542KmiTEuzp7RsUHgYZU40CwpmeI3+3osP8GbgzkJu3hj/NI30A4jbWqE0yGM46goOAp 6hT9ejMbVz2bbzCD2sUZjaoODgqfljKUNYO/FZHWQ196dDN8f2EJjyLzJKTzlYSR3jI/ 83cjifIODbrACn736a/oAopy//UsQOXEpr7X6+GAR/A1toLU3Org6eRCHGqA+HssScM6 PSrA==
X-Gm-Message-State: ALoCoQlusUanl76NK1bm4Sy8S0U8WRPIs60UIrhHO79il+yqpafOPndCIiILRQzZGEbYTkxUgS5L
MIME-Version: 1.0
X-Received: by 10.170.189.216 with SMTP id g207mr623548yke.45.1414106680221; Thu, 23 Oct 2014 16:24:40 -0700 (PDT)
Received: by 10.182.248.161 with HTTP; Thu, 23 Oct 2014 16:24:39 -0700 (PDT)
In-Reply-To: <54253A22.2050904@tik.ee.ethz.ch>
References: <54253A22.2050904@tik.ee.ethz.ch>
Date: Thu, 23 Oct 2014 16:24:39 -0700
Message-ID: <CAB_+Fg7qxpy+41RhvTxHvNiR3kXAxJgo0oSFPHfBi6bu0197KQ@mail.gmail.com>
From: Nandita Dukkipati <nanditad@google.com>
To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>
Content-Type: multipart/alternative; boundary=001a1139817e59912905061f5eb1
Archived-At: http://mailarchive.ietf.org/arch/msg/conex/9ZlpX2weVc9Ebdqdeakm4ejRJeg
Cc: ConEx IETF list <conex@ietf.org>
Subject: Re: [conex] TCP mods: Intro
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: Thu, 23 Oct 2014 23:24:44 -0000

Mirja,

Here's the edited version of your text.

Inline are a couple of comments. Please pay particular attention to
describing what's going into each of the Sections. I found it confusing.

Nandita

1.  Introduction

Congestion Exposure (ConEx) is a mechanism by which senders inform the
network about the congestion encountered by previous packets on the same
flow.  ConEx concepts and use cases are explained in [RFC6789]. Abstract
ConEx mechanism is explained in [draft-ietf-conex-abstract-mech].  This
document describes the necessary modifications to use ConEx with the
Transmission Control Protocol (TCP).

ConEx marking is defined as a destination option for IPv6
[draft-ietf-conex-destopt].
Specifically, the use of four bits are defined: X (ConEx-capable), the L
(loss experienced), the E (ECN experienced) and C (credit) bit.

ConEx signal is based on loss or Explicit Congestion Notification (ECN)
marks [RFC3168] as a congestion indication.  This congestion information is
retrieved by the sender based on existing feedback mechanisms from the
receiver to the sender in TCP.  No changes are needed at the receiver to
implement ConEx signaling. Therefore no additional negotiation is needed to
implement and use ConEx at the sender.  This document specifies actions
needed by a sender to provide meaningful ConEx information to the network.

<Let the above be the main Intro. Put Section specific information below.>

Section 2 explains ...
 Further this document describes congestion accounting for TCP, both with
and without the Selective Acknowledgment (SACK) extension [RFC2018] in
Section 3.1.  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.  The detailed mechanism to
respectively set the L bit in response to loss-based congestion feedback
signal is given in Section 4.1.

<what happens between the jump from Section 3.1 to Section 4.1, or should
it just be Section 3 and Section 4? Is Section 3 about congestion
accounting w/o SACK and section 4 about congestion accounting with SACK.
Please clarify and rewrite.>

While loss-based congestion feedback should be minimized, ECN could actually
provide more fine-grained feedback information.  ConEx-based traffic
measurement or management mechanisms would benefit from this. Unfortunately,
the current ECN feedback mechanism does not reflect multiple congestion
markings which occur within the same Round-Trip Time (RTT).  A more
accurate feedback extension to ECN is defined in a separate document
[draft-kuehlewind-tcpm-accurate-ecn], as this is also useful for other
mechanisms.

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

<and now I am totally confused :( about the sections: so Section 4.1
describes the response to both loss and ECN?>

------------------------------------------------------------------------------------------------------------

On Fri, Sep 26, 2014 at 3:04 AM, Mirja Kühlewind <
mirja.kuehlewind@tik.ee.ethz.ch> wrote:

> Hi Nandita, hi all,
>
> find below the current version of the intro. Sorry for the delay; this
> week was a little busy...
>
> I applied the following changes:
>
> - Paragraph on CDO move back to intro (from section 4)
>
> - Added paragraph explaining that no receiver side changes are needed
>
> - Now introducing loss first
>
> - Added some sentences and the last paragraph to further explain the
> structure of the doc
>
>
> Mirja
>
> -------------------------------------------------------------
> 1.  Introduction
>
>    Congestion Exposure (ConEx) is a mechanism by which senders inform
>    the network about the congestion encountered by previous packets on
>    the same flow.  ConEx concepts and use cases are further explained in
>    [RFC6789].  The abstract ConEx mechanism is explained in
>    [draft-ietf-conex-abstract-mech].  This document describes the
>    necessary modifications to use ConEx with the Transmission Control
>    Protocol (TCP).
>
>    ConEx is defined as a destination option for IPv6
>    [draft-ietf-conex-destopt].  The use of four bits have been defined,
>    namely the X (ConEx-capable), the L (loss experienced), the E (ECN
>    experienced) and C (credit) bit.
>
>    Therefore the ConEx signal is based on loss or Explicit Congestion
>    Notification (ECN) marks [RFC3168] as a congestion indication.  This
>    congestion information is retrieved by the sender based on existing
>    feedback mechanisms from the receiver to the sender in TCP.  No
>    changes are needed at the receiver to implement ConEx signaling.
>    Therefore no additional negotiation is needed to implement and use
>    ConEx at the sender.  This document specifies actions needed by
>    sender to provide meaningful ConEx information to the network in
>    section Section 2.
>
>    Further this document describes congestion accounting for both TCP
>    with and without the Selective Acknowledgment (SACK) extension
>    [RFC2018] in section Section 3.1.  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.  The detailed mechanism to respectively set the L bit
>    in response to loss-based congestion feedback signal is given in
>    section Section 4.1.
>
>    While loss-based congestion feedback should be minimized, ECN could
>    actually provide more fine-grained feedback information.  ConEx-based
>    traffic measurement or management mechanisms would benefit from this.
>    Unfortunately, the current ECN feedback mechanism does not reflect
>    multiple congestion markings which occur within the same Round-Trip
>    Time (RTT).  A more accurate feedback extension to ECN is defined in
>    a separate document [draft-kuehlewind-tcpm-accurate-ecn], as this is
>    also useful for other mechanisms.
>
>    The congestion accounting for both, with the classic ECN feedback as
>    well as a more accurate ECN feedback are explained in detail in
>    section Section 3.2 while the setting of the E bit in response to
>    ECN-based congestion feedback is again detailed in section
>    Section 4.1.
>