[byteio-wg] FW: BOUNCE byteio-wg at ggf.org: Non-member submission from [Peter Kunszt <peter.kunszt at cern.ch>]
Mark Morgan
mmm2a at virginia.edu
Thu Sep 15 08:42:19 CDT 2005
Peter's email bounced.
> -----Original Message-----
> From: owner-byteio-wg at ggf.org [mailto:owner-byteio-wg at ggf.org]
> Sent: Wednesday, September 14, 2005 5:22 PM
> To: owner-byteio-wg at ggf.org
> Subject: BOUNCE byteio-wg at ggf.org: Non-member submission from
> [Peter Kunszt <peter.kunszt at cern.ch>]
>
> >From owner-grdfm-byteio-wg at mailbouncer.mcs.anl.gov Wed Sep
> 14 16:21:38
> >2005
> Return-Path: <owner-grdfm-byteio-wg at mailbouncer.mcs.anl.gov>
> X-Original-To: grdfm-byteio-wg at mailbouncer.mcs.anl.gov
> Delivered-To: grdfm-byteio-wg at mailbouncer.mcs.anl.gov
> Received: from localhost (localhost [127.0.0.1])
> by mailbouncer.mcs.anl.gov (Postfix) with ESMTP id 4E68312A7F;
> Wed, 14 Sep 2005 16:21:38 -0500 (CDT)
> X-Greylist: delayed 61 seconds by postgrey-1.21 at
> mailbouncer.mcs.anl.gov; Wed, 14 Sep 2005 16:21:33 CDT
> Received: from cernmxlb.cern.ch (cernmx07.cern.ch [137.138.166.171])
> by mailbouncer.mcs.anl.gov (Postfix) with ESMTP id 7C5AE12A72;
> Wed, 14 Sep 2005 16:21:33 -0500 (CDT)
> DomainKey-Signature: a=rsa-sha1; c=nofws; s=beta; d=cern.ch; q=dns;
>
> h=received:message-id:date:from:to:subject:mime-version:content-type;
>
> b=fHntbWcE6W2b9wQJnRWbU+PO+ynTUBBuseMit2MaM5mLhAIxXYZ1N0fq9Vy2
> +AGNeKYjexPykwuKoDR0XtbRfgWxjV8Ud1tAnorYf1pqCs21NjA4ye16EPXCkcYY3Mz/;
> Keywords: CERN SpamKiller Note: -51 Charset: west-latin
> X-Filter: CERNMX07 CERN MX v2.0 050628.1122 Release
> Received: from cernfe02.cern.ch ([137.138.28.243]) by
> cernmxlb.cern.ch with Microsoft SMTPSVC(6.0.3790.1830);
> Wed, 14 Sep 2005 23:20:30 +0200
> Received: from [129.57.112.206] ([129.57.11.105]) by
> cernfe02.cern.ch with Microsoft SMTPSVC(6.0.3790.1830);
> Wed, 14 Sep 2005 23:20:26 +0200
> Subject: Re: Draft Charter for Data Movement Interface
> Standardization WG
> From: Peter Kunszt <peter.kunszt at cern.ch>
> To: "William E. Allcock" <allcock at mcs.anl.gov>
> Cc: ogsa-d-wg at ggf.org, gsm-wg at ggf.org, byteio-wg at ggf.org,
> James Casey <James.Casey at cern.ch>, Ravi Madduri
> <madduri at mcs.anl.gov>
> In-Reply-To: <43284C53.2040305 at mcs.anl.gov>
> References: <43284C53.2040305 at mcs.anl.gov>
> Content-Type: multipart/signed; micalg=sha1;
> protocol="application/x-pkcs7-signature";
> boundary="=-Fbuwhse1ldSoT2mWbyvb"
> Organization: CERN
> Date: Wed, 14 Sep 2005 23:20:58 +0200
> Message-Id: <1126732858.2843.7.camel at localhost.localdomain>
> Mime-Version: 1.0
> X-Mailer: Evolution 2.2.2
> X-OriginalArrivalTime: 14 Sep 2005 21:20:27.0056 (UTC)
> FILETIME=[2060EB00:01C5B972]
> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at
> mailbouncer.mcs.anl.gov
>
>
> --=-Fbuwhse1ldSoT2mWbyvb
> Content-Type: text/plain
> Content-Transfer-Encoding: quoted-printable
>
> hi bill
>
> i agree that standardization on interfacing=20
> to file transfer services is important. i would like
> to put in another aspect in addition to the ones you mention,
> which is the scheduling aspect: i.e. there will be 'local' schedulers
> which move data on a single network link as opposed to
> superschedulers which take also the network topology and
> network optimizations into account. so this will relate
> to GRAAP and GHPN and probably also the job description
> language groups (forgot the acronym). it will actually be
> an extremely interesting showcase of how all these efforts
> can be 'harmonized' into an easy and useful spec or not.
>
> peter
>
> On Wed, 2005-09-14 at 11:14 -0500, William E. Allcock wrote:
> > Sorry for the re-send, I typoed the byte-io mail list, yet again.
> >=20
> > All,
> >=20
> > Sorry for the SPAM, but I sent this to the "likely
> suspects" who might
> > be interested. I have a proposed BOF (waiting for AD approval) to
> > discuss standardizing an interface for invoking data
> movement. There
> > are several of them out there already. CERN has the File Transfer
> > System (FTS), the gsm-wg has SRM copy, Globus has the Reliable File
> > Transfer (RFT) service, etc.. I don't think there will be
> any argument
> > that there is a need for such standardization, the hard part will be
> > scoping the extent of what we will work on. For instance, all the
> > examples above are file based, but ideally, this interface
> would work
> > for any data that can be addressed.
> >=20
> > I expect that that the BOF will be centered around scoping
> the working
> > group, but I think we should (and approval of the BOF depends on)
> > getting some initial discussion around the scope. So...
> here it goes:
> >=20
> > I think the obvious thing is that it needs to be able to
> have the basic
> > functionality presented by FTS, RFT, and SRM-copy, however
> the devil is
> > in the details, so I will break this up into "blocks of
> functionality":
> >=20
> > Lets start with naming. What will this service accept as
> valid names
> > for entities that it will move? URLs? EPRs? Will logical
> file names be
> > accepted or should they be translated outside this service?
> >=20
> > Related to the naming is what type of data will this service move?
> > Files? video streams? the output of simulations? the
> output of database
> > queries? Can we make this a service that any service that
> wants to move
> > data can simply invoke it? Note that I am differentiating data from
> > messages. You would not use this to send the result from a
> service that
> > summed a bunch of numbers, that would simply be a SOAP
> response... IMHO :=
> -).
> >=20
> > Can we make a generic module that would allow this
> functionality to be
> > applied to any service that exposes the byte-io interface?
> Does that
> > affect the interface or is it just an implementation issue?
> >=20
> > Can we make this service transport mechanism agnostic?
> both application
> > transport (GridFTP vs HTTP vs ...) as well as network
> transport (TCP vs
> > UDP vs UDT vs ...). My concern here is that I am not sure
> SOAP has the
> > functionality we need. To do this, I wonder if we need the
> equivalent
> > of a union in C, so that the parameters specified are based on the
> > transport(s) chosen. For instance, if you use TCP you need
> to specify a
> > buffer size, but not for UDP. GridFTP specifies streams and data
> > channel authentication, but HTTP does not.
> >=20
> > What about security / authorization. This is a broad
> category and we
> > should push as much as possible outside of scope via
> callouts and Policy
> > Enforcement Points (PEPs), but what about delivery
> guarantees such as AT
> > MOST ONCE, AT LEAST ONCE, EXACTLY ONCE, non-repudiation,
> etc.? I know
> > Dieter has a set of use cases that require some of this
> type delivery
> > guarantee functionality.
> >=20
> > A potentially contentious issue is whether or not these
> services will
> > use WSRF and notifications to expose (push from the
> service) or methods
> > to query the state (pull from the service). Hopefully, we
> can find a
> > way to make each optional.
> >=20
> > If we start making many optional parts to the interface, it
> will make
> > what is exposed as service metadata for brokering will become more
> > important. I would propose that we should make at a minimum a
> > recommendation for what facts about the service should be exposed.
> >=20
> > All of the existing services accept "bulk" inputs, i.e.,
> move these 100
> > files. This can be a problem when the requests become very
> large due to
> > de-serialization. Should we provide a "chunking" interface so that
> > requests can be of unlimited size?
> >=20
> > Please feel free to make comments on the above and more importantly
> > suggest other important issues we need to address.
> >=20
> > btw, once we have a mail list of our own we will quit
> spamming the other
> > lists :-).
> >=20
> > Bill
> > --=20
> > William E. Allcock
> > Argonne National Laboratory
> > Bldg 221, Office C-115A
> > 9700 South Cass Ave
> > Argonne, IL 60439-4844
> > Office Phone: +1-630-252-7573
> > Office Fax: +1-630-252-1997
> > Cell Phone: +1-630-854-2842
> >=20
> >=20
> >=20
> --=20
> ------
> CERN, 1211 Geneva 23, Switzerland
>
>
> --=-Fbuwhse1ldSoT2mWbyvb
> Content-Type: application/x-pkcs7-signature; name=smime.p7s
> Content-Disposition: attachment; filename=smime.p7s
> Content-Transfer-Encoding: base64
>
> MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQ
> AAoIID7TCCA+kw
> ggLRoAMCAQICAgZbMA0GCSqGSIb3DQEBBQUAMD0xCzAJBgNVBAYTAkNIMQ0wCw
> YDVQQKEwRDRVJO
> MQ0wCwYDVQQLEwRHUklEMRAwDgYDVQQDEwdDRVJOIENBMB4XDTA1MDkwNzE2MT
> MyNFoXDTA2MDkw
> NzE2MTMyNFowRzELMAkGA1UEBhMCQ0gxDTALBgNVBAoTBENFUk4xDTALBgNVBA
> sTBEdSSUQxGjAY
> BgNVBAMTEVBldGVyIEt1bnN6dCAzOTQ2MIGfMA0GCSqGSIb3DQEBAQUAA4GNAD
> CBiQKBgQC7wHEf
> /+u02QsolNuP4Ge1yUCUp60tSZgleZH0PH7sLKL+je7nRlB6scKhlYbknIKlDx
> t7S1mAbGt/murC
> /oIbOXf9lt1TLqG4uafdA51qBvCbBIbf4l4J//sJxbLdHxCs9G9/rmeWqooqZV
> YNnk0mg3FpyJ4a
> 4W6i9CFvwgJSZQIDAQABo4IBazCCAWcwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFg
> QU/qF+PP60GYyr
> BJ1r+1uOa/0+/P0wHwYDVR0jBBgwFoAU8kruin3jqnkHi9bdO92hpXIyfmowDg
> YDVR0PAQH/BAQD
> AgP4MFIGA1UdHwRLMEkwR6BFoEOGQWh0dHA6Ly9zZXJ2aWNlLWdyaWQtY2Eud2
> ViLmNlcm4uY2gv
> c2VydmljZS1ncmlkLWNhL2NnaS1iaW4vZ2V0Q1JMMCIGA1UdEgQbMBmBF3Nlcn
> ZpY2UtZ3JpZC1j
> YUBjZXJuLmNoMBcGA1UdIAQQMA4wDAYKKwYBBAFgCgECAzARBglghkgBhvhCAQ
> EEBAMCBaAwQgYJ
> YIZIAYb4QgECBDUWM2h0dHA6Ly9zZXJ2aWNlLWdyaWQtY2Eud2ViLmNlcm4uY2
> gvc2VydmljZS1n
> cmlkLWNhLzAfBgNVHREEGDAWgRRQZXRlci5LdW5zenRAY2Vybi5jaDANBgkqhk
> iG9w0BAQUFAAOC
> AQEAc6q3grJVkGOu04bLcKml6luSlrK3BvV0o/LxgHs+0AwfKq3m3B71BB4uY5
> SPG3fv4YoJhv/S
> aoyhMZWd8WdTacedj3m1fRfX12XzIy2Ky0KB/KrA/gdp+YMKUITqrkL8ikqYwO
> w2eacgG/5g61Zf
> OkvDpavz2bbf7HEsGBri+c4PbaCUWGu/1kkSKaIUXcEBx4kEfT2dxdD0eMl1pI
> YTNI+bhnd8RWaS
> HpDybAWWqyrsKk7E6YxP0NweTbXxkZBjRQJxW2SE00r9GycLkh3Wmse7/7AGSa
> T5/1OEfpD2p5oH
> mc3qrpqlIMc/+n+vVpCFiGvXNZC+rbfM0BIqu5jeNzGCAUgwggFEAgEBMEMwPT
> ELMAkGA1UEBhMC
> Q0gxDTALBgNVBAoTBENFUk4xDTALBgNVBAsTBEdSSUQxEDAOBgNVBAMTB0NFUk
> 4gQ0ECAgZbMAkG
> BSsOAwIaBQCgXTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQ
> EJBTEPFw0wNTA5
> MTQyMTIwNTVaMCMGCSqGSIb3DQEJBDEWBBRE1tTc9hOMd3FUwXT6Ti6nBGpJOz
> ANBgkqhkiG9w0B
> AQEFAASBgFGm4nn+N3b4PQk9DkNrvmpfKB1A+t5XVvsJBDbfhy/PVsbXF+hBY/
> kuTHlXHZlkmQA1
> mRsKPH2tiDPfeRGktNZYYpb4pYF7afuGS3yn0NPw7jKX4JGWdhUqAu+J1WJ3F9
> tHs7wORxoKVwXw
> wq2sHmeRfcpSogXAXKzDUVqdmRCLAAAAAAAA
>
>
> --=-Fbuwhse1ldSoT2mWbyvb--
>
More information about the byteio-wg
mailing list