Subject: [Anima] Fwd: I-D Action: draft-carpenter-anima-grasp-bulk-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Sep 2017 13:41:26 +1200

Comments welcomed!

-------- Forwarded Message --------
Subject: I-D Action: draft-carpenter-anima-grasp-bulk-00.txt
Date: Mon, 11 Sep 2017 18:32:28 -0700
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Transferring Bulk Data over the GeneRic Autonomic Signaling Protocol (GRASP)
        Authors         : Brian Carpenter
                          Sheng Jiang
                          Bing Liu
	Filename        : draft-carpenter-anima-grasp-bulk-00.txt
	Pages           : 10
	Date            : 2017-09-11

Abstract:
   This document describes how bulk data may be transferred between
   Autonomic Service Agents via the GeneRic Autonomic Signaling Protocol
   (GRASP).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-carpenter-anima-grasp-bulk/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-carpenter-anima-grasp-bulk-00
https://datatracker.ietf.org/doc/html/draft-carpenter-anima-grasp-bulk-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 11 Sep 2017 23:17:35 -0400

Given our experience with file transfers, several things seem to be 
called for:

1) There should be a mechanism for the sender to initiate.  Several of 
the use cases you cite are such that the sender would better than the 
receiver when it is a good time to send the data.

2) I realize that it does not fit the pattern, but without some sort of 
position indication, this seems very fragile.  I think you need to come 
up with a way to indicate the position.

3) Unless we want to restrict this to very local environments, we really 
should have a way to resume a failed transfer at the failure point, 
rather than  start from teh beginning.

In particular, without these features, the justification for using GRASP 
rather than a better transfer protocol over the ANIMA infrastructure 
becomes very weak.

Yours,
Joel

On 9/11/17 9:41 PM, Brian E Carpenter wrote:
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Sep 2017 16:56:14 +1200

Hi Joel, thanks for the rapid comments. More in-line:

> receiver when it is a good time to send the data.

Yes, certainly. That's behind the mention that the mechanism could
be turned round for upload. Maybe it would be better to call it
push and pull, since ANIMA does not assume a hierarchy.

> up with a way to indicate the position.

It wouldn't be hard to add a block number, both for the sending side
and the acknowledgements. But then it would be very tempting to also add
a retransmission mechanism, and look, we've re-invented the wheel. So
we just have to decide where to stop in complexity.

> rather than  start from teh beginning.

Ditto. To be honest I had to stop myself adding such mechanisms, when writing
a quick prototype.
> rather than a better transfer protocol over the ANIMA infrastructure 

Well, there we might disagree. Or at least, that is the question of scope.
What do we want to assume is already installed on an autonomic node? If it's
a fully-featured host or host-like device, I would expect some existing
mechanism to be available. If it's a bare-bones device, maybe not. But in that
case, we'd want a GRASP-based mechanism to be bare-bones too*. We'd be interested
in WG opinions about this.

*Just to scale it, the client side that corresponds to the example
in the draft is about 110 lines of Python.

Thanks
   Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 12 Sep 2017 10:10:10 -0400

Even if you want a simple mechanism, I think the bidirectionality and 
block numbers would be VERY good ideas.  I think these two are critical.

Without either resumption or retransmission, there seem to be many 
environments where low complexity is valuable but the system is unlikely 
to be able to perform the transfers.
This does edge into the argument about how much size and work it would 
be to just use the code for an existing protocol.

Yours,
Joel