From swc at iis.sinica.edu.tw Sun Jan 9 22:10:08 2011 From: swc at iis.sinica.edu.tw (Sheng-Wei (Kuan-Ta) Chen) Date: Mon, 10 Jan 2011 14:10:08 +0800 Subject: [e2e] [Apologies if you receive this more than once] Message-ID: <001101cbb08d$08814d00$1983e700$@sinica.edu.tw> [Apologies if you receive this more than once] +++++++++++++++++++++ [ NOSSDAV 2011 Call for Papers ] +++++++++++++++++++++++ The 21th International Workshop on Network and Operating Systems Support for Digital Audio and Video June 2-3, 2011 Vancouver, British Columbia, Canada http://nss.cs.ubc.ca/nossdav2011/ NOSSDAV 2011 is the 21th anniversary of SIGMM's leading workshop on network and operating systems support for digital audio and video. The workshop, hosted at the University of British Columbia (UBC), will continue to focus on emerging research topics, controversial ideas, and future research directions in the area of multimedia systems research. As in previous years, we will maintain the focused single-track format a setting that stimulates lively discussions among the senior and junior participants. NOSSDAV encourages experimental research based on real systems and real data sets. Public availability of the source code and data sets discussed in papers presented at NOSSDAV is highly encouraged. For NOSSDAV 2011, we will accept papers on broad ranges of topics related to the transmission and presentation of digital audio/video objects. We are particularly interested in soliciting articles that discuss system-level support for distributed social media, as well as papers that focus on enabling multimedia applications in distributed cloud. Other topics of interest include (but are not restricted to): * OS, middleware and network support * Overlay networks * Media streaming, distribution and storage support * Web 2.0 systems and social networks * Media sensor and ad hoc networks / embedded systems * Multicore architecture support * Wireless and mobile multimedia systems / network processor support * Networked GPUs, graphics and virtual environments * Networked games / real-time immersive systems * Multimedia communications and system security * Grid/Cloud computing support Please contact the workshop co-chairs to check if your topic is within the scope of NOSSDAV. Papers will be judged on their relevance, technical content and correctness, and the clarity of presentation of the research. Papers should not be under review at another venue nor previously published elsewhere. Submissions should be at most SIX pages, using standard ACM proceedings style. We expect these submissions to be the kernel of what will eventually lead to full-length papers at high-quality conferences or journals. Important Dates Paper Submission Deadline: 24 Feb 2011 Decision Notification: 24 Mar 2011 Camera Ready Due: 7 Apr 2011 For more information, please visit the workshop website at http://nss.cs.ubc.ca/nossdav2011/ From alejandro.canovas.cp46700 at gmail.com Wed Jan 12 15:43:02 2011 From: alejandro.canovas.cp46700 at gmail.com (Alejandro Canovas) Date: Thu, 13 Jan 2011 00:43:02 +0100 Subject: [e2e] Last two weeks | ENERGY 2011 || May 22-27, 2011 - Venice, Italy Message-ID: <201101122343.p0CNh18N017935@smtp.upv.es> INVITATION: ================= Note that the submission deadline has been extended to January 25. Please consider to contribute to and/or forward to the appropriate groups the following opportunity to submit and publish original scientific results. ================= ============== ENERGY 2011 | Call for Papers =============== CALL FOR PAPERS, TUTORIALS, PANELS ENERGY 2011: The First International Conference on Smart Grids, Green Communications and IT Energy-aware Technologies May 22-27, 2011 - Venice, Italy General page: http://www.iaria.org/conferences2011/ENERGY11.html Call for Papers: http://www.iaria.org/conferences2011/CfPENERGY11.html Submission deadline: January 25, 2011 Technical Co-Sponsors: - IEEE Consumer Electronics Society - Microsoft Israel R&D Center Sponsored by IARIA, www.iaria.org Extended versions of selected papers will be published in IARIA Journals: http://www.iariajournals.org Please note the Poster Forum and Work in Progress options. The topics suggested by the conference can be discussed in term of concepts, state of the art, research, standards, implementations, running experiments, applications, and industrial case studies. Authors are invited to submit complete unpublished papers, which are not under review in any other conference or journal in the following, but not limited to, topic areas. All tracks are open to both research and industry contributions, in terms of Regular papers, Posters, Work in progress, Technical/marketing/business presentations, Demos, Tutorials, and Panels. Before submission, please check and conform with the Editorial rules: http://www.iaria.org/editorialrules.html ENERGY 2011 Topics (topics and submission details: see CfP on the site) Fundamentals in Smart Grids Architectures for Smart Grids; Smart Grids Modeling; Middleware for Smart Grids; Energy-efficient communication for Smart Grid infrastructures; Smart Grid Specific Protocols (DNP3, ICCP); Scalable infrastructures for Smart Grids; Service-oriented architectures for Smart Grids; Standards for Smart Grids; Implementation and projects on Smart Grids; Innovations on Smart Grids Green communications Energy-efficient communication protocols and power management; Green communications (energy efficient modulation, coding, resource allocation); Optimization of energy-efficient protocols/algorithms; Cross-layer optimization techniques for efficient energy consumption; Energy-efficient scheduling algorithms; Voltage and frequency scaled networks protocols; Energy-efficient transmission technologies; Energy-efficient protocols/algorithms in physical and IP layers; Energy-efficient radio resource management and routing; Hardware energy-efficiency systems; Virtualization techniques for energy efficiency; Simulation/modeling tools for energy efficient solutions; Green computation Energy-efficient service provisioning; Energy-efficient networking; Technology as Green Enablers (Grid, Cloud, Data Centers, Virtualization); Energy-efficient methodologies for infrastructure; Cooling/heating efficient energy; Power distribution; Green service life cycle; Energy efficiency planning Green performance metrics; Energy and performance profiling; Energy consumption and energy efficiency analysis; Energy demand prediction for appliances in industrial and home environments; Green certificates; Green maturity models Energy-aware vehicular technologies Alternative vehicular energy; Hybrid car energy and new battery technologies; Smart charging infrastructure; New forms of energy storage; Integration of electric vehicles and battery technology; Monitoring and sense-and-control of charging; Energy-aware vehicular sensor networks; Pricing models for charging stations, roaming across territories; Systems and computing for electric vehicle; Car energy optimization; Pricing models for charging stations Smart Grids technologies Sensors for Smart Grids; Wireless communications and networks for the Smart Grid last mile; Transport layer mechanisms for Smart Grids; IP interoperability in the Smart Grid; Multicast and secure multicast for the Smart Grids; Intelligent electronic devices (IED) for Smart Grids; Precision time synchronization protocols for the Smart Grids Smart Grids Transmission Infrastructure High Voltage DC (HVDC); Flexible AC Transmission Systems (FACTS); Automatic Correction Substations; Phasor Measurement Units (PMU); Optical Sensors (OS) Smart Grids management and control AMI (Advanced Metering Infrastructure); QoS, latency and reliability in Smart Grids; Security (including wireless, wire-line, broadband over power lines) in Smart Grids; Data aggregation, privacy considerations, and network data anonymization; Mobility issues in Smart Grids; Demand - response with dynamic pricing on a real-time in Smart Grids; Intelligent status monitoring in Smart Grids; Fault tolerance and disaster recovery in Smart Grids; Load balancing in Smart Grids; Dynamic discovery in Smart Grids Software for Smart Grids Management software for Smart Grids; End-User software application for Smart-grids; Firmware for Smart devices; Smart Grid modeling applications; Smart Grids applications Geographic Information Systems (GIS); Energy Management Systems (EMS); Demand Response Control; Meter Data Management System (MDMS); Home Area Networking (HAN) technologies with smart meters; Wind energy integration in Smart Grids; Disseminating power grid status information in Smart Grids; Solar, wind and energy storage integration in Smart Grids; Business issues for Smart Grids; Resilient operations against physical and cyber attacks, and natural disasters; Power quality operations in a digital economy; Anticipation and responses to system disturbances in a self-healing manner applications Smart Grids and social infrastructure challenges Utilities and transportation assets; Smart Grid efficiency, security and reliability; Smart Grids and renewable technologies; Enabling active participation by consumers; Accommodate all generation and storage options; Enable new products, services, and markets; Optimize asset utilization and operating efficiency; Legislation on Smart Grid Advanced IT energy-aware technologies Communications, sensors, wireless, mobility; Integration of consumer with utility's infrastructure; Automation, including billing and monitoring (smart meter integration); User interfaces (e.g., personal mobile devices); Appliance integration of smart appliances (communications interfaces, data formats); Integration of customer perception and response; Integration of solar technologies; Integration of wind mill technologies; Energy storage integration - battery, hydro, mechanical; Renewable energy - energy source integration models; Sensors use for energy management Challenges in Smart Grids and IT-energy aware technologies Scaling up; Cyber-infrastructure and cyber-security - technologies, models; Open-systems wireless and communications interface software; Security of information technology; Governments and corporation visions; Social perception and support; Standardizing approach ENERGY Advisory Chairs Stefan Mozar, CCM Consulting / CQ University - Sydney International Centre, Australia Mehrdad (Mark) Ehsani, Texas A&M University - College Station, USA Petre Dini, Concordia university, Canada / China Space Agency Center, China Mardavij Roozbehani, Massachusetts Institute of Technology, USA ENERGY Industry Liaison Chairs Dave Cavalcanti, Philips Research North America, USA Marco Di Girolamo, Hewlett-Packard Company - Cernusco sul Naviglio, Italy Thomas M. Overman, Boeing Energy Cyber Security, USA Angelantonio Gnazzo, Telecom Italia - Torino, Italy Dragan Obradovic, Siemens AG, Germany Avi Mendelson, Microsoft Corporation, USA ENERGY Special Area Chairs on Nano-Grids Peter Mueller, IBM-Zurich, Switzeland ENERGY Special Area Chairs on Efficient Energy Consumption Giorgio Nunzi, NEC Europe Ltd. - London, UK ENERGY Special Area Chairs on Smart Grids Ritwik Majumder, ABB AB / Corporate Research Center - Vasteras, Sweden ENERGY Special Area Chairs on IT-energy- aware, Planning Brian P. Gaucher, IBM Research Division - Yorktown Heights, USA ENERGY Special Area Chairs on Grid, Green Communication Gargi Bag, ABB Corporate Research, Sweden Ken Christensen, University of South Florida, USA ENERGY Special Area Chairs on Vehicular Grzegorz Swirszcz, IBM Watson Laboratory, USA ENERGY Publicity Chairs Luciano Bertini, Fluminense Federal University, Brazil Cathryn Peoples, University of Ulster, UK Committee: http://www.iaria.org/conferences2011/ComENERGY11.html ==================== Alejandro Cánovas Solbes IARIA Publicity Board From garmitage at swin.edu.au Sun Jan 16 14:00:37 2011 From: garmitage at swin.edu.au (grenville armitage) Date: Mon, 17 Jan 2011 09:00:37 +1100 Subject: [e2e] DIFFUSE v0.1: IPFW traffic classification using statistical properties Message-ID: <4D336A85.8090905@swin.edu.au> Hi list, We believe this may be of some interest to list members, and apologise in advance for any duplicates you may receive. We are pleased to announce DIFFUSE v0.1, our first release of a system enabling FreeBSD's IPFW firewall subsystem to classify IP traffic based on statistical traffic properties. With DIFFUSE v0.1, IPFW computes statistics (such as packet lengths or inter-packet time intervals) for observed flows, and uses ML (machine learning) techniques to assign flows into classes. In addition to traditional packet inspection rules, IPFW rules may now also be expressed in terms of traffic statistics or classes identified by ML classification. This can be helpful when direct packet inspection is problematic (perhaps for administrative reasons, or because port numbers do not reliably identify classes of applications). DIFFUSE also enables one instance of IPFW to send flow information and classes to other IPFW instances, which then can act on such traffic (e.g. prioritise, accept, deny, etc) according to its class. This allows for distributed architectures, where classification at one location in your network is used to control fire-walling or rate-shaping actions at other locations. DIFFUSE v0.1 contains an example classifier model for identifying real-time first person shooter game traffic. In the next release we will include a classifier model to detect Skype traffic. The project site (http://caia.swin.edu.au/urp/diffuse) contains a more comprehensive introduction, including application examples, links to related work and documentation describing the design of our software. DIFFUSE v0.1 is a set of patches for FreeBSD-CURRENT, and can be obtained directly from http://caia.swin.edu.au/urp/diffuse/downloads.html The software was developed as part of the DIFFUSE research project at Swinburne University's Centre for Advanced Internet Architectures. The project has been made possible in part by a grant from the Cisco University Research Program Fund at Community Foundation Silicon Valley. We welcome your feedback and hope you enjoy playing with the code and tools. Cheers, Sebastian Zander and Grenville Armitage -- Professor Grenville Armitage Head, Telecommunications Engineering Academic Group Director, Centre for Advanced Internet Architectures Faculty of Information and Communication Technologies Swinburne University of Technology, Australia http://caia.swin.edu.au From alexander.zimmermann at comsys.rwth-aachen.de Mon Jan 17 06:35:15 2011 From: alexander.zimmermann at comsys.rwth-aachen.de (Alexander Zimmermann) Date: Mon, 17 Jan 2011 15:35:15 +0100 Subject: [e2e] [tcpm] RTTM + timestamps In-Reply-To: <5FDC413D5FA246468C200652D63E627A0C5BBDCC@LDCMVEXC1-PRD.hq.netapp.com> References: <5FDC413D5FA246468C200652D63E627A0C4E3E0E@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0C5BBDCC@LDCMVEXC1-PRD.hq.netapp.com> Message-ID: <687258D3-D8AF-4F33-BACC-A6F0F8468E80@comsys.rwth-aachen.de> Hi Richard, some rash thoughts... Am 17.01.2011 um 14:48 schrieb Scheffenegger, Richard: > Hi group, > > After having received some feedback off-list so far, I would like to summarize what I learned so far. Also, I invite everyone to discuss these points. There are benefits for the research community both empirical as well as theoretical, as well as mobile and high-speed network operators and implementers. > > > o) one-way delay based (and delay variation based) congestion controls would benefit from knowing the clock resolution on both sides. Some research in that area is done by Mirja Kuehlewind and Bob Briscoe (http://bobbriscoe.net/pubs.html#chirp_impl), as well as David Hayes (http://caia.swin.edu.au/reports/100219A/CAIA-TR-100219A.pdf) > > o) RTT variance during loss episodes is not deeply researched. Current heuristics (RFC1122, RFC1323, Karn's algorithm, RFC2988) explicitly exclude (and prevent) the use of RTT samples when loss occurs. Eh... With RFC1323, you take RTT samples when loss occurs. > However, solving the retransmission ambiguity problem - The problem is solved, isn't it? Eifel? > and the related reliable ACK delivery problem - may allow the refinement of these algorithms further, as well as enabling new research to distinguish between corruption loss (without RTT / one-way delay impact) and congestion loss (with RTT / one-way delay impact). This is not new. Ask Michael Welzl ;-) And a citation form Sally Floyd to that topic: "Inferring congestion vs. corruption at the transport level. There are also papers that investigate algorithms for the transport end-nodes to infer that certain drops are from corruption rather than congestion, without explicit feedback from routers. My own view would be that the burden is on such approaches to show that they are not ignoring legitimate congestion indications from the network." eg: S.Biaz and N. Vaidya. Discriminating Congestion Losses from Wireless Losses Using Interarrival Times at the Receiver. IEEE Symposium on Application-Specific Systems and Software Engineering and Technology, Mar 1999. > This appears to be a rather neglected field however, especially when it comes to large scale, public internet investigations. Due to the very nature of this, passive investigations without signals contained within the headers are only of limited use in empirical research here. > > o) A side-effect of Van Jacobson's algorithm is that RTO spikes when the path RTT suddenly drops. With the decrease of the path RTT, the variance grows. As the variance has a large effect on the calculated RTO, this leads to potentially very lengthy timeouts even though the RTT is much shorter. This particular problem has been addressed in some stacks, and the lessons learned from the deployment there could be used to update the RTO calculation specs. > > o) Enabling of spurious RTO detection (Eifel, D-SACK, F-RTO) in the last years also make it possible to dynamically identify instances when the RTT estimation or RTO calculation where mislead, allowing to use a more conservative algorithm for certain paths / times. > > o) Retransmission ambiguity detection during loss recovery (what we already have) > would allow an additional level of loss recovery control without reverting to timer-based methods. I don't get this point. > As with the deployment of SACK, separating "what" to send from "when" to send it could be driven one step further. In particular, less conservative loss recovery schemes which do not trade principles of packet conservation against timeliness, require a reliable way of prompt and best possible feedback from the receiver about any delivered segment and their ordering. SACK alone goes quite a long way, but using Timestamp information in addition could remove any ambiguity. Which ambiguity do you mean here? > However, the current specs in RFC1323 make that use impossible, thus a modified signaling (receiver behavior) is a necessity. > > > > > > The first central aspect of the above mentioned points is to resolve the retransmission ambiguity Again, Eifel? > , and the second to give the end host a better understanding of their respective partners behavior. > > I strongly believe that much about the retransmission ambiguity can be solved by exploiting synergistic signaling between the TCP SACK option and Timestamp option. In particular, the receiver-side state required by RFC1323 to choose which Timestamp to reflect when a non-contiguous segment is received could be alleviated, when the TCP session is also using SACK. (The presence of a SACK field indicates some out of sequence delivery. The current stipulations were made, afaik, to ensure that no unduly small RTT sample is entered into the RTO calculation, when ACK loss occurs. But again, SACK disambiguates between a in-sequence ACK, and a duplicate ACK). > // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22222 // email: zimmermann at cs.rwth-aachen.de // web: http://www.umic-mesh.net // -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: Signierter Teil der Nachricht Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20110117/b1825a84/PGP.bin From rs at netapp.com Mon Jan 17 07:48:34 2011 From: rs at netapp.com (Scheffenegger, Richard) Date: Mon, 17 Jan 2011 15:48:34 -0000 Subject: [e2e] [tcpm] RTTM + timestamps In-Reply-To: <687258D3-D8AF-4F33-BACC-A6F0F8468E80@comsys.rwth-aachen.de> References: <5FDC413D5FA246468C200652D63E627A0C4E3E0E@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0C5BBDCC@LDCMVEXC1-PRD.hq.netapp.com> <687258D3-D8AF-4F33-BACC-A6F0F8468E80@comsys.rwth-aachen.de> Message-ID: <5FDC413D5FA246468C200652D63E627A0C5BBF04@LDCMVEXC1-PRD.hq.netapp.com> HI Alex, > > o) RTT variance during loss episodes is not deeply researched. > > Current heuristics (RFC1122, RFC1323, Karn's algorithm, RFC2988) > > explicitly exclude (and prevent) the use of RTT samples when loss > > occurs. > > Eh... With RFC1323, you take RTT samples when loss occurs. True, but these samples are a worst-case upper bound, since the last in-sequence delivered segment - if you are running "stateless" on the sender. With a stateful sender, that keeps sending timestamps independent of the TS option, and matches the (S)ACKed packets to this (potentially very lengthy) list, you can - to some extent - circumvent this issue. However, it does not help you with re-retransmissions still. Probably my wording was poor, what I intended to say was to get the best possible RTT measurement with each delivered (and (S)ACKed) segment possible, without incurring undue overhead (state) in the sender. The deliberate withholding of TS info according to RFC1323 - in order to address the problem of unreliably delivered ACKs, and - at the time - non-availability of SACK, was what triggered this point. > > However, solving the retransmission ambiguity problem - > > The problem is solved, isn't it? Eifel? Only for cumulative/partial ACKs, and only then in theory, because IPR restrictions prevent Eifel from being deployed in any commercial stack. (There is only a single OS compatible with the IPR requirements for all the Eifel algorithms). For segments that are delivered out-of-sequence, it still exists. > > > and the related reliable ACK delivery problem - may allow the > refinement of these algorithms further, as well as enabling new > research to distinguish between corruption loss (without RTT / one-way > delay impact) and congestion loss (with RTT / one-way delay impact). > > This is not new. Ask Michael Welzl ;-) > > And a citation form Sally Floyd to that topic: > > "Inferring congestion vs. corruption at the transport level. There are > also papers that investigate algorithms for the transport end-nodes to > infer that certain drops are from corruption rather than congestion, > without explicit feedback from routers. My own view would be that the > burden is on such approaches to show that they are not ignoring > legitimate congestion indications from the network." > > eg: S.Biaz and N. Vaidya. Discriminating Congestion Losses from > Wireless Losses Using Interarrival Times at the Receiver. IEEE > Symposium on Application-Specific Systems and Software Engineering and > Technology, Mar 1999. Thanks for the reference! Still you need some way of getting most accurate RTT samples back to the sender, right? > > o) Retransmission ambiguity detection during loss recovery > > (what we already have) Not really, you'll not get a lower TS back for a long delayed segment, which was already retransmitted; also, if the retransmitted segment is beyond some (still existing hole), Eifel + RFC1323 still fail to disambiguate between original and retransmitted segment, when it's delivered. > > > would allow an additional level of loss recovery control without > reverting to timer-based methods. > > I don't get this point. Ok, this revolves around lost retransmission detection at the end-of-stream / below RecoveryPoint. First, LRD is again not widely available (only one particular stack has that feature), nor officially specified. Second, it depends on the ack of a segment beyond recovery point to find that a retransmission was lost. However, if the sender can infer the exact ordering in which all the segements (original, retransmitted, reordered,...) were delivered to the client, it can make a more informed choice if one particular segement was lost (again), before going beyond RecoveryPoint (ie. Retransmit as soon as the segment re-transmitted (!) dupthresh segments later than the one in question, is received; For emphasis, I really mean the re-transmitted segment, not the the delivery of a delayed original segment (because that would be in indication, that there is a good chance of the still-lost segement to be delivered via a slower path; re-sending then would violate the packet conservation principle). > > > As with the deployment of SACK, separating "what" to send from "when" > to send it could be driven one step further. In particular, less > conservative loss recovery schemes which do not trade principles of > packet conservation against timeliness, require a reliable way of > prompt and best possible feedback from the receiver about any delivered > segment and their ordering. SACK alone goes quite a long way, but using > Timestamp information in addition could remove any ambiguity. > > Which ambiguity do you mean here? Hope I made this clear already: For out-of-sequence delivered, retransmitted segments. Under certain circumstances, the sender may re-transmit one segment more than twice, and it should be possible to discriminate between each individual instance of that segment by using SACK+TS information. I can send around a sketch of such a less-conservative SACK loss recovery scheme, using SACK+TS information, for detailed discussions about it...? Best regards, Richard From Michael.Scharf at alcatel-lucent.com Mon Jan 17 12:52:01 2011 From: Michael.Scharf at alcatel-lucent.com (SCHARF, Michael) Date: Mon, 17 Jan 2011 21:52:01 +0100 Subject: [e2e] [tcpm] RTTM + timestamps References: <5FDC413D5FA246468C200652D63E627A0C4E3E0E@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0C5BBDCC@LDCMVEXC1-PRD.hq.netapp.com> Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C026F629F@SLFSNX.rcs.alcatel-research.de> Richard, I happened to look at the RTO calculation and RTO spike issue a long time ago. For whatever it is worth, I scanned that old work and extracted some references that may or may not be well-known. A number of algorithms have indeed been developed to address these issues (e. g., Linux stack), and several papers tried to further optimize the timer calculation in particular for mobile environments, including amongst others: R. Ludwig und K. Sklower. The Eifel Retransmission Timer. ACM SIGCOMM Computer Communications Review, 30(3), 2000, pp. 17?27 [this is not the actual Eifel algorithm] H. Ekstroem and R. Ludwig, ?The Peak-Hopper: A New End-to-End Retransmission Timer for Reliable Unicast Transport,? Proc. IEEE INFOCOM, 2004 K. Jacobsson, H. Hjalmarsson, N. Moeller and K. H. Johansson, "Round-Trip time estimation in communication networks using adaptive Kalman filtering" A. Kesselman, Y. Mansour, "Optimizing TCP Retransmission Timeout", Springer LNCS 3421, 2005 I. Psaras, V. Tsaoussidis, "Why TCP timers (still) don't work well", Computer Networks, Volume 51, Issue 8, 6 June 2007 etc. And, BTW, a young wannabe-TCP researcher once tried to systematically understand the RTO spikes resulting from RFC 2988: Michael Scharf, Marc C. Necker, Bernd Gloss: "The Sensitivity of TCP to Sudden Delay Variations in Mobile Networks", Springer LNCS 3042, 2004, pp. 76-87 If a better RTT estimation or RTO calculation was indeed needed, these papers might contain some interesting starting points. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20110117/b9ee60aa/attachment.html From rs at netapp.com Mon Jan 17 14:57:34 2011 From: rs at netapp.com (Scheffenegger, Richard) Date: Mon, 17 Jan 2011 22:57:34 -0000 Subject: [e2e] [tcpm] RTTM + timestamps In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C026F629F@SLFSNX.rcs.alcatel-research.de> References: <5FDC413D5FA246468C200652D63E627A0C4E3E0E@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0C5BBDCC@LDCMVEXC1-PRD.hq.netapp.com> <133D9897FB9C5E4E9DF2779DC91E947C026F629F@SLFSNX.rcs.alcatel-research.de> Message-ID: <5FDC413D5FA246468C200652D63E627A0C6C2F81@LDCMVEXC1-PRD.hq.netapp.com> Hi Michael, again thank you for these references! I wanted to bring this particular issue up, to discuss if an improved RTO calculation should be brought into a hypothetical I-D talking about improved signaling using existing options. The one currently used by Linux has the merit of extremely wide deployment, and being conservative (only improves one particular aspect over the current standard calculation). For non-technical issues, "Eifel" algorithms offer less good choice for any such future I-D work... (restrictions on IPR prevent the use in commercial implementations unfortunately). However, I think most of these scenarios would also benefit from obtaining good feedback about the RTT samples (with the additional side-info, if the RTT was obtained off a reordered or retransmitted segment). But current signaling doesn't yield that feedback back from the client. Best regards, Richard From: SCHARF, Michael [mailto:Michael.Scharf at alcatel-lucent.com] Sent: Montag, 17. J?nner 2011 21:52 To: Scheffenegger, Richard; tcpm at ietf.org; iccrg at cs.ucl.ac.uk; end2end-interest at postel.org Cc: Matt Mathis; Mark Allman Subject: Re: [tcpm] RTTM + timestamps Richard, I happened to look at the RTO calculation and RTO spike issue a long time ago. For whatever it is worth, I scanned that old work and extracted some references that may or may not be well-known. A number of algorithms have indeed been developed to address these issues (e. g., Linux stack), and several papers tried to further optimize the timer calculation in particular for mobile environments, including amongst others: R. Ludwig und K. Sklower. The Eifel Retransmission Timer. ACM SIGCOMM Computer Communications Review, 30(3), 2000, pp. 17-27 [this is not the actual Eifel algorithm] H. Ekstroem and R. Ludwig, "The Peak-Hopper: A New End-to-End Retransmission Timer for Reliable Unicast Transport," Proc. IEEE INFOCOM, 2004 K. Jacobsson, H. Hjalmarsson, N. Moeller and K. H. Johansson, "Round-Trip time estimation in communication networks using adaptive Kalman filtering" A. Kesselman, Y. Mansour, "Optimizing TCP Retransmission Timeout", Springer LNCS 3421, 2005 I. Psaras, V. Tsaoussidis, "Why TCP timers (still) don't work well", Computer Networks, Volume 51, Issue 8, 6 June 2007 etc. And, BTW, a young wannabe-TCP researcher once tried to systematically understand the RTO spikes resulting from RFC 2988: Michael Scharf, Marc C. Necker, Bernd Gloss: "The Sensitivity of TCP to Sudden Delay Variations in Mobile Networks", Springer LNCS 3042, 2004, pp. 76-87 If a better RTT estimation or RTO calculation was indeed needed, these papers might contain some interesting starting points. Michael From rs at netapp.com Mon Jan 17 05:48:22 2011 From: rs at netapp.com (Scheffenegger, Richard) Date: Mon, 17 Jan 2011 13:48:22 -0000 Subject: [e2e] [tcpm] RTTM + timestamps In-Reply-To: <5FDC413D5FA246468C200652D63E627A0C4E3E0E@LDCMVEXC1-PRD.hq.netapp.com> References: <5FDC413D5FA246468C200652D63E627A0C4E3E0E@LDCMVEXC1-PRD.hq.netapp.com> Message-ID: <5FDC413D5FA246468C200652D63E627A0C5BBDCC@LDCMVEXC1-PRD.hq.netapp.com> Hi group, After having received some feedback off-list so far, I would like to summarize what I learned so far. Also, I invite everyone to discuss these points. There are benefits for the research community both empirical as well as theoretical, as well as mobile and high-speed network operators and implementers. o) one-way delay based (and delay variation based) congestion controls would benefit from knowing the clock resolution on both sides. Some research in that area is done by Mirja Kuehlewind and Bob Briscoe (http://bobbriscoe.net/pubs.html#chirp_impl), as well as David Hayes (http://caia.swin.edu.au/reports/100219A/CAIA-TR-100219A.pdf) o) RTT variance during loss episodes is not deeply researched. Current heuristics (RFC1122, RFC1323, Karn's algorithm, RFC2988) explicitly exclude (and prevent) the use of RTT samples when loss occurs. However, solving the retransmission ambiguity problem - and the related reliable ACK delivery problem - may allow the refinement of these algorithms further, as well as enabling new research to distinguish between corruption loss (without RTT / one-way delay impact) and congestion loss (with RTT / one-way delay impact). This appears to be a rather neglected field however, especially when it comes to large scale, public internet investigations. Due to the very nature of this, passive investigations without signals contained within the headers are only of limited use in empirical research here. o) A side-effect of Van Jacobson's algorithm is that RTO spikes when the path RTT suddenly drops. With the decrease of the path RTT, the variance grows. As the variance has a large effect on the calculated RTO, this leads to potentially very lengthy timeouts even though the RTT is much shorter. This particular problem has been addressed in some stacks, and the lessons learned from the deployment there could be used to update the RTO calculation specs. o) Enabling of spurious RTO detection (Eifel, D-SACK, F-RTO) in the last years also make it possible to dynamically identify instances when the RTT estimation or RTO calculation where mislead, allowing to use a more conservative algorithm for certain paths / times. o) Retransmission ambiguity detection during loss recovery would allow an additional level of loss recovery control without reverting to timer-based methods. As with the deployment of SACK, separating "what" to send from "when" to send it could be driven one step further. In particular, less conservative loss recovery schemes which do not trade principles of packet conservation against timeliness, require a reliable way of prompt and best possible feedback from the receiver about any delivered segment and their ordering. SACK alone goes quite a long way, but using Timestamp information in addition could remove any ambiguity. However, the current specs in RFC1323 make that use impossible, thus a modified signaling (receiver behavior) is a necessity. The first central aspect of the above mentioned points is to resolve the retransmission ambiguity, and the second to give the end host a better understanding of their respective partners behavior. I strongly believe that much about the retransmission ambiguity can be solved by exploiting synergistic signaling between the TCP SACK option and Timestamp option. In particular, the receiver-side state required by RFC1323 to choose which Timestamp to reflect when a non-contiguous segment is received could be alleviated, when the TCP session is also using SACK. (The presence of a SACK field indicates some out of sequence delivery. The current stipulations were made, afaik, to ensure that no unduly small RTT sample is entered into the RTO calculation, when ACK loss occurs. But again, SACK disambiguates between a in-sequence ACK, and a duplicate ACK). For the second aspect, the single most important aspect to convey would be the tcp clock resolution. For this, no signaling exists yet. However, there appears to be a downward-compatible method to extend the Timestamp SYN option, to include this signal. According to RFC1323, TSecr is unused in the SYN segment, and most stacks appear to ignore that value. An enhanced signaling could set this initial TSecr field. To convey some feedback from the receiver to the sender in the SYN|ACK, while maintaining compatibility with stacks that do not evaluate the contents of this SYN TSecr, a simple XOR between the SYN|TSopt field and the clients respective settings could be employed. The sender would compare the TSecr value in the SYN|ACK with it's initial sent TSval, and if they are identical, conclude to deal with an unenhanced client (no SACK+TS synergy, no one-way delay/variance CC). If the TSecr in the SYN|ACK would be different, the negotiated heuristics can be enabled for that TCP session - decoded by an XOR from the original TSval. SYN: +-------+-------+---------------------+---------------------+ |Kind=8 | 10 | TS Value (TSval) |TS Echo Reply (TSecr)| +-------+-------+---------------------+---------------------+ 1 1 4 4 With TSecr containing, ie. A 16-bit Flag field plus a 16-bit IEEE float indicating the TCP clock resolution (duration or frequency), or a 8-bit Flag field plus two 12-bit floats for negotiation of an acceptable clock range. Also, perhaps a CIDR-like prefix bitstring may be of interest for future extensions, ie: 1 1 x x x - future 1 0 1 x x - use 2x12 bit floats 1 0 0 1 x - use 1x16 bit float A few potentially meaningful flag bits discussed so far could be TS-extension flag (always set; this limits the senders initial TS selection...) Reserved TS-negotiate range (w/ 2x 12bit floats) TS-fixed rate (w/ 16bit float) Modified exponent offset (-21 instead of -15, for very high speed networks) SACK+TS synergy (always reflect TS of last received segment) High-Precision (use HW late in data path for TS insertion, exclude much jitter) Note that binary16 allows a dynamic range (with some lost precision) from 2^15 down to 2^-24, while a 12-bit representation, omitting sign and most significant exponent bit, plus least two significant fraction bits, would still allow a range between 2^0 to 2^-22. Binary16: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |Si| Exponent | Fraction | |gn|offset shifted| | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 12-bit subsample: +--+--+--+--+--+--+--+--+--+--+--+--+ | exponent | fraction | +--+--+--+--+--+--+--+--+--+--+--+--+ However even this dynamic range may not be enough to allow a tcp clock to run at the sending rate of minimal IP frames at very high (100 Gbit/s, 1Tbit/s) speeds. Using a different exponent offset shift, and omitting one additional fraction bit instead of one exponent bit in the 12 bit value should be discussed. +--+--+--+--+--+--+--+--+--+--+--+--+ | exponent | fraction | +--+--+--+--+--+--+--+--+--+--+--+--+ From: Scheffenegger, Richard Sent: Montag, 10. J?nner 2011 19:25 To: tcpm at ietf.org; iccrg at cs.ucl.ac.uk Subject: [tcpm] RTTM + timestamps Hi group, in order not to spam the whole group, I would like to learn who is interested in the heuristics and signaling around round-trip measurement, timestamps and possible synergies between TS and other option, as well as some empirical measurements around currently deployed tcp stacks that diverge from the IETF specs in these aspects. In the light of some recent developments (ie. LEDBAT, path-chirp/chirp CC), and more efficient (end-of-flow / non-congestion) loss recovery, improvements in that space may be of interest to a larger group of implementers too... With your feedback, I would like to learn the extent of possible interest, before going further with my work in that area! Best regards, Richard Scheffenegger From dpreed at reed.com Mon Jan 17 18:04:05 2011 From: dpreed at reed.com (David P. Reed) Date: Mon, 17 Jan 2011 21:04:05 -0500 Subject: [e2e] [tcpm] RTTM + timestamps In-Reply-To: <5FDC413D5FA246468C200652D63E627A0C6C2F81@LDCMVEXC1-PRD.hq.netapp.com> References: <5FDC413D5FA246468C200652D63E627A0C4E3E0E@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0C5BBDCC@LDCMVEXC1-PRD.hq.netapp.com> <133D9897FB9C5E4E9DF2779DC91E947C026F629F@SLFSNX.rcs.alcatel-research.de> <5FDC413D5FA246468C200652D63E627A0C6C2F81@LDCMVEXC1-PRD.hq.netapp.com> Message-ID: <4D34F515.7040200@reed.com> For congestyion control purposes, it seems like the proper figure to use should factor out queuing along the current path. That is, since the ideal equilibrium state of the system is to have the average packet queue depth in each "bottleneck"* node between source and destination be 1 packet, the RTT on which one should base congestion management should be the RTT that would be achieved if the system were at that state. If you base RTT on the current cumulative queue-backlog across all nodes, you end up creating a positive-feedback control loop where the queues grow, making the RTT longer, which encourages more packets to be pushed into the queues, making the RTT longer, ... Positive-feedback control loops are unstable in a very bad way. You will end up pinning the end-to-end latency at the largest possible value. The proper design of the congestion control in the Internet should always push the system to minimize backlog on every queue in the system. The average queue length should always converge (quickly) to <=1 packet over all paths. Otherwise, the system is in a congestive degraded state. I feel weird having to say this, but it appears that the "conventional wisdom" all too often assumes that "throughput" will be optimized by building up queues in every router and switch. That is not correct. Beyond one packet in the bottleneck links, throughput becomes quite unstable. * a "bottleneck" link (for the purposes of my point in the email) is the link or link(s) along a path that sustain the lowest data rate of all links on that path. Typically there is one bottleneck link, but in some cases (where there are chains of links that carry the same data rate) there may be two or more. This is easily seen as the "optimal pipelining" model of scheduling jobs. /WWW: http://www.reed.com/dpr/ On 01/17/2011 05:57 PM, Scheffenegger, Richard wrote: > Hi Michael, > > again thank you for these references! > > I wanted to bring this particular issue up, to discuss if an improved RTO calculation should be brought into a hypothetical I-D talking about improved signaling using existing options. > > The one currently used by Linux has the merit of extremely wide deployment, and being conservative (only improves one particular aspect over the current standard calculation). > > For non-technical issues, "Eifel" algorithms offer less good choice for any such future I-D work... (restrictions on IPR prevent the use in commercial implementations unfortunately). > > > However, I think most of these scenarios would also benefit from obtaining good feedback about the RTT samples (with the additional side-info, if the RTT was obtained off a reordered or retransmitted segment). But current signaling doesn't yield that feedback back from the client. > > Best regards, > Richard > > > > > > From: SCHARF, Michael [mailto:Michael.Scharf at alcatel-lucent.com] > Sent: Montag, 17. J?nner 2011 21:52 > To: Scheffenegger, Richard; tcpm at ietf.org; iccrg at cs.ucl.ac.uk; end2end-interest at postel.org > Cc: Matt Mathis; Mark Allman > Subject: Re: [tcpm] RTTM + timestamps > > Richard, > > I happened to look at the RTO calculation and RTO spike issue a long time ago. For whatever it is worth, I scanned that old work and extracted some references that may or may not be well-known. A number of algorithms have indeed been developed to address these issues (e. g., Linux stack), and several papers tried to further optimize the timer calculation in particular for mobile environments, including amongst others: > > R. Ludwig und K. Sklower. The Eifel Retransmission Timer. ACM SIGCOMM Computer Communications Review, 30(3), 2000, pp. 17-27 [this is not the actual Eifel algorithm] > > H. Ekstroem and R. Ludwig, "The Peak-Hopper: A New End-to-End Retransmission Timer for Reliable Unicast Transport," Proc. IEEE INFOCOM, 2004 > > K. Jacobsson, H. Hjalmarsson, N. Moeller and K. H. Johansson, "Round-Trip time estimation in communication networks using adaptive Kalman filtering" > > A. Kesselman, Y. Mansour, "Optimizing TCP Retransmission Timeout", Springer LNCS 3421, 2005 > > I. Psaras, V. Tsaoussidis, "Why TCP timers (still) don't work well", Computer Networks, Volume 51, Issue 8, 6 June 2007 > > etc. > > And, BTW, a young wannabe-TCP researcher once tried to systematically understand the RTO spikes resulting from RFC 2988: > > Michael Scharf, Marc C. Necker, Bernd Gloss: "The Sensitivity of TCP to Sudden Delay Variations in Mobile Networks", Springer LNCS 3042, 2004, pp. 76-87 > > If a better RTT estimation or RTO calculation was indeed needed, these papers might contain some interesting starting points. > > Michael > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20110117/4095add4/attachment-0001.html From alexander.zimmermann at comsys.rwth-aachen.de Mon Jan 17 23:53:12 2011 From: alexander.zimmermann at comsys.rwth-aachen.de (Alexander Zimmermann) Date: Tue, 18 Jan 2011 08:53:12 +0100 Subject: [e2e] [tcpm] RTTM + timestamps In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C026F629F@SLFSNX.rcs.alcatel-research.de> References: <5FDC413D5FA246468C200652D63E627A0C4E3E0E@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0C5BBDCC@LDCMVEXC1-PRD.hq.netapp.com> <133D9897FB9C5E4E9DF2779DC91E947C026F629F@SLFSNX.rcs.alcatel-research.de> Message-ID: And don't forget also Mark's work Using Spurious Retransmissions to Adapt the Retransmission Timeout http://tools.ietf.org/html/draft-allman-rto-backoff-05 Am 17.01.2011 um 21:52 schrieb SCHARF, Michael: > Richard, > > I happened to look at the RTO calculation and RTO spike issue a long time ago. For whatever it is worth, I scanned that old work and extracted some references that may or may not be well-known. A number of algorithms have indeed been developed to address these issues (e. g., Linux stack), and several papers tried to further optimize the timer calculation in particular for mobile environments, including amongst others: > > R. Ludwig und K. Sklower. The Eifel Retransmission Timer. ACM SIGCOMM Computer Communications Review, 30(3), 2000, pp. 17?27 [this is not the actual Eifel algorithm] > > H. Ekstroem and R. Ludwig, ?The Peak-Hopper: A New End-to-End Retransmission Timer for Reliable Unicast Transport,? Proc. IEEE INFOCOM, 2004 > > K. Jacobsson, H. Hjalmarsson, N. Moeller and K. H. Johansson, "Round-Trip time estimation in communication networks using adaptive Kalman filtering" > > A. Kesselman, Y. Mansour, "Optimizing TCP Retransmission Timeout", Springer LNCS 3421, 2005 > > I. Psaras, V. Tsaoussidis, "Why TCP timers (still) don't work well", Computer Networks, Volume 51, Issue 8, 6 June 2007 > > etc. > > And, BTW, a young wannabe-TCP researcher once tried to systematically understand the RTO spikes resulting from RFC 2988: > > Michael Scharf, Marc C. Necker, Bernd Gloss: "The Sensitivity of TCP to Sudden Delay Variations in Mobile Networks", Springer LNCS 3042, 2004, pp. 76-87 > > If a better RTT estimation or RTO calculation was indeed needed, these papers might contain some interesting starting points. > > Michael > > _______________________________________________ > tcpm mailing list > tcpm at ietf.org > https://www.ietf.org/mailman/listinfo/tcpm // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22222 // email: zimmermann at cs.rwth-aachen.de // web: http://www.umic-mesh.net // -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20110118/12ed959e/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: Signierter Teil der Nachricht Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20110118/12ed959e/PGP.bin From touch at isi.edu Tue Jan 18 09:04:44 2011 From: touch at isi.edu (Joe Touch) Date: Tue, 18 Jan 2011 09:04:44 -0800 Subject: [e2e] please trim recipient lists Message-ID: <4D35C82C.2000905@isi.edu> Hi, all, I just pushed through a few posts that were held due to excessively long recipient lists. Please remember to trim your recipient lists; those you're responding to are likely already on the list. Joe (list admin) From michael.finkenzeller at siemens.com Wed Jan 19 01:55:36 2011 From: michael.finkenzeller at siemens.com (Finkenzeller, Michael) Date: Wed, 19 Jan 2011 10:55:36 +0100 Subject: [e2e] Sign me out! Message-ID: <780A716E579FEF43BD346ADF35B0B7EA021DE8DDD3@DEMCHP99E54MSX.ww902.siemens.net> I'm not the guy you thought! Please sign me out of your email distribution list! Thanks a lot. Mit freundlichen Gr??en Michael Finkenzeller Siemens AG Corporate Technology Corporate Research and Technologies CT T DE HW2 Otto-Hahn-Ring 6 81739 M?nchen, Deutschland Tel.: +49 (89) 636-31893 Fax: +49 (89) 63646376 mailto:michael.finkenzeller at siemens.com Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme; Vorstand: Peter L?scher, Vorsitzender; Wolfgang Dehen, Brigitte Ederer, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen; Sitz der Gesellschaft: Berlin und M?nchen, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, M?nchen, HRB 6684; WEEE-Reg.-Nr. DE 23691322 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20110119/17a476c8/attachment.html From alejandro.canovas.cp46700 at gmail.com Thu Jan 20 15:21:54 2011 From: alejandro.canovas.cp46700 at gmail.com (Alejandro Canovas Solbes) Date: Fri, 21 Jan 2011 00:21:54 +0100 Subject: [e2e] IMMM 2011 || July 17-22, 2011 - Bournemouth, UK Message-ID: <201101202321.p0KNLr2q002898@smtp.upv.es> INVITATION: ================= Please consider to contribute to and/or forward to the appropriate groups the following opportunity to submit and publish original scientific results. ================= ============== IMMM 2011 | Call for Papers =============== CALL FOR PAPERS, TUTORIALS, PANELS IMMM 2011: The First International Conference on Advances in Information Mining and Management July 17-22, 2011 - Bournemouth, UK General page: http://www.iaria.org/conferences2011/IMMM11.html Call for Papers: http://www.iaria.org/conferences2011/CfPIMMM11.html Submission deadline: March 1, 2011 Technical Co-Sponsors: - The Bournemouth & Poole College - Bournemouth University - Cisco Systems, Inc. - Linköpings Universitet, Sweden - IN2 search interfaces development Ltd., UK - High Performance Computing Center Stuttgart / Universität Stuttgart, Germany Sponsored by IARIA, www.iaria.org Extended versions of selected papers will be published in IARIA Journals: http://www.iariajournals.org Please note the Poster Forum and Work in Progress options. The topics suggested by the conference can be discussed in term of concepts, state of the art, research, standards, implementations, running experiments, applications, and industrial case studies. Authors are invited to submit complete unpublished papers, which are not under review in any other conference or journal in the following, but not limited to, topic areas. All tracks are open to both research and industry contributions, in terms of Regular papers, Posters, Work in progress, Technical/marketing/business presentations, Demos, Tutorials, and Panels. Before submission, please check and conform with the Editorial rules: http://www.iaria.org/editorialrules.html IMMM 2011 Topics (topics and submission details: see CfP on the site) Mining mechanisms and methods Data mining algorithms; Media adaptive mining; Agent-based mining; Content-based mining; Context-aware mining; Automation of data extraction; Data mining at a large; Domain-driven data mining; Graph-based data mining; Multilabel information; Multimodal mining; Cloud-based mining; Mining using neurocomputing techniques Mining support Querying for mining; Questions for digital investigation; Similarity search; User-generated content; Visualizing data mining; Internationalization and localization techniques for profile/context-based visualization Type of information mining Concept mining; Process mining; Concept mining; Knowledge mining; Knowledge discovery; Mining image and video; Mining patterns; Opinion mining; Graph mining; Ontology mining; Semantic annotations and mining; Document mining; Spatial mining; Speech mining; Text mining; Web mining; XML data mining Pervasive information retrieval Context and location information retrieval; Mobile information retrieval; Geo-information retrieval; Context-aware information retrieval; Access-driven information retrieval; Location-specific information retrieval; Spacial information retrieval; Semantic-driven retrieval Automated retrieval and mining Automated information extraction; Agent-based data mining and information discovery; Agent-based knowledge; Datamining-based agents and multi-agent systems; Agent-mining intelligent applications and systems; Automated retrieval of multimedia streams; Automated retrieval from multimedia archives; Automated copyright infringement detection and watermarking; Automated content summarization; Automatic concept detection, categorization, and genre detection; Automatic speech recognition; Automated cross-media linking Mining features Multilingual data mining; Multimedia mining; String processing and data mining; Mining association rules; Mining social relationships; Mining linked data; Mining sequential episodes from time series; Mining time-dependent data; Un-supervised data mining; Semi-structured data; Mining location-sensitive data; Concept-drift in data mining Information mining and management Data cleaning; Data updating; Segmentation and clustering; Mining transient information; Warehousing; Web syndication; Data filtering and aggregation; Optimal pruning; Data summarization; Knowledge injection, discovery and classification; Uncertainty removal; Managing incompleteness Mining from specific sources Bio data mining; Climate data mining; Data mining in medicine and pharmacology; Data mining in special networks (grids, sensors, etc.); Data management for mobile systems; Data management for sensors; Data mining and management for wireless systems; Dynamic network discovery; Mining from multiple sources; Mining personal semantic data; Mining from social networks; Mining from deep web; Mining from Wikipedia Data management in special environments Data management in sensor and mobile ad hoc networks; Data management in mobile peer-to-peer networks; Data management for mobile applications; Data management in mobile/temporal social networks; Management of community sensing/participatory sensing data; Managing pervasive data, sensor data streams and user devices; Managing mobile semantic data; Manging data-intensive mobile computing; Management of real-time data; Managing security data streams; Managing Mobile Web 2.0 data; Managing data in mobile clouds; Data replication, migration and dissemination in mobile environments; Web data processing and security on mobile devices; Resource advertising and discovery techniques Mining evaluation Statistics on mining; Ranking of mining results; Provenance; Privacy issues; Patterns for mining; Credibility on data mining; Performance of mining information; Data mining and computational intelligence; Intelligent data understanding; Intelligent data analysis Mining tools and applications Data mining applications; Data mining tools and enabling software; Interoperability of information mining tools; Applications for large-scale mining; Content segmentation tools (e.g., shot and semantic scene segmentation); Evaluation methods for TV and radio content analysis tools; Tools for data sets and standard resources Committee http://www.iaria.org/conferences2011/ComIMMM11.html ==================== Publicity Chairs: Zaher Al Aghbari, University of Sharjah, UAE Alejandro Canovas Solbes, Polytechnic University of Valencia, Spain From touch at isi.edu Fri Jan 21 16:57:02 2011 From: touch at isi.edu (Joe Touch) Date: Fri, 21 Jan 2011 16:57:02 -0800 Subject: [e2e] reminder about CFP posts Message-ID: <4D3A2B5E.7000200@isi.edu> Hi, all, We've had a few slip through the filters, unfortunately. As a reminder: *ALL* calls for paper and calls for participation posts to this list must be approved in advance. This list does not permit *any* reminders or extension notices. Please review our list posting policy before posting. Thanks, Joe (list admin)