Re: [Spud] FW: New Version Notification for draft-hildebrand-spud-prototype-02.txt

Patrick McManus <mcmanus@ducksong.com> Fri, 06 March 2015 20:52 UTC

Return-Path: <mcmanus@ducksong.com>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85841A854D for <spud@ietfa.amsl.com>; Fri, 6 Mar 2015 12:52:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 S-FKoGF2pvj7 for <spud@ietfa.amsl.com>; Fri, 6 Mar 2015 12:52:28 -0800 (PST)
Received: from linode64.ducksong.com (li629-102.members.linode.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 7464D1A6F12 for <spud@ietf.org>; Fri, 6 Mar 2015 12:52:24 -0800 (PST)
Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) by linode64.ducksong.com (Postfix) with ESMTPSA id 8B1F73A026 for <spud@ietf.org>; Fri, 6 Mar 2015 15:52:22 -0500 (EST)
Received: by qgdq107 with SMTP id q107so15672530qgd.6 for <spud@ietf.org>; Fri, 06 Mar 2015 12:52:22 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.140.236.211 with SMTP id h202mr22429440qhc.88.1425675142421; Fri, 06 Mar 2015 12:52:22 -0800 (PST)
Received: by 10.140.104.115 with HTTP; Fri, 6 Mar 2015 12:52:22 -0800 (PST)
In-Reply-To: <CA+9kkMDSMMUByAMOc8gSyMajyKj0ZtZzmFPg+J7bz-6AYkFYhw@mail.gmail.com>
References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> <CA+9kkMDSMMUByAMOc8gSyMajyKj0ZtZzmFPg+J7bz-6AYkFYhw@mail.gmail.com>
Date: Fri, 6 Mar 2015 15:52:22 -0500
Message-ID: <CAOdDvNrRcMCnWMzBvL0Do16mmiajeR4OJRx36cxnppuaD7+81w@mail.gmail.com>
From: Patrick McManus <mcmanus@ducksong.com>
To: Ted Hardie <ted.ietf@gmail.com>
Content-Type: multipart/alternative; boundary=001a11359dae6de2f80510a4dce6
Archived-At: <http://mailarchive.ietf.org/arch/msg/spud/Reu514EXHWtar3xJZ2ktksNeDoo>
Cc: "Joe Hildebrand \(jhildebr\)" <jhildebr@cisco.com>, "spud@ietf.org" <spud@ietf.org>
Subject: Re: [Spud] FW: New Version Notification for draft-hildebrand-spud-prototype-02.txt
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Session Protocol Underneath Datagrams <spud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spud>, <mailto:spud-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/spud/>
List-Post: <mailto:spud@ietf.org>
List-Help: <mailto:spud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spud>, <mailto:spud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Mar 2015 20:52:29 -0000

First - Thanks Joe and Brian. I have a few margin notes to share :)

Next, I may just be confused because I have read the text less than the
authors at this point, but it seems as if unidirectional flows are off the
table.. the text doesn't really say this, but the open-ack seems to imply
it. There certainly are unidirectional udp flows but some clarification
would help.

Thirdly, is there advice given or implied for middleboxes that see data
spud packets on opening tubes? The only thing I really see about the
opening state is the diagram - but the diagram applies to the endpoint, not
to the middlebox state, right? I'm concerned the text will read like there
needs to be a full rtt handshake before data packets can flow on a spud
tube and there are counter examples to things we would like to run on spud
already.

Fourthly, there are a couple "reserved bits MUST be zero".. should that be
"senders MUST set to zero, receivers MUST ignore "?

Fifthly, on the topic of whether tube-ids need a consistent 5 tuple, I
think there are several cases where it would be nice if they didn't..  load
balancers are a good example - a request is sent to a central service that
parses it and dispatches it to the best back end server.. historically that
server needs to lie about its address somehow when sending the reply
(either via proxy or more likely via spoofing - and if spoofed you need to
figure out the ack traffic). It would be cool to have that all in one tube
with real addresses so the transport could decide how to deal with those
issues.

Sixthly, am I misreading the 8.2 MUST that SPUD enabled NATs need to share
internal addressing info on the external side of the NAT? Is that really a
MUST - some folks will be frothing at the mouth with the perceived
information disclosure issues.

Again, thanks for this.



>