Re: [tsvwg] [tcpm] Agenda requests for TSVWG@IETF101
Toerless Eckert <tte@cs.fau.de> Wed, 14 March 2018 23:32 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9956E126FDC; Wed, 14 Mar 2018 16:32:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.961
X-Spam-Level:
X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 Oa8fgdgL543J; Wed, 14 Mar 2018 16:32:17 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5520F126CD6; Wed, 14 Mar 2018 16:32:17 -0700 (PDT)
Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 12FF858C4BA; Thu, 15 Mar 2018 00:32:12 +0100 (CET)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id ED8B3B0DD1F; Thu, 15 Mar 2018 00:32:11 +0100 (CET)
Date: Thu, 15 Mar 2018 00:32:11 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Pat Thaler <pat.thaler@broadcom.com>
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, Thomas Nadeau <tnadeau@lucidvision.com>, "tcpm@ietf.org" <tcpm@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "Scharf, Michael (Nokia - DE/Stuttgart)" <michael.scharf@nokia.com>, "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>, DetNet Chairs <detnet-chairs@ietf.org>, Yingzhen Qu <yingzhen.qu@huawei.com>
Message-ID: <20180314233211.GA11615@faui40p.informatik.uni-erlangen.de>
References: <A1F61D20-1911-4A6E-9F80-A1DF1EF91816@huawei.com> <AM5PR0701MB254755BA63E33173CC7C7BCE93DB0@AM5PR0701MB2547.eurprd07.prod.outlook.com> <5A9BEB65.6010102@erg.abdn.ac.uk> <CAJt_5EiroGsuQks5gcUOmLTxAd7NbqyYVbFu4iQ6_TXqH1pT3w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAJt_5EiroGsuQks5gcUOmLTxAd7NbqyYVbFu4iQ6_TXqH1pT3w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/kvgAbej13Sla6GLsKaZEhaCml5Q>
Subject: Re: [tsvwg] [tcpm] Agenda requests for TSVWG@IETF101
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Mar 2018 23:32:20 -0000
Thanks, Pat - inline. On Wed, Mar 14, 2018 at 09:41:55AM -0700, Pat Thaler wrote: > There work underway in detnet WG in the routing area for " point-to-point > (unicast) and point-to-multipoint (multicast) flows which can be > characterized in a manner that allows the network to 1) reserve the > appropriate resources for the flows in advance, and 2) release/reuse the > resources when they are no longer required." The purpose is to provide for > bounded latency, loss and delay variation along with high reliability. The > current charter is focused on defining the data plane aspects. Yes, well aware of that. We will also propose he inband signalling fr that context. The draft already mentions in passing UDP and is really not difficult to adopt to any transport. TCP was just the most widely accepted protocol even with more challenges than UDP IMHO, thats why our inband signaling draft focusses on it. > I hope that that will be followed by work to define the control plane. +1. > I've only had a quick glance at the draft. It isn't clear to me that it > would be compatible with a network providing reservations for guaranteed > bandwidth because it allows for sending at a rate higher than the bandwidth > guarantee; (i.e. a peak rate higher than the committed rate). If flows are > allowed to consume more than their reserved resources, they may interfere > with the resources committed to other flows. The enforcement of not intruding on reserved capacity is a matter of the forwarding plane. In the most extreme case which we describe in our inband singaling, you use per-flow reservation state (shaper/scheduler). This can be optimized(cost reduced) by only doing per-flow state on the edge and only admission control (calculate/signal inband) hop-by-hop, but not establish per-flow packet processing state (shaper/scheduler). This is all exactly like IMHO it would need to work in DetNet (e.g.: forwarding plane. Signaling is obviously variable... inband signaling is just the best IMHO ;-)). The interesting part of course is that your overall latency and jitter will go down the drain once you exceed your per-flow shaper/scheduler CIR + burst size and start to compete based on congestion experience. For the not really 'realtim' apps like he typical streaming with guaranteed CIR requiremens but desire for upspeeding, this is a perfect compromise to strike. For the typical realtime app coming from a CBR world, thats a surprise that might want them to stick to just CBR = CIR = PIR requests. The more advanced video solutions btw would use the AF style forwarding approach, whereby your <= CIR rate is marked with a hghier priority AF code point and the CIR..PIR rate with a lower AF code point. And then you put the more important video frames into your higher AF code point/ <= CIR rate, and the less important frames into the lower priority and you get even better upspeeding experience (visually). This btw. is something requiring UDP or SCTP or the like. TCP apps have no control over message/packet boundaries to mark them accordingly. Wrt. DetNet: I wam not quite sure about the PHBs defined in TSN. I sometime have the fear that its a lot more limited than in IP. I hope we manage to leverage the full extend of IP QoS in DetNet and not only some L2 TSN QoS subset... Toerless > Pat > > 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 > >> > >> > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > -- --- tte@cs.fau.de
- [tsvwg] Agenda requests for TSVWG@IETF101 Yingzhen Qu
- Re: [tsvwg] Agenda requests for TSVWG@IETF101 Scharf, Michael (Nokia - DE/Stuttgart)
- Re: [tsvwg] Agenda requests for TSVWG@IETF101 Emmanuel Lochin
- Re: [tsvwg] Agenda requests for TSVWG@IETF101 Gorry Fairhurst
- Re: [tsvwg] Agenda requests for TSVWG@IETF101 Yingzhen Qu
- Re: [tsvwg] Agenda requests for TSVWG@IETF101 Yingzhen Qu
- Re: [tsvwg] Agenda requests for TSVWG@IETF101 Scharf, Michael (Nokia - DE/Stuttgart)
- Re: [tsvwg] Agenda requests for TSVWG@IETF101 Emmanuel Lochin
- [tsvwg] draft-han-tsvwg-cc (was: Re: Agenda reque… Toerless Eckert
- Re: [tsvwg] draft-han-tsvwg-cc (was: Re: Agenda r… Toerless Eckert
- Re: [tsvwg] Agenda requests for TSVWG@IETF101 Yingzhen Qu
- Re: [tsvwg] Agenda requests for TSVWG@IETF101 Gorry Fairhurst
- Re: [tsvwg] [tcpm] Agenda requests for TSVWG@IETF… Michael Tuexen
- Re: [tsvwg] Agenda requests for TSVWG@IETF101 Katsushi Kobayashi
- Re: [tsvwg] inband signaling (was: Re: Agenda req… Toerless Eckert
- Re: [tsvwg] inband signaling (was: Re: Agenda req… Lin Han
- Re: [tsvwg] inband signaling (was: Re: Agenda req… Toerless Eckert
- Re: [tsvwg] inband signaling (was: Re: Agenda req… Lin Han
- Re: [tsvwg] [tcpm] inband signaling (was: Re: Age… Ingemar Johansson S
- Re: [tsvwg] [tcpm] inband signaling (was: Re: Age… Smith, Kevin, (R&D) Vodafone Group
- Re: [tsvwg] [tcpm] Agenda requests for TSVWG@IETF… Pat Thaler
- Re: [tsvwg] [tcpm] Agenda requests for TSVWG@IETF… Yingzhen Qu
- Re: [tsvwg] [tcpm] Agenda requests for TSVWG@IETF… Brian E Carpenter
- Re: [tsvwg] [tcpm] inband signaling (was: Re: Age… Lin Han
- Re: [tsvwg] [tcpm] Agenda requests for TSVWG@IETF… Toerless Eckert
- Re: [tsvwg] [tcpm] inband signaling (was: Re: Age… Ingemar Johansson S
- Re: [tsvwg] [tcpm] inband signaling Brian E Carpenter
- Re: [tsvwg] draft-han-tsvwg-cc (was: Re: Agenda r… Scharf, Michael (Nokia - DE/Stuttgart)
- Re: [tsvwg] Agenda requests for TSVWG@IETF101 Scharf, Michael (Nokia - DE/Stuttgart)
- Re: [tsvwg] [tcpm] inband signaling (was: Re: Age… Lin Han
- Re: [tsvwg] inband signaling (was: Re: Agenda req… Scharf, Michael (Nokia - DE/Stuttgart)
- Re: [tsvwg] inband signaling (was: Re: Agenda req… Lin Han
- Re: [tsvwg] inband signaling (was: Re: Agenda req… Scharf, Michael (Nokia - DE/Stuttgart)
- Re: [tsvwg] inband signaling (was: Re: Agenda req… Lin Han
- Re: [tsvwg] [tcpm] inband signaling Brian E Carpenter
- Re: [tsvwg] inband signaling (was: Re: Agenda req… Tom Herbert
- Re: [tsvwg] inband signaling (was: Re: Agenda req… Scharf, Michael (Nokia - DE/Stuttgart)
- Re: [tsvwg] inband signaling (was: Re: Agenda req… Toerless Eckert
- Re: [tsvwg] inband signaling (was: Re: Agenda req… Spencer Dawkins at IETF
- Re: [tsvwg] inband signaling (was: Re: Agenda req… Toerless Eckert
- Re: [tsvwg] [tcpm] inband signaling (was: Re: Age… Ingemar Johansson S
- Re: [tsvwg] inband signaling (was: Re: Agenda req… Lin Han
- Re: [tsvwg] inband signaling Emmanuel Lochin
- Re: [tsvwg] inband signaling Lin Han
- Re: [tsvwg] inband signaling Toerless Eckert
- Re: [tsvwg] inband signaling Black, David
- Re: [tsvwg] inband signaling Emmanuel Lochin
- Re: [tsvwg] inband signaling Lin Han
- Re: [tsvwg] inband signaling Lin Han