Re: [tcpm] draft-han-tsvwg-cc (was: Re: [tsvwg] Agenda requests for TSVWG@IETF101)
Toerless Eckert <tte@cs.fau.de> Mon, 12 March 2018 20:58 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6C1126DD9; Mon, 12 Mar 2018 13:58:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.96
X-Spam-Level:
X-Spam-Status: No, score=-3.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 A4EcbHgstUx5; Mon, 12 Mar 2018 13:58:22 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DDFE126CF9; Mon, 12 Mar 2018 13:58:22 -0700 (PDT)
Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 7D25358C505; Mon, 12 Mar 2018 21:58:18 +0100 (CET)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5DCFDB0DCE8; Mon, 12 Mar 2018 21:58:18 +0100 (CET)
Date: Mon, 12 Mar 2018 21:58:18 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Emmanuel Lochin <emmanuel.lochin@isae-supaero.fr>
Cc: tsvwg@ietf.org, tcpm@ietf.org
Message-ID: <20180312205818.GC25534@faui40p.informatik.uni-erlangen.de>
References: <A1F61D20-1911-4A6E-9F80-A1DF1EF91816@huawei.com> <419905ca-305b-594d-2958-fb468e6e5bb0@isae-supaero.fr> <CABY-gOPNbUsazRjbuuJOa+-XfiuMZ=5riO=g95aVbQ8qZ7k5uA@mail.gmail.com> <9ef0cc0b-7bbc-d266-2410-b03265b8c2a1@isae-supaero.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <9ef0cc0b-7bbc-d266-2410-b03265b8c2a1@isae-supaero.fr>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/MAXIJyGDT3qfK48PIlb8zv8cVeM>
Subject: Re: [tcpm] draft-han-tsvwg-cc (was: Re: [tsvwg] Agenda requests for TSVWG@IETF101)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2018 20:58:25 -0000
On Mon, Mar 05, 2018 at 10:16:19AM +0100, Emmanuel Lochin wrote: > What I remember (looking back IETF archives) is that Sally Floyd > answered she had no objection concerning the proposal if it was > clearly written that the gTFRC mechanism must be used only in the > context of a QoS network. And if history serves me right, that draft of yours was before the IETF figured out that there was and is a lot of traffic assuming bandwidth guaranteees without sufficient network guarantees provided - and ultimately, the concept of circuit breakers was born. I think for these mechanisms we're proposing one could equally refine their applicability to "badly QoS supported" networks by making them automatically fall back to standard congestion control (in our drafts case Reno without CIR). > Sally Floyd also asked questions related > to the algorithm and proposed enhancements about the slow-start > behavior of the mechanism. We answered that we fully agreed with > this hypothesis and justified the choice of our design concerning > the slow-start method. > Therefore, a second discussion started with Mark Allman on potential > security issues raised by this mechanism. Basically, Mark asked us > to add a part concerning the reaction to the congestion in the > guaranteed part (the ???g??? part) even if we are in a context of a > QoS network. We have discussed this point and following this emails > exchange, published a new version of the draft. Right, your -02 section 3.4.2. I told the authors of our draft that that was also a piece i felt is missing in our draft. See above - i would today rephrase it in terms of a "soft circuit breaker" - not breaking the flow at all, but just breaking the assumption of have a CIR. > We also talked about the best way to publish this proposal, it > seemed to be well-accepted to publish a new draft rather than > inserting this contribution inside the new TFRC draft (now RFC > 5348). As a result, we extended the gTFRC draft in order to detail a > complete protocol for QoS networks. > > Finally I left the laboratory I worked during the elaboration of > this draft in 2007 and I assume that this work has not been pursued. Right. > Considering your proposal, I reckon you'll be face to the same > questions in particular the one on the security issue. > But I'm quite > interesting in discussing this proposal on the mailing-list while > even doing something more generic about transport protocol > extensions for QoS networks. Great. Toerless > > EL > > > > > > >BTW, yes, AR/VR means Augmented Reality/Virtual Reality. I'll add > >the acronyms to the next version. > > > >Thanks, > >Yingzhen > > > > > >On Sun, Mar 4, 2018 at 3:45 AM, Emmanuel Lochin > ><emmanuel.lochin@isae-supaero.fr > ><mailto:emmanuel.lochin@isae-supaero.fr>> wrote: > > > > Hi Yingzhen > > > > Just for your information, you might be interested in gTFRC : > > https://tools.ietf.org/html/draft-lochin-ietf-tsvwg-gtfrc-02 > > <https://tools.ietf.org/html/draft-lochin-ietf-tsvwg-gtfrc-02> > > which is a similar solution i.e. a CC for bandwidth guaranteed > > networks with TFRC. > > Furthermore just a quick question : in your draft does AR/VR > > stands for Augmented/Real Virtuality ? > > > > Regards > > > > Emmanuel > > > > > > On 04/03/2018 06:54, Yingzhen Qu wrote: > >> > >> Dear Chairs, > >> > >> A new draft (The draft was suggested by TSVWG @IETF100) was just > >> submitted, and we???d like to request a time slot to present it > >> @IETF101. > >> > >> Title:A New Congestion Control in Bandwidth Guaranteed Network > >> > >> Presenter: Yingzhen Qu (Huawei) > >> > >> Time required (including Q/A): 10 mins > >> > >> Draft: https://datatracker.ietf.org/doc/draft-han-tsvwg-cc/ > >> <https://datatracker.ietf.org/doc/draft-han-tsvwg-cc/> > >> > >> If there is any question, please kindly let us know. > >> > >> Thanks, > >> > >> Yingzhen > >> > > > > -- Emmanuel LOCHIN > > Professeur ISAE > > > > ISAE SUPAERO - Institut Supérieur de l'Aéronautique et de l'Espace > > 10 avenue Edouard Belin > > <https://maps.google.com/?q=10+avenue+Edouard+Belin&entry=gmail&source=g> - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE -http://www.isae-supaero.fr > > Tel+33 5 61 33 84 85 <tel:+33%205%2061%2033%2084%2085> - Fax(+33) 5 61 33 83 30 <tel:+33%205%2061%2033%2083%2030> > > > > > > -- > Emmanuel LOCHIN > Professeur ISAE > ISAE SUPAERO - Institut Supérieur de l'Aéronautique et de l'Espace > 10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE - > http://www.isae-supaero.fr > Tel +33 5 61 33 84 85 - Fax (+33) 5 61 33 83 45 > Web : http://personnel.isae.fr/emmanuel-lochin/ >
- Re: [tcpm] Agenda requests for TSVWG@IETF101 Scharf, Michael (Nokia - DE/Stuttgart)
- Re: [tcpm] Agenda requests for TSVWG@IETF101 Gorry Fairhurst
- Re: [tcpm] [tsvwg] Agenda requests for TSVWG@IETF… Yingzhen Qu
- Re: [tcpm] [tsvwg] Agenda requests for TSVWG@IETF… Scharf, Michael (Nokia - DE/Stuttgart)
- [tcpm] draft-han-tsvwg-cc (was: Re: [tsvwg] Agend… Toerless Eckert
- Re: [tcpm] draft-han-tsvwg-cc (was: Re: [tsvwg] A… Toerless Eckert
- Re: [tcpm] [tsvwg] Agenda requests for TSVWG@IETF… Yingzhen Qu
- Re: [tcpm] [tsvwg] Agenda requests for TSVWG@IETF… Gorry Fairhurst
- Re: [tcpm] [tsvwg] Agenda requests for TSVWG@IETF… Michael Tuexen
- Re: [tcpm] [tsvwg] Agenda requests for TSVWG@IETF… Gorry Fairhurst
- Re: [tcpm] [tsvwg] Agenda requests for TSVWG@IETF… Scharf, Michael (Nokia - DE/Stuttgart)
- Re: [tcpm] [tsvwg] Agenda requests for TSVWG@IETF… Gorry Fairhurst
- Re: [tcpm] [tsvwg] Agenda requests for TSVWG@IETF… Scharf, Michael (Nokia - DE/Stuttgart)
- Re: [tcpm] [tsvwg] Agenda requests for TSVWG@IETF… Michael Welzl
- Re: [tcpm] [tsvwg] Agenda requests for TSVWG@IETF… David Ros
- Re: [tcpm] [tsvwg] Agenda requests for TSVWG@IETF… Gorry Fairhurst
- Re: [tcpm] inband signaling (was: Re: [tsvwg] Age… Toerless Eckert
- Re: [tcpm] [tsvwg] Agenda requests for TSVWG@IETF… Spencer Dawkins at IETF
- Re: [tcpm] [tsvwg] inband signaling (was: Re: Age… Lin Han
- Re: [tcpm] [tsvwg] inband signaling (was: Re: Age… Toerless Eckert
- Re: [tcpm] [tsvwg] inband signaling (was: Re: Age… Lin Han
- Re: [tcpm] [tsvwg] inband signaling (was: Re: Age… Ingemar Johansson S
- Re: [tcpm] [tsvwg] inband signaling (was: Re: Age… Smith, Kevin, (R&D) Vodafone Group
- Re: [tcpm] [tsvwg] Agenda requests for TSVWG@IETF… Yingzhen Qu
- Re: [tcpm] [tsvwg] Agenda requests for TSVWG@IETF… Michael Tuexen
- Re: [tcpm] Agenda requests for TSVWG@IETF101 Pat Thaler
- Re: [tcpm] Agenda requests for TSVWG@IETF101 Yingzhen Qu
- Re: [tcpm] [tsvwg] Agenda requests for TSVWG@IETF… Brian E Carpenter
- Re: [tcpm] [tsvwg] inband signaling (was: Re: Age… Lin Han
- Re: [tcpm] [tsvwg] Agenda requests for TSVWG@IETF… Toerless Eckert
- Re: [tcpm] [tsvwg] inband signaling (was: Re: Age… Ingemar Johansson S
- Re: [tcpm] [tsvwg] inband signaling Brian E Carpenter
- Re: [tcpm] draft-han-tsvwg-cc (was: Re: [tsvwg] A… Scharf, Michael (Nokia - DE/Stuttgart)
- Re: [tcpm] [tsvwg] Agenda requests for TSVWG@IETF… Scharf, Michael (Nokia - DE/Stuttgart)
- Re: [tcpm] [tsvwg] inband signaling (was: Re: Age… Lin Han
- Re: [tcpm] inband signaling (was: Re: [tsvwg] Age… Scharf, Michael (Nokia - DE/Stuttgart)
- Re: [tcpm] [tsvwg] inband signaling (was: Re: Age… Lin Han
- Re: [tcpm] [tsvwg] inband signaling (was: Re: Age… Scharf, Michael (Nokia - DE/Stuttgart)
- Re: [tcpm] [tsvwg] inband signaling (was: Re: Age… Lin Han
- Re: [tcpm] [tsvwg] inband signaling Brian E Carpenter
- Re: [tcpm] [tsvwg] inband signaling (was: Re: Age… Scharf, Michael (Nokia - DE/Stuttgart)
- Re: [tcpm] [tsvwg] inband signaling (was: Re: Age… Tom Herbert
- Re: [tcpm] [tsvwg] inband signaling (was: Re: Age… Toerless Eckert
- Re: [tcpm] [tsvwg] inband signaling (was: Re: Age… Spencer Dawkins at IETF
- Re: [tcpm] [tsvwg] inband signaling (was: Re: Age… Toerless Eckert
- Re: [tcpm] [tsvwg] inband signaling (was: Re: Age… Ingemar Johansson S
- Re: [tcpm] [tsvwg] inband signaling (was: Re: Age… Lin Han