Re: [iccrg] [Stackevo-discuss] New Version Notification for draft-welzl-irtf-iccrg-tcp-in-udp-00.txt

John Leslie <john@jlc.net> Fri, 25 March 2016 12:35 UTC

Return-Path: <john@jlc.net>
X-Original-To: iccrg@ietfa.amsl.com
Delivered-To: iccrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5488612D6DE for <iccrg@ietfa.amsl.com>; Fri, 25 Mar 2016 05:35:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2-o_-Ddp5AnR for <iccrg@ietfa.amsl.com>; Fri, 25 Mar 2016 05:35:27 -0700 (PDT)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 6042012D6DB for <iccrg@irtf.org>; Fri, 25 Mar 2016 05:35:26 -0700 (PDT)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 1B55FC94BE; Fri, 25 Mar 2016 08:35:22 -0400 (EDT)
Date: Fri, 25 Mar 2016 08:35:22 -0400
From: John Leslie <john@jlc.net>
To: Michael Welzl <michawe@ifi.uio.no>
Message-ID: <20160325123522.GN88304@verdi>
References: <A741874C-0E2C-4905-9FD3-D29B4B94A9C0@ifi.uio.no> <56F3212B.5020408@isi.edu> <20F3E6FF-DED4-46BD-BFD5-C76F8A6A8D40@ifi.uio.no> <56F32C47.6080707@isi.edu> <271375F3-2B9D-4C61-9C6E-468E6423A1A4@ifi.uio.no> <56F427D9.9030208@isi.edu> <9826517E-9237-4EBB-AC0D-54388EBD4E5B@ifi.uio.no> <20160325105448.GM88304@verdi> <294CAD03-ABEB-4EC7-84F8-FD2C668518C2@ifi.uio.no>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <294CAD03-ABEB-4EC7-84F8-FD2C668518C2@ifi.uio.no>
User-Agent: Mutt/1.4.1i
Archived-At: <http://mailarchive.ietf.org/arch/msg/iccrg/KxTJowy7T34Lfq_xV80l9ZLYvfc>
Cc: iccrg@irtf.org, John Leslie <john@jlc.net>
Subject: Re: [iccrg] [Stackevo-discuss] New Version Notification for draft-welzl-irtf-iccrg-tcp-in-udp-00.txt
X-BeenThere: iccrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussions of Internet Congestion Control Research Group \(ICCRG\)" <iccrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/iccrg>, <mailto:iccrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iccrg/>
List-Post: <mailto:iccrg@irtf.org>
List-Help: <mailto:iccrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/iccrg>, <mailto:iccrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Mar 2016 12:35:28 -0000

Michael Welzl <michawe@ifi.uio.no> wrote:
> On 25. mar. 2016, at 11.54, John Leslie <john@jlc.net> wrote:
>  
>> Operators _don't_ have the same horror about "underutilizing" that
>> you do.
>> 
>> It turns out to be very practical to drive the bottlenecks close to
>> the endpoints; and aggregation tends to ameliorate under-utilization
> 
> Sure, that all makes sense to me - but you???re talking about operators
> dealing with today???s system. I don???t think that we want to design
> a congestion control based on the assumption that underutilizing
> won???t matter anyway?

   That's not what I meant to say...

   I was trying to talk about what we're really experiencing today. I'm
not at all sure there's any end-to-end improvement available from
optimizing the balance of multi-path forwarding not under the control
of one of the endpoints.

   IMHO, there _are_ issues where "TCP Congestion Control" is a bit
brain-dead; and could be improved by tracking the capacity of the path(s)
available to it.

   But its failure to utilize path capacity stems from ramp-up problems
and its "steady-state" insistance on sawtoothing.

   I'd like us to work on getting better congestion signals and making
better use of them.

--
John Leslie <john@jlc.net>