<p><strong>SRM - tape T0 - T1 transfers</strong></p>

<p>Paul (with Andrea and Mihai) presented 3 stages possible stages to change SRM authorization mechanism to get to use SRM with HTTP.</p>

<ol>
	<li>X509&nbsp; + macaroons will require some reorganisation of the code between gfal and FTS</li>
	<li>X509 + JWT at first sight no development but after further discussion it may still need some</li>
	<li>JWT only requires some major changes.</li>
</ol>

<p>CTA should work because it is based on xrootd and we have HTTP working on it If we go down the direction of SRM+http do we need to take into account also castor? Agreement that castor shouldn't be touched and we should keep it using gsiftp.</p>

<p>There is no plan to proactively remove gsiftp until we are on more solid ground with other protocols. The plan is to move the infrastructure to use something else but to keep it as backup</p>

<p>Same for SRM in this way we can prolong the SRM klife which is a well known protocol and all T1s know how to deal with it. We can think about removing SRM when we have a better QoS experience.</p>

<p>rucio will need some adjustment too as it assumes gsiftp atm</p>

<p>Action: Mihai will create few slides for next meeting with a plan to enable 1 and 2 in FTS gfal. Andrea volunteered to help with 2. so we have something that can be tested for both setup by the end of the year.</p>

<p>Christophe (LHCb) and Michael (CTA) are on board with the plan.</p>

<p><strong>Experiments production</strong></p>

<p>Petr did some stress testing involving different storages and protocols. two problem highlighted</p>

<ul>
	<li>dcache interrupts abruptly the transfers when using xrootd, This happens mostly between FZK and US sites, so it might be due to a TCP timeout. There was some discussion about this but it will continue offline.</li>
	<li>Abrubtly interrupted transfer errrors appear also in production transfers for http-tpc and shold be looked at.</li>
	<li>infn-t1 (but not only) has much worst HTTP-TPC transfer rates than gsiftp.</li>
	<li>smoke tests failed when both the storage and the curl client try to use TLS 1.3. For now a work around to use TLS 1.2 has been put in plae, but we have to worry in case client upgrades start causing failures. We need to understand better how we can avoid this. This concerns clients on centos7 and 8. Alessandra didn't notice any problem when running smoke tests because so far she run them against DPM and DPM doesn't use TLS 1.3</li>
	<li>further points in the contribution minutes</li>
</ul>

<p>Question from Julia for next upgrade for dcache sites which is the dest dcache version to upgrade to? Latest! to avoid bugs already fixed. The choice between 5.2.x and 6.2.x is up to the site.</p>

<p>ATLAS has 20 sites configured as active destinations. They use HTTP with any sites that has it enabled, so the matrix is quite large.</p>

<p><br>
<strong>AOB</strong></p>

<ul>
	<li>WLCG workshop in November will concentrate on storage. There is a call for sites to present their status and plans regarding storage. The aim is to produce a roadmap for storage leading up to HL-LHC. Any volunteer site add themselves in the google doc</li>
	<li>Paul asked is there is a deadline. [info from after the meeting] The plan is to collect talks within the next two weeks</li>
</ul>

<p>&nbsp;</p>