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/
>