[Spud] multicast spud

Caitlin Bestler <caitlin.bestler@nexenta.com> Tue, 24 March 2015 00:26 UTC

Return-Path: <caitlin.bestler@nexenta.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 792221A90DB for <spud@ietfa.amsl.com>; Mon, 23 Mar 2015 17:26:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 Fv4JWkOnSY21 for <spud@ietfa.amsl.com>; Mon, 23 Mar 2015 17:26:09 -0700 (PDT)
Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) (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 203B31A90C7 for <spud@ietf.org>; Mon, 23 Mar 2015 17:26:09 -0700 (PDT)
Received: by oiag65 with SMTP id g65so155127828oia.2 for <spud@ietf.org>; Mon, 23 Mar 2015 17:26:08 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=hhTohoHm7s+FZTm23MTxa9YvihGcAbYAu3vMQ24jrLg=; b=Bcj3hfoHCRAak6p6Qryb/xPckMnIw4wNRcKunZbzBcVZyi1aUdoHNbxCXBISjBox3U AHfW8MPLWL6NluEza5hzigZlilbpY0BYdZsR3Q+Dr30A4z6BvF8PEyakNCNNLEkvOKO9 0fG0vTLtJg4Ng4uK1aVqWgq7kjjey1yUvq5nF0oeG5TdyWfnNOKOf0Xxy31U9Jt3VqGS 1CxE5fd7lRtgjlD0gQQqorC1ivh0idz48XRd3g0mplnFFHwJyuzTwoVve7ePc6+Z7n3r o3UZhMYYFwFGpEv1beQSuqUIIOkf96uF5HrfS0wAlOJA8zaC3DQ5D02pUcvSMyjYoPJ0 rDwQ==
X-Gm-Message-State: ALoCoQm5Y8NpcvELGB+G9yYvpSTxPWAAYfMkH9ju8jeyZNVGfAUes2vaEqwyL6P7N2lSDPQC0M+h
X-Received: by 10.60.42.171 with SMTP id p11mr1308510oel.41.1427156768562; Mon, 23 Mar 2015 17:26:08 -0700 (PDT)
Received: from Macintosh.local (rrcs-64-183-197-98.sw.biz.rr.com. [64.183.197.98]) by mx.google.com with ESMTPSA id bc12sm1316708obd.21.2015.03.23.17.26.07 for <spud@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Mar 2015 17:26:07 -0700 (PDT)
Message-ID: <5510AF1F.4090802@nexenta.com>
Date: Mon, 23 Mar 2015 17:26:07 -0700
From: Caitlin Bestler <caitlin.bestler@nexenta.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: spud@ietf.org
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/spud/19hPvEeN6bF6xyxmxfJyehfT_hU>
Subject: [Spud] multicast spud
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: Tue, 24 Mar 2015 00:26:10 -0000

The requirements section includes multicast in the list, but the details 
need
some more work. For example: "A tube may be closed by either endpoint."

A multicast session does not have a pair of endpoints. it has an 
initiator (or
maybe more) and zero or more receivers.

The opening of a multicast session obviously needs a different procedure 
than
what is used for unicast.

Nexenta's object cluster systems using multicast UDP to replicate 
storage chunks
within a data center. This relies upon a concept of "Transactional 
multicast" that
is described in draft-bestler-transactional-multicast-00.

This approach to multicast addressing is very compatible with SPUD, 
although the
specific project did not need it because multicasting is limited to a 
single subnet.
But SPUD could enable verifying path details for a wider range 
transactional multicast
delivery. Confirming the MTU, for example, would be essential for 
delivering across
middleboxes.



Other comments:

The "CBOR Map" is unclear as described. I presume that this is the 
balance of the
UDP payload that is somehow mutually exclusive from user-content. That 
should
be explicitly stated and probably made clear in the diagram.

There is a rationale that is not explained. If a tube is a specific set 
of datagrams
there is obviously some method of enumerating what is a complete set. 
SPUD is
deliberately limiting its knowledge of this to knowing the first and 
last datagram
because the middleboxes do not need to know how to validate the payload. 
Therefore
while this information is needed, the protocol will not constrain how it 
is encoded.