[conex] TCP mods: Intro
Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> Fri, 26 September 2014 10:04 UTC
Return-Path: <mirja.kuehlewind@tik.ee.ethz.ch>
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 AD2CC1A1AC7 for <conex@ietfa.amsl.com>; Fri, 26 Sep 2014 03:04:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.686
X-Spam-Level:
X-Spam-Status: No, score=-4.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] 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 aCs7S24MRUCJ for <conex@ietfa.amsl.com>; Fri, 26 Sep 2014 03:04:21 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FD0F1A1ABF for <conex@ietf.org>; Fri, 26 Sep 2014 03:04:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 83B8CD9305; Fri, 26 Sep 2014 12:04:19 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id v3HybJHLIhjG; Fri, 26 Sep 2014 12:04:19 +0200 (MEST)
Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 35F9CD9302; Fri, 26 Sep 2014 12:04:19 +0200 (MEST)
Message-ID: <54253A22.2050904@tik.ee.ethz.ch>
Date: Fri, 26 Sep 2014 12:04:18 +0200
From: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: ConEx IETF list <conex@ietf.org>, Nandita Dukkipati <nanditad@google.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/conex/t9iuX5oal64Nd7ig4IRYoK5c9qA
Subject: [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: Fri, 26 Sep 2014 10:04:23 -0000
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.
- [conex] TCP mods: Intro Mirja Kühlewind
- Re: [conex] TCP mods: Intro Nandita Dukkipati
- Re: [conex] TCP mods: Intro Mirja Kühlewind
- Re: [conex] TCP mods: Intro Nandita Dukkipati
- Re: [conex] TCP mods: Intro Mirja Kühlewind
- Re: [conex] TCP mods: Intro Nandita Dukkipati