Re: [nwcrg] Spencer Dawkins' Yes on draft-irtf-nwcrg-network-coding-satellites-13: (with COMMENT)

"lloyd.wood@yahoo.co.uk" <lloyd.wood@yahoo.co.uk> Sat, 23 May 2020 02:02 UTC

Return-Path: <lloyd.wood@yahoo.co.uk>
X-Original-To: nwcrg@ietfa.amsl.com
Delivered-To: nwcrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF653A0D7C for <nwcrg@ietfa.amsl.com>; Fri, 22 May 2020 19:02:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.co.uk
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 7H4gYo0m58AL for <nwcrg@ietfa.amsl.com>; Fri, 22 May 2020 19:02:48 -0700 (PDT)
Received: from sonic314-21.consmr.mail.ir2.yahoo.com (sonic314-21.consmr.mail.ir2.yahoo.com [77.238.177.147]) (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 A8CCF3A0D7E for <nwcrg@irtf.org>; Fri, 22 May 2020 19:02:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1590199364; bh=N+nAibap/AeB/WPU1eCt5KjPBgpwUBf2GU6A7Xyxidw=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=lEfUd3e5eLXvSiRP6WlQwLr2RC+dUBk9s12pq6MhT3jHNSoYaUbMefCJ18E+DcW2Rg9/XgmvJavpURdsFeqrjyZ1Po310f0FT3dobksbN9iD7bIXMw5Btfpr17L5kbM4YsNe+9KDuSoDRMs1/wPZkd7SPxIcCLE0YeN6O4djwd2B4eSU5HX6Y1sD7zNjByLODUlGyVbioB5ZGc9dOenA48L0NPpWfkhwzk/TK5BJIqQHPcYAPWJeG/G8ONuqzKJMjtkCQHxv0rm4i8H3qRxoV7uucaFEyZZay+wNV10YbNDtSmiD2YW33cKLTMdTgrtuf23YMzFB2Ul0Ob3fqDHAwQ==
X-YMail-OSG: AOxOP0wVM1mZU2v26WigzMB.uomxwK6teJtlrEP9uyLFOC4m_fgitrDGkKHsoX6 26AI1RjAHdQrdQTNvhdBSiMpfBvoVbSJcqzlDBw1X3n_lLGnSmaV575xCgvXV.dnAbG0dQxgZHeL M_VyamwVGLyQ657uD5MIorzCd4qD6P5PWyQLL_wiYjXV75Va9bL4VW.nxNE_nO2.YN18y2w_91ei SZa63p4KECu3pSyVBSKWx_p_yPmRK1JuCVjqoidbj7a46wpLlqtgHZW.v3tC5eQjKcNyB257lslN gTBnXG79xsZrkpPgk88Cf4X_1Y9kZ0bCd0iJhLSaxPQr4SCN0HZK692UMQBFOPL2KGrUjwjeCJnv J55P0sSAQCJ3p7UIXlGMcGcqB5acz.j5UiVuadLt2S5a_.IjS8RnenhxCBCRPpGxBbDKz7_pSTHv pL5HNd5Ijhq2cubQKmoj0cHUXYo7YkPPn7LPCc7fPrWKUvuBRB3iF1p2vyQUxQA.vWaG71Ll0F5D Z9JyUZ7zykEf8kzyjrrTqN9ZK4E6gWekz9TsZ_QgL_ESof5_KchYAIjNpRN9AZILLnSeaMtLTh1m ulxnYdIHzRdRd1XTKoO2gVzapbWZlW.aAZ_I72w1Hwwu8N.0sd1NRvsceG1J_YnmLWzDLEX3BOJf 0OsEK98rBN5TjkrPWYzGQN17CFm7vspVp7tJRLO2veTx5NQRIl_SQ1SH5atgzJEFPR6Och0JdW3P w9lKH24d1QPfOp62Z16qRW0qpSArQUo1wLoop1lVGhAS3pgAABTX0N52hxd0VZE3xjngoKKmFKu_ zWRkdwMh4q.uXtGevw.NUitXcoPE3F2SHMFVcxu5Qyv3o5w.KpqL62SA79EbIU3opiVoW3M_0uj2 gY19ZyQVErXHKKwNfRLTVY7CR3NAj1d6ipLhXmmOOeUTyg1RKnzDYCscGl.afRPCDS5g3_FBjDu_ 4hlZvl35IyacSZwUcbUMbydPdA6WqA2mF8iuIiNWBHwvfj244eL4qYa8nTVsTb479qIQVG_ebUa_ vKBV1Wv3oFUUJRLwOv3hs0wB27g5UUGk2Y4h.mwNkUqoYEWjet6kPAhJ82QNLDQC5kG..a6.eEuf jO1Gz7hhWdByrHX9QyLqFYwxfMwqBchuFTo42assDu5xdPEL7.fG6tOhJerPVG9uSgM8_goBCtqp D1Ahdt4ymtk.GSTOpt639fo.nFMns_N4A_q3tFyyB8uq8BqRxNyCnxRMqqnGiiikGxehtr67N2JU obOOizmdFthmFIpj_qcN33CeRywDmXsKne2_yMLKXkJCxI29uiVe0Pvceg_scHB0m6h8n99cQb1W .ZGXi20NtuP6_EXNbnbMePnGOHPiDtZWdtdvSW70-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ir2.yahoo.com with HTTP; Sat, 23 May 2020 02:02:44 +0000
Date: Sat, 23 May 2020 01:52:39 +0000
From: "lloyd.wood@yahoo.co.uk" <lloyd.wood@yahoo.co.uk>
To: The IRSG <irsg@irtf.org>, Spencer Dawkins <spencerdawkins.ietf@gmail.com>
Cc: vincent.roca@inria.fr, nwcrg@irtf.org, draft-irtf-nwcrg-network-coding-satellites@ietf.org, nwcrg-chairs@ietf.org
Message-ID: <24177699.3708839.1590198759351@mail.yahoo.com>
In-Reply-To: <159015933944.21205.1257920058480954416@ietfa.amsl.com>
References: <159015933944.21205.1257920058480954416@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: WebService/1.1.15960 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/nwcrg/GPQIj_iY0v0AqbwOw2Upy7EDTFc>
Subject: Re: [nwcrg] Spencer Dawkins' Yes on draft-irtf-nwcrg-network-coding-satellites-13: (with COMMENT)
X-BeenThere: nwcrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IRTF Network Coding Research Group discussion list <nwcrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/nwcrg>, <mailto:nwcrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nwcrg/>
List-Post: <mailto:nwcrg@irtf.org>
List-Help: <mailto:nwcrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/nwcrg>, <mailto:nwcrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 May 2020 02:02:52 -0000

Spencer,


ack spoofing has gone away in PEPs -- when the Savage attacks were addressed in TCP stacks. See Stefan Savage's papers, the relevant section of RFC5681, etc.


TCP connection splicing assumes an unencrypted TCP flow. That's going away, very rapidly. Compression and caching (typically for http) also assume unencrypted flows, and they're going away very quickly. Typical PEPs for satellite acceleration are stripping out this code as not worth maintaining. Yes, PEP proxying for a security endpoint and going full man-in-middle to recreate TLS etc. so that they could do compression and caching is technically possible, but the benefits generally aren't worth the security concerns and code complexity. (Though Riverbed will try to do it, bless their hearts.)


So, those technical terms of art are imo not worth being referred to at this point.


TCP congestion window sizing to ameliorate slow start remains, and is the go-to strength of PEPs for TCP that can be called out as a typical technical feature. It's slightly clearer than the generic 'TCP acceleration' imo, and is a substitution I'd recommend.


L.


we really need to accelerate the speed of light.


Lloyd Wood lloyd.wood@yahoo.co.uk http://about.me/lloydwood






On Saturday, 23 May 2020, 12:56:25 am AEST, Spencer Dawkins via Datatracker <noreply@ietf.org> wrote: 


In this text,



  o  PEP: Performance Enhancing Proxy [RFC3135] - a typical PEP for

      satellite communications include compression, caching and TCP

                                                                ^^^

      acceleration;

      ^^^^^^^^^^^^



I know "TCP acceleration" is the correct marketing term (I worked at a company

that sold them, in my darkest past), but would it be correct to say something

like "TCP ACK spoofing", or "TCP connection splicing", which is I think the

3GPP term?