Re: [tcpm] [tsvwg] Agenda requests for TSVWG@IETF101
Yingzhen Qu <yingzhen.ietf@gmail.com> Tue, 13 March 2018 06:43 UTC
Return-Path: <yingzhen.ietf@gmail.com>
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 E6C69126DFF; Mon, 12 Mar 2018 23:43:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 6Pjzo5hCnCC8; Mon, 12 Mar 2018 23:43:30 -0700 (PDT)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1FC1126DCA; Mon, 12 Mar 2018 23:43:29 -0700 (PDT)
Received: by mail-qk0-x232.google.com with SMTP id z184so12709978qkc.1; Mon, 12 Mar 2018 23:43:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pfCUUGQ7Ngq5CS0bbjmrzdqS4iHFNOkLyFSy4kpqF60=; b=EgMnulmOZkl5I4YcAKhgpsPi9OuGirG7Rq/wvMJYWhVWBUxF1lDzZNGK8Fs033Yv99 mAjxO6KX7TKs4TiRt7I3mcdzv37ixfpJ+I9H3xYP3GWanCyq1C5vQykiaK8eLaStWAsu le7GI7CSCff4NWVf2/I+YDiAeN/nE9RvKgWwZbtEjiWa2g1BR19AgxsJXa9f+py1on5l YUKZC7nYXovgbvER4IywIkv9bV1Kr8I8JZJ/cvkGbJhAqyECcYJOFEhcMDThvyM59gXq gKpTrZXKGP12pH2W2AyWQyTbgBVq3//YVr1pvGUMS2Oaxq9pD71bqJl5HDYdkqruu8Td ctgg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pfCUUGQ7Ngq5CS0bbjmrzdqS4iHFNOkLyFSy4kpqF60=; b=oAd1wsumQC2N32b7pz9zQk36DyMCfOfAeoLF4m62lTx1cU6SLj5LrnfX6aUhOj/xyp D9obIkMRBPdnax6dwOspmebzG8V4fQaD94fizIUiRWWG3rQfzzeULuAZ6zMO3QP9cfdf I8onfvjEzRHWqHFWAGbY3q21rkSAI0hj68O61JDkCnU0SrlLhJziaxFdHoTWZseCm5VY hwb32aqcELWYNdNF58Azeuci+GtMlUEgaMAaEjWGI7ab9d2fwC7krtpbqYKbj9E/AMce 5zRdvMN/OXRe3u5yDG27MYCScnFl5g2+shZLXzCqommMMng4bmCpEOvhakWs1dRlmQU5 j7zw==
X-Gm-Message-State: AElRT7FczBqssqeHnc5uezXzJ2hqLnWPSO6nzysQAS+4Ty0Di1OutHGU S5kNkCj9TjNZ7PfAVrzmhEEknr3qr+QjA9xGkA==
X-Google-Smtp-Source: AG47ELs4Cn+lTJE59UnQ8j7hgYSgw5t5oKn/9OfiYUxy/5a/346OhADcLbbxY+3jJKbq5CmCPJy4tlCGns4Sym1xdus=
X-Received: by 10.55.64.21 with SMTP id n21mr15668858qka.186.1520923409060; Mon, 12 Mar 2018 23:43:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.60.123 with HTTP; Mon, 12 Mar 2018 23:43:28 -0700 (PDT)
In-Reply-To: <AM5PR0701MB25474AC4A52E38B43E543FA193DA0@AM5PR0701MB2547.eurprd07.prod.outlook.com>
References: <A1F61D20-1911-4A6E-9F80-A1DF1EF91816@huawei.com> <AM5PR0701MB254755BA63E33173CC7C7BCE93DB0@AM5PR0701MB2547.eurprd07.prod.outlook.com> <5A9BEB65.6010102@erg.abdn.ac.uk> <CABY-gOO8sH3+5qfFj7DV6wh6+uX8CyBfwo4FBLi=9x1RngQDHg@mail.gmail.com> <AM5PR0701MB25474AC4A52E38B43E543FA193DA0@AM5PR0701MB2547.eurprd07.prod.outlook.com>
From: Yingzhen Qu <yingzhen.ietf@gmail.com>
Date: Mon, 12 Mar 2018 23:43:28 -0700
Message-ID: <CABY-gOMJf-4GKkbmYMJScrafO44NEfy0hoq5KXJ0uVA+QUXGiA@mail.gmail.com>
To: "Scharf, Michael (Nokia - DE/Stuttgart)" <michael.scharf@nokia.com>
Cc: "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, Thomas Nadeau <tnadeau@lucidvision.com>, "tcpm@ietf.org" <tcpm@ietf.org>, Yingzhen Qu <yingzhen.qu@huawei.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="001a114e528687167c056745930c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/pyFsH8Hjwb47CKTGGub6hZWnXrM>
Subject: Re: [tcpm] [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: Tue, 13 Mar 2018 06:43:33 -0000
Hi Michael, Sorry for the late response. Thanks for pointing out that we missed this important reference. You're right, Quick-Start and our proposal do have lots of similarities, for example both of them require that end-points and routers to work together. But they are also different in details. For example, in our proposal in-band signaling proposal bandwidth is reserved on routers along the path. In next version of this draft, We'll add discussions about RFC 4728 and 6077. BTW, can I request a slot to present this draft in TCPM if time allows? Thanks, Yingzhen On Mon, Mar 5, 2018 at 12:09 AM, Scharf, Michael (Nokia - DE/Stuttgart) < michael.scharf@nokia.com> wrote: > I believe that this proposal is similar to QuickStart TCP (RFC 4782), > which is not cited in draft-han-tsvwg-cc, and the reference is also missing > in draft-han-6man-in-band-signaling-for-transport-qos. > > > > RFC 6077 explains some of the issues that an in-band signaling mechanism > like Quick-Start has to solve. As far as I can tell, the fundamental > challenge is neither the protocol specification nor a prototype > implementation. For instance, it has been proven that QuickStart TCP can be > implemented e.g. in network processors (see http://www.ikr.uni-stuttgart. > de/Content/Publications/Archive/Sf_Diss_40112.pdf). > > > > So, when updating the documents, I suggest to add a discussion of how the > open research issues explained in RFC 6077 are addressed. > > > > Michael > > > > > > *From:* Yingzhen Qu [mailto:yingzhen.ietf@gmail.com] > *Sent:* Sunday, March 04, 2018 9:59 PM > *To:* gorry@erg.abdn.ac.uk > *Cc:* Scharf, Michael (Nokia - DE/Stuttgart) <michael.scharf@nokia.com>; > Thomas Nadeau <tnadeau@lucidvision.com>; tcpm@ietf.org; Yingzhen Qu < > yingzhen.qu@huawei.com>; tsvwg@ietf.org; tsvwg-chairs@ietf.org > *Subject:* Re: [tsvwg] Agenda requests for TSVWG@IETF101 > > > > Hi Gorry and Michael, > > > > Thanks for the suggestion, I'll request a presentation in ICCRG. > Meanwhile, I think since the in-band signaling draft was presented in > TSVWG, if time allows it still makes sense to present this draft in TSVWG. > > > > The in-band signaling draft covers lots of aspects, and the required > changes include network layer and transport layer. We're working on > updating the draft, and may break it into pieces to fit different WGs. > > > > Your comments and help are very much appreciated. > > > > Thanks, > > Yingzhen > > > > On Sun, Mar 4, 2018 at 4:49 AM, Gorry Fairhurst <gorry@erg.abdn.ac.uk> > wrote: > > I am unsure yet what the correct group of people world be to explore a > "Bandwidth Guaranteed Network". The presentation last IETF looked like the > work could imply a need for changes proposed to the network layer (using > OAM exchnages) to set the sending rate and make those bandwidth > reservations. In the end, it could result in a protocol quite different to > TCP, I think this sort of change may possibly have a home in TSVWG - but > first I'd agree with Michaeland would encourage a presentation of the > problem statement in ICCRG to explore the issues. > > Gorry > > On 04/03/2018, 10:34, Scharf, Michael (Nokia - DE/Stuttgart) wrote: > > > Hi all, > > From the abstract: “…This draft proposes a new TCP congestion control > algorithm used in bandwidth guaranteed networks. It is an extension to the > current TCP standards.” > > In the IETF, I believe the expertise for this specific document would be > in TCPM, which in CC. If the authors are interested in feedback on the > proposed mechanism, I would recommend to ask TCPM. > > Alternatively, corresponding research could perhaps be performed in the > ICCRG. ICCRG has published RFC 6077 to document some of the open research > issues in this space. > > Michael > > *From:*tsvwg [mailto:tsvwg-bounces@ietf.org] *On Behalf Of *Yingzhen Qu > *Sent:* Sunday, March 04, 2018 6:55 AM > *To:* tsvwg@ietf.org; tsvwg-chairs@ietf.org > *Cc:* Thomas Nadeau <tnadeau@lucidvision.com> > *Subject:* [tsvwg] Agenda requests for TSVWG@IETF101 > > 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/ > > If there is any question, please kindly let us know. > > Thanks, > > Yingzhen > > > > >
- 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