IETF Logo Mail Archive

Re: [conex] draft-ietf-conex-destopt-01.txt

Mirja Kuehlewind <mirja.kuehlewind@ikr.uni-stuttgart.de> Wed, 09 November 2011 19:58 UTC

Return-Path: <mirja.kuehlewind@ikr.uni-stuttgart.de>
X-Original-To: conex@ietfa.amsl.com
Delivered-To: conex@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E1021F851A for <conex@ietfa.amsl.com>; Wed, 9 Nov 2011 11:58:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.161
X-Spam-Level:
X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12YJvr4QWZoG for <conex@ietfa.amsl.com>; Wed, 9 Nov 2011 11:58:31 -0800 (PST)
Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id D36D321F84CB for <conex@ietf.org>; Wed, 9 Nov 2011 11:58:30 -0800 (PST)
Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id EBB62633B1 for <conex@ietf.org>; Wed, 9 Nov 2011 20:58:28 +0100 (CET)
Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id CDF8459A8A for <conex@ietf.org>; Wed, 9 Nov 2011 20:58:28 +0100 (CET)
From: Mirja Kuehlewind <mirja.kuehlewind@ikr.uni-stuttgart.de>
Organization: University of Stuttgart (Germany), IKR
To: conex@ietf.org
Date: Wed, 09 Nov 2011 20:58:27 +0100
User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316)
References: <20111030141755.21962.83789.idtracker@ietfa.amsl.com> <20111107160135.GA45061@verdi> <201111091719.54931.mirja.kuehlewind@ikr.uni-stuttgart.de>
In-Reply-To: <201111091719.54931.mirja.kuehlewind@ikr.uni-stuttgart.de>
X-KMail-QuotePrefix: >
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <201111092058.28029.mirja.kuehlewind@ikr.uni-stuttgart.de>
Subject: Re: [conex] draft-ietf-conex-destopt-01.txt
X-BeenThere: conex@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 09 Nov 2011 19:58:31 -0000

Hi again,

I just want to quickly answer/rephrase my own question:

> Another good point is, if it is possible to have one half-connection
> ConEx-enable and the other not? Maybe it might make sense if e.g. use data
> only flow in one direction and the other direction which sends only pure
> ACKs is not ConEx-capable...? Don't no... further options here?

As ConEx requires only sender-side modifications, it is possible to one 
half-connection ConEx-enabled and the other direction not. But the question 
would be: Should a sender that is generally ConEx-capable not enable ConEx on 
a (half-)connection that does not send any use data (but e.g. just pure 
ACKs), as no congestion feedback is available for those packets...?

Mirja

v2.39.1 | Report a Bug | By Email | System Status