Re: Announcing the TSVAREA session on "Evolution of IETF Transport Protocols" @ IETF-88
Bob Briscoe <bob.briscoe@bt.com> Fri, 25 October 2013 14:19 UTC
Return-Path: <bob.briscoe@bt.com>
X-Original-To: tsv-area@ietfa.amsl.com
Delivered-To: tsv-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4347211E83E6 for <tsv-area@ietfa.amsl.com>; Fri, 25 Oct 2013 07:19:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.498
X-Spam-Level:
X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbIWq64FkpEz for <tsv-area@ietfa.amsl.com>; Fri, 25 Oct 2013 07:19:31 -0700 (PDT)
Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id 916CE11E81BB for <tsv-area@ietf.org>; Fri, 25 Oct 2013 07:19:30 -0700 (PDT)
Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 25 Oct 2013 15:19:25 +0100
Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 25 Oct 2013 15:19:28 +0100
Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.347.0; Fri, 25 Oct 2013 15:19:25 +0100
Received: from BTP075694.jungle.bt.co.uk ([10.215.131.145]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r9PEJOUq006394; Fri, 25 Oct 2013 15:19:24 +0100
Message-ID: <201310251419.r9PEJOUq006394@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 25 Oct 2013 15:19:18 +0100
To: Toerless Eckert <eckert@cisco.com>
From: Bob Briscoe <bob.briscoe@bt.com>
Subject: Re: Announcing the TSVAREA session on "Evolution of IETF Transport Protocols" @ IETF-88
In-Reply-To: <20131024193152.GQ11229@cisco.com>
References: <526776F0.50401@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645BE80CD@dfweml509-mbb.china.huawei.com> <20131024193152.GQ11229@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
Cc: "tsv-area@ietf.org" <tsv-area@ietf.org>
X-BeenThere: tsv-area@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Transport and Services Area Mailing List <tsv-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsv-area>
List-Post: <mailto:tsv-area@ietf.org>
List-Help: <mailto:tsv-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Oct 2013 14:19:36 -0000
Toerless, * QoS in the network is not unequivocally a good thing - for instance, if you can make delay predictably low for all BE traffic, you don't need or want the complexity of differentiated latency. * Similarly, Mobile IP is not unequivocally a good thing. Rest assured my slot will not be about the bottom 20%, it is about enabling a "top 20%" combination of AQM and transport (DCTCP) to be deployable alongside the bottom 20%, rather than stuck out of reach in data centres. But, in general, I agree your point is true for many of these TSV efforts - and in a maturing network like the Internet you would expect that. However, universal damnation of everything wasn't warranted. Bob At 20:31 24/10/2013, Toerless Eckert wrote: >Reminds me a bit of the situation early on in RMT. There where >so many proposal for the "one protocol will save the world" that the WG >had to step back and first create a taxonomy of building block to >sort through the necessary/beneficial functions in them and only after >that was done try to compose full-protocol recommendations. > >Aka: would be lovely if this effort could lead to some useful taxonomy >of network conditions and components driving the innovations. > >I am a bit cynical here, because if i look at the overall scope of >stuff going on (not specifically the ones proposed to be talked about), >what i see is this (yes, some pessimistic blinders used): > > 60% workaround to get through NAT/FW with a transport flow > 10% workaround to get QoS without having QoS in the network > 10% workarounds to use multiple interfaces without having mobile IP > 10% workarounds to make new congestion control compete with the > dumbest TCP stack and stupiest queue. > 9% workarounds to do transport stuff inside the app as opposed to > traditionally the OS because OS stacks are also considered inagile. > 1% all the other cool stuff SCTP had already try to aggregate but > re-done in the context of the above workarounds. > >So, the evolution of transport protocols i see is this architecture: > > -> the network is a bunch of bad packet forwarders with a lot of NAT/FW, > no DiffServ or other QoS, not even good AQM, no mobility, but a lot > of congestion by badly behaving transport stacks. > -> The OS likewise is not agile enough to deploy innovation. > -> In-Middleware/App- Transport stacks to the rescue with all the above > inside the transport stack, designed only against the lowest common > denominator. > >I totally get the business need that tranport stacks must do these >workarounds, >even if it's just for the bottom 20% paths/subscribers of interest. But >what we have is overwhelmingly a focus on ONLY this bottom 20%, and little >in the transport stacks that balances expectations. If you bring in MUSTs >for workarounds at the bottom, i think the same spec MUST also include the >appropriate improvements for the top. Otherwise the market dynamics will >just continue to cause a race to the bottom and the title of the slot should >be: > > "Evolution of transport stacks - Rewarding bad networks and OS" > >Cheers > toerless > > >On Thu, Oct 24, 2013 at 06:19:25PM +0000, Linda Dunbar wrote: > > Martin and Spencer, > > > > Possible to include HTTP? More and more applications run HTTP, > and many people believe that HTTP is the future of the transport protocol(s). > > > > Linda > > > > > -----Original Message----- > > > From: tsv-area-bounces@ietf.org [mailto:tsv-area-bounces@ietf.org] On > > > Behalf Of Martin Stiemerling > > > Sent: Wednesday, October 23, 2013 2:13 AM > > > To: tsv-area@ietf.org > > > Subject: Announcing the TSVAREA session on "Evolution of IETF Transport > > > Protocols" @ IETF-88 > > > > > > Dear all, > > > > > > We would like to give time to the Transport Area to discuss any > > > potential need to evolve the IETF transport protocols. > > > > > > There are a number of proposals discussed in the IETF and outside of > > > the > > > IETF on changing parts of TCP (e.g. laminar TCP [1]), reusing parts of > > > TCP (e.g., TCP Minion [2]), completely new transport protocols (e.g. > > > QUIC [3]), and also discussions about the congestion control approach > > > to > > > be used (e.g., delay-based [4], LEDBAT [5]). > > > > > > (We are fully aware that this list of proposals is incomplete) > > > > > > Spencer and I are planning a slot in the TSVAREA session at IETF 88 in > > > Vancouver to discuss this topic. > > > > > > More information to come soon. > > > > > > Let Spencer and me know at tsv-ads@tools.ietf.org if you are interested > > > in contributing actively to the session. > > > > > > Thanks, > > > > > > Spencer and Martin, your TSV ADs. > > > > > > References > > > [1] https://developers.google.com/speed/protocols/tcp-laminar > > > [2] http://tools.ietf.org/html/draft-iyengar-minion-concept > > > [3] > > > https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV- > > > ev2jRFUoVD34/edit?pli=1 > > > [4] https://datatracker.ietf.org/wg/rmcat/charter/ > > > [5] https://datatracker.ietf.org/wg/ledbat/charter/ > >-- >--- >Toerless Eckert, eckert@cisco.com >Cisco NSSTG Systems & Technology Architecture >SDN: Let me play with the network, mommy! ________________________________________________________________ Bob Briscoe, BT
- Announcing the TSVAREA session on "Evolution of I… Martin Stiemerling
- Re: Announcing the TSVAREA session on "Evolution … Wesley Eddy
- RE: Announcing the TSVAREA session on "Evolution … Linda Dunbar
- Re: Announcing the TSVAREA session on "Evolution … Scott Brim
- Re: Announcing the TSVAREA session on "Evolution … Toerless Eckert
- Re: Announcing the TSVAREA session on "Evolution … Matt Mathis
- Re: Announcing the TSVAREA session on "Evolution … Michael Welzl
- Re: Announcing the TSVAREA session on "Evolution … Bob Briscoe
- Re: Announcing the TSVAREA session on "Evolution … Toerless Eckert
- Re: Announcing the TSVAREA session on "Evolution … Martin Stiemerling
- Re: Announcing the TSVAREA session on "Evolution … Wesley Eddy
- RE: Announcing the TSVAREA session on "Evolution … Linda Dunbar
- Re: Announcing the TSVAREA session on "Evolution … Martin Stiemerling
- Re: Announcing the TSVAREA session on "Evolution … Martin Stiemerling
- Re: Announcing the TSVAREA session on "Evolution … Joe Touch
- Re: Announcing the TSVAREA session on "Evolution … Martin Stiemerling
- Re: Announcing the TSVAREA session on "Evolution … Scott Brim
- Re: Announcing the TSVAREA session on "Evolution … Joe Touch
- Re: Announcing the TSVAREA session on "Evolution … Martin Stiemerling
- RE: Announcing the TSVAREA session on "Evolution … l.wood