Re: [Spud] Details about PLUS BoF

Tom Herbert <> Sun, 10 July 2016 21:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A59CD12D094 for <>; Sun, 10 Jul 2016 14:35:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dIepn2CXqP5v for <>; Sun, 10 Jul 2016 14:35:43 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 541B812D08D for <>; Sun, 10 Jul 2016 14:35:43 -0700 (PDT)
Received: by with SMTP id q83so22091130iod.1 for <>; Sun, 10 Jul 2016 14:35:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=rkykjBsqCBWjvrGeAmL1ww0tmVqsinGB9HIOya0cJKE=; b=Xkkwk3iqI2Zt5lCVYSmbrAbIp8wF9f4H7YQqKxBHjvQyiOxFsRHdEAFL3QD4olhsWl 5o3OcPcAQP9WXPJ7eQCFwDQbEebYr8T/Tdqq6K9mmGoC86ZLmIg7Z1B9xB+bBNX/g4xB r69P/1seEbWn8cMmvVo2f6VtNOqIe8btXp59gPc5/GIwS9XXg21MLvMibiEV4iofS/8u wTO7N8eej2Ckl+BygfsQ51jkfLbVlNtjHmejML+LH4OhrGkY7eETr18CuTSrXLy46jVD q1vEyqU70Q+zs5L+/6gBn29uEEFYcfjpCLPE/0rxCst8epi90aeUY95EN5v72K3WLABZ QNZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=rkykjBsqCBWjvrGeAmL1ww0tmVqsinGB9HIOya0cJKE=; b=Jau2Vn3c1AU89vlX9JCQhZhMy5pVeuLCzda5r3IyQXXMQXo9forZ/o8Zq3py1K+xMK e0pzfNn/CmMoCISp+kFkaeydpkaG2VTcYiZid/EcG7ejkdJXlLxFDKxopZKzyeDNCFpA G7f4gEi9XdFQlgoE5Wex6ZNmdGSor6wz5IrKxi6P17V6FXswhr7PguypgEJZBYpnBY7j oPdEs95w5t+xkucA6jTtg/BaaxnNMPDykiHt5F0OSGLSgkwikQS/UDRu9Gp8j3eJcOE1 5vvdXbEX3lX5J6JOurZRJyIar0P57o/fqf9veWAQ+k4XmXslcNabPiKkLK7+oW+Ou883 jeIA==
X-Gm-Message-State: ALyK8tLTctWAUx/kQTPbRguO4qLw6l1K4XtTwgcZtzXsP7btRkSAOfqA78gBR7xMdEvdxmmCw602fksHwBq7ig==
X-Received: by with SMTP id v71mr10602789ioi.107.1468186542527; Sun, 10 Jul 2016 14:35:42 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 10 Jul 2016 14:35:41 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: Tom Herbert <>
Date: Sun, 10 Jul 2016 16:35:41 -0500
Message-ID: <>
To: Brian Trammell <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: Ted Hardie <>, Natasha Rooney <>, spud <>
Subject: Re: [Spud] Details about PLUS BoF
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Session Protocol Underneath Datagrams <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 10 Jul 2016 21:35:44 -0000

> I hope we do. Restoring the ability to safely treat IP as a packet-switched architecture is one of the goals of this work (see the SPUD use cases draft, section 6 [4]). As of today, since common wisdom holds that TCP performance *sucks* if you reorder packets, quite a lot of effort goes into reducing reordering within a flow, and it turns out an excellent way to do that is to make sure all the packets in a flow hit all the same queues in the absence of rerouting. How can a transport signal that reordering is tolerable today?

I believe that TCP performance *sucks* with OOO packet is mostly a
myth at this point. In the Internet, bad TCP performance is dominated
by packet loss and retransmissions (which I guess leads to OOO but
that's a secondary issue then). In the datacenter where loss is low we
do typically prefer in order delivery to keep variance down. But in
order delivery has never be a requirement there either (except when
people have attempt to use protocols that really require in order like
FCoe, RDMA). There are also results that show all packets could
purposely be sent over different paths in a well engineered with good
effect but would generate OOO
Also, as described in that paper, modern TCP stacks are robust with
some amount of reordering.

A transport can signal that reordering is tolerable by changing the
IPv6 FlowID on every packet. This would be one way to accomplish
Random Packet Spraying without needing special support in network
devices as described in the paper above.

>> Consider that any smart phone is now typically
>> multi-homed to both a mobile network and a WIFI network. It's pretty
>> obvious that we'd like to seamlessly transition from using one network
>> to the other without breaking established connections.
> This world has existed for a couple of decades now: SCTP (where it deploys) and MPTCP do this already by building a session over multiple transport connections.
It's not quite the same, these require that the transport layer or
network understand network topology. That breaks down for instance if
devices are behind a NAT which is change source addresses for existing
connections. As I mentioned previously, NAT state eviction causing
connections to be dropped is one thing we want to fix with UDP based
transport protocols (e.g. by disassociated location).