IETF Logo Mail Archive

Re: [alto] alto transport streams (Re: early reviews)

Mark Nottingham <mnot@mnot.net> Thu, 28 July 2022 03:28 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F22CC13C51F for <alto@ietfa.amsl.com>; Wed, 27 Jul 2022 20:28:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.11
X-Spam-Level:
X-Spam-Status: No, score=-7.11 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=Je1bKUnj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=iPKP8NSr
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2b6oDNnMY1c for <alto@ietfa.amsl.com>; Wed, 27 Jul 2022 20:28:27 -0700 (PDT)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECA05C14CF0A for <alto@ietf.org>; Wed, 27 Jul 2022 20:28:26 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 6B136320095A; Wed, 27 Jul 2022 23:28:23 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 27 Jul 2022 23:28:23 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1658978902; x= 1659065302; bh=GjN0hZy1mKKarUsAJwSg5xcqo9ZfL5TU59Nm3HS86Xs=; b=J e1bKUnjt5PyLZy/mN43QvdEmI4kqPLZHAGWncefjuPyq6NCiUdMQ+INQdcx05Ozh XuE/vOk9iDu7ozVoK5E4hEtkzOfYcagDVeF3Ewf2d4j9YvJKsc1wI6aShBuosmNR qYuJPEXawt5SzwJkZfYWtFRoN+i6ud06TBw/abbmi9FmW0Cx6ux2MNC+39CNTTfo wy5pXCeDfDZPYrPK1h8vSEjZP1h1jCLWj0gFsltKPFe/tMQQ+u6wOWU27vSic+aL 3b0l4OXfSSb7ApE1154JVwgj3r57AJkSlJm1E/DGIvUFMn/EaAePdPXKQrjifGLu FrkCJlJZbb0DuFp4o87zA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1658978902; x= 1659065302; bh=GjN0hZy1mKKarUsAJwSg5xcqo9ZfL5TU59Nm3HS86Xs=; b=i PKP8NSrnuaBJaUQHL3JBec5fXb9YRPXWD2teJzFtsh2aBKcnm5VP4HMnCzIcjmms GNzU4oSnetqhSNUiwnADHE6IgHEgZupcQFF9+nvOXtX/yguDYqfVAoq0fksG8/4e NehfRpvAspTSZc+6PWqp/48Db4Jxr16F6Qjdr6JUjLbdEiAioAh5eTp+4lbvNcOK LA/Vq0S93PgarN2vhzqXNvZD3NvAMQNNqH+cccIilwJRVnyj/0Y3F2CyZr7xVLl4 sAk3gcLJBahJUS55DIks+k7MWuqTahXB4J+AgVxe0MZ2dseQ9JOnp7Jh1sSnwoA4 +MSLSgUpT6QJMWde2GFPQ==
X-ME-Sender: <xms:VgLiYmx5LGQ6KYi2PzzxKwdCczDODY9wow6IK0UOoIcNIil8AkOrvQ> <xme:VgLiYiTXjHuqf0UlbgpiyDIDRibE3yarq78dtm0NEq6q_hyhRFYd9sd2HgPnYP3iC qgmPnmwpmYAtGegcg>
X-ME-Received: <xmr:VgLiYoVK0qjCTjqm_61dLk9Yl3McZ76CKaEb3IkJY2TAqZiNyYXzzNtF3o1cYV-l79BcsC9TsfeOKp9cHvbj4EYEksMLhCJ0TSu7X4AFx-LxylDjjvo4KOxc>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvddufedgjedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffvefgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghr khcupfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrth htvghrnheptddtgefgueevtddugfdtkeffudegveetffegjeelhfdvtedvueejteegueeg teetnecuffhomhgrihhnpehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght
X-ME-Proxy: <xmx:VgLiYsik_B2cpchn-K528HReLyJBDO96UsrKIXfAqpa2OtiqVGC2Pg> <xmx:VgLiYoCdQVUmJrHYZw_XK0l8LdXRRsgA34edCzNYkN_xGES1CFySDw> <xmx:VgLiYtKrV_PO_laUJMFfXOWUSVOqNxryXM1_T27GoTo2IP5CIrAg-A> <xmx:VgLiYrP5BvsEYsIB8c57rbJTfKXpmHxTbxKb7vvNGKxNxFBxQkW7rw>
Feedback-ID: ie6694242:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 27 Jul 2022 23:28:21 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CANUuoLrvFMDDaY+o4FF=q_evbH+NfsNNb_3y98i-NvC0wzFhOQ@mail.gmail.com>
Date: Thu, 28 Jul 2022 13:28:18 +1000
Cc: Spencer Dawkins <spencerdawkins.ietf@gmail.com>, Martin Duke <martin.h.duke@gmail.com>, IETF ALTO <alto@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1AD3673D-481A-4AA4-9B94-4E1200756473@mnot.net>
References: <CANUuoLoGYYO3PczKzCyvnrNoqGUa0Zfn8rr-x+Hz2dzqLFBVww@mail.gmail.com> <EF370A5A-1005-4F81-98F8-CB7117B9513F@mnot.net> <CANUuoLrvFMDDaY+o4FF=q_evbH+NfsNNb_3y98i-NvC0wzFhOQ@mail.gmail.com>
To: "Y. Richard Yang" <yry@cs.yale.edu>
X-Mailer: Apple Mail (2.3696.100.31)
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/hX_ELF2ogWteuFoo6K-5cpmdaEw>
Subject: Re: [alto] alto transport streams (Re: early reviews)
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jul 2022 03:28:31 -0000

> On 25 Jul 2022, at 1:27 pm, Y. Richard Yang <yry@cs.yale.edu> wrote:
> 
> Consider a set of resources {Ui} with application-level dependencies (e.g., U1 -> U2, U1 -> U3, U3 -> U4). I see two transport-oblivious designs:
> - Transport oblivious, batch submission: U1, U2, U3 and U4 are submitted to the (HTTP) transport (buffers) concurrently. Without knowing the dependencies, the transport may schedule the transfers in the order of U4, U3, U2 and U1, resulting in application layer latency.
> - Transport oblivious, controlled-release submission: app submits U1; and when U1 is transferred, submits U2/U3 (i.e., those at the roots of the DAG); after U3 is transported, submit U4. This will avoid priority reversal but a problem is that if the TCP congestion window is large enough to accommodate all U1-U4, it helps to submit all all.
> 
> Any previous work/techniques?

To me, the first question here is whether you need to specify this and lock it down, or whether you can allow implementations to find the best patterns for them (perhaps with some recommendations).

Cheers,


--
Mark Nottingham   https://www.mnot.net/

v2.23.0 | Report a Bug | By Email