Re: congestion control? - (was Re: Appointment of a Transport AreaDirector)

Cameron Byrne <cb.list6@gmail.com> Wed, 06 March 2013 16:12 UTC

Return-Path: <cb.list6@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376B821F886D for <ietf@ietfa.amsl.com>; Wed, 6 Mar 2013 08:12:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 j8ixFKELgEeE for <ietf@ietfa.amsl.com>; Wed, 6 Mar 2013 08:12:27 -0800 (PST)
Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 0C62321F8826 for <ietf@ietf.org>; Wed, 6 Mar 2013 08:12:26 -0800 (PST)
Received: by mail-we0-f173.google.com with SMTP id x51so198332wey.32 for <ietf@ietf.org>; Wed, 06 Mar 2013 08:12:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=tJn1hcNicI0XoG6hjL89vNf4A50K2immJeRjvPd6al8=; b=R/kD0tdjzubMA6WWpxOvu7hn/LtjDkpFNe0neoPugLQYe/sKrWD9Lu6S3Uq6OWCsNj GL8l1ekZ3Q0aI+1ZSOL8Pzz3dbR1Ip5xLQyHJvCrHHnsh7kHJkzha5rqbz4Qipg8t93v qyVA3PL0vqm3W+816tlRdev2QZpbwj3nLkVSjSKxkMaSC3M5OYdinZrhu++jnXtV7Nou Oa9dglnzI9ABMg4ZcyZsQL/C20i1Lo68zvHEbNOn9zAkUtTiD96Wbi9oPiCuPtV27uLv QWJ1Li0g/2Z5JYEN7JGeIcjCeavE+uiKbg0KwkEo37eSoLze2R88IWfVPv4e1cT/ajj0 mlOw==
MIME-Version: 1.0
X-Received: by 10.194.6.2 with SMTP id w2mr48189389wjw.10.1362586346145; Wed, 06 Mar 2013 08:12:26 -0800 (PST)
Received: by 10.194.20.35 with HTTP; Wed, 6 Mar 2013 08:12:25 -0800 (PST)
Received: by 10.194.20.35 with HTTP; Wed, 6 Mar 2013 08:12:25 -0800 (PST)
In-Reply-To: <5137066C.9080904@gmail.com>
References: <5134EFEB.2090104@isi.edu> <20130305004135.34CCA1A5F4@ld9781.wdf.sap.corp> <B31EEDDDB8ED7E4A93FDF12A4EECD30D2502A316@GLKXM0002V.GREENLNK.net> <CAD6AjGRt-0A42apmDwJQeRhUn6EM0qgrbrJuDipEESNz1+K9Gw@mail.gmail.com> <007e01ce1a45$a9766fa0$4001a8c0@gateway.2wire.net> <5137066C.9080904@gmail.com>
Date: Wed, 06 Mar 2013 08:12:25 -0800
Message-ID: <CAD6AjGTWumzZd=JSakj99j3x2uYgg2fEQdPjAskobLXi_n_8pQ@mail.gmail.com>
Subject: Re: congestion control? - (was Re: Appointment of a Transport AreaDirector)
From: Cameron Byrne <cb.list6@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: multipart/alternative; boundary="047d7b5d2e202352fa04d743db33"
Cc: braden@isi.edu, IETF-Discussion <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Mar 2013 16:12:28 -0000

On Mar 6, 2013 1:03 AM, "Brian E Carpenter" <brian.e.carpenter@gmail.com>
wrote:
>
> On 06/03/2013 08:36, t.p. wrote:
> ...
> > Interesting, there is more life in Congestion Control than I might have
> > thought.  But it begs the question, is this something that the IETF
> > should be involved with or is it better handled by those who are
> > developping LTE etc?
>
> From the little I know about TCP proxies, they are horrible beasts
> that can impact application layer semantics. Figuring out how to deal
> with mixed e2e paths (partly lossy, partly congested) seems to me
> very much an IRTF/IETF topic, even if we don't have an AD who is
> a subject matter expert.
>
>    Brian

There is a huge cross layer optimization issue between 3gpp and the ietf.
It is worse than you can imagine, highly akin to how the industry moved
passed the ietf with Nat. The same thing is happening with tcp.  Tcp is
simply not fit for these high latency high jitter low loss networks.

Google is a player in the e2e space for various business reasons and it
appears they are now in an arms race with these horrible mobile carrier
proxies (which in many cases do on the fly transcoding of video).

There are 2 fronts. 1 is quic as linked above. Another is their own
transcoding https proxy
https://developers.google.com/chrome/mobile/docs/data-compression

This is not novel. Opera mini has been doing this for years, otherwise know
as opera turbo. Oh, and Nokia has been doing it too.  They even help by
bypassing pki and any sense of internet security.

http://www.techweekeurope.co.uk/news/nokia-decrypting-traffic-man-in-the-middle-attacks-103799

Hold on to your hats.

CB