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