RFC 4594

(1) According to the RFC these transfers may be classified in the category "Low-Priority-Data" because they are tolerant to packet loss (being TCP-based) but the performance would be impacted. We want transfers to be fast, so High-Throughput Data may be better choice.

(2) Ideally it would be good to differentiate between synchronous and asynchronous transfers of data. The asynchronous transfers (via FTS for example) don't have a user (or a job) waiting for the data and a lower-quality treatment of that data would have few unwanted side effects. Synchronous transfers, however, means that a user (or a job) is waiting for the data and a lower-quality service would probably mean wasted CPU, etc. Therefore it might be better to allow the services to mark the quality of service desired. They would set a DSCP value of AF11, AF12 or AF13 (sub-categories of "High-Throughput Data"), or maybe, in particular case where latency is critical, AF21, AF22, AF23 (sub-categories of "Low-Latency Data"). Because of the amount of work needed for this kind of differentiation, no work on this is planned for a near future.

For pure gLite-based applications, we do not see any other kind of traffic.

The DORII project focuses on real- (or quasi-real-) time applications and consequently have higher networking needs. DORII and EGEE are related because DORII is partially using the EGEE infrastructure. Moreover this link between EGEE and DORII will probably become stronger as we move towards EGI and consequently it would be good to have a common network monitoring solution.

Thanks to Cal Loomis for his feedback.

-- EtienneDUBLE - 19 May 2009