From kristen.eisenberg at yahoo.com Mon Oct 10 03:45:54 2011 From: kristen.eisenberg at yahoo.com (Kristen Eisenberg) Date: Mon, 10 Oct 2011 03:45:54 -0700 (PDT) Subject: [e2e] TCP sequence number reset Message-ID: <1318243554.59681.YahooMailNeo@web122316.mail.ne1.yahoo.com> Just want to get some opinion from the list members about an idea proposed in an IETF draft. The equivalent idea when applied to TCP is sequence number reset. The idea is that assuming an application can access TCP sequence number with each byte of data, an app is allowed to reset the TCP sequence number when it wants to. The sequence number is set to a number not acceptable (add 231) in the current connection. Note that there is no clear usage proposed in that draft nor any reason that it is needed, just a mechanism to do it. I want to see whether folks on this list think that it is a good or bad idea? And why? Kristen Eisenberg Billige Fl?ge Marketing GmbH Emanuelstr. 3, 10317 Berlin Deutschland Telefon: +49 (33) 5310967 Email: utebachmeier at gmail.com Site: http://flug.airego.de - Billige Fl?ge vergleichen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20111010/e1964e3e/attachment.html From jeroen at unfix.org Mon Oct 10 04:04:13 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 10 Oct 2011 13:04:13 +0200 Subject: [e2e] TCP sequence number reset In-Reply-To: <1318243554.59681.YahooMailNeo@web122316.mail.ne1.yahoo.com> References: <1318243554.59681.YahooMailNeo@web122316.mail.ne1.yahoo.com> Message-ID: <4E92D12D.3030203@unfix.org> On 2011-10-10 12:45 , Kristen Eisenberg wrote: > Just want to get some opinion from the list members about an > idea proposed in an IETF draft. [..] Seems some spammer figured out that resending text: http://comments.gmane.org/gmane.network.end2end/6525 but adding your own domain as the spam at the end is not really seen as spam as is passes all spam filters as it is valid text.... goody. Received: from [109.126.141.231] by web122316.mail.ne1.yahoo.com via HTTP; Mon, 10 Oct 2011 03:45:54 PDT Long live The Spammers of Belarus.... Greets, Jeroen From touch at isi.edu Tue Oct 11 09:02:30 2011 From: touch at isi.edu (Joe Touch) Date: Tue, 11 Oct 2011 09:02:30 -0700 Subject: [e2e] TCP sequence number reset In-Reply-To: <1318243554.59681.YahooMailNeo@web122316.mail.ne1.yahoo.com> References: <1318243554.59681.YahooMailNeo@web122316.mail.ne1.yahoo.com> Message-ID: <4E946896.8040503@isi.edu> Hi, Kristen, On 10/10/2011 3:45 AM, Kristen Eisenberg wrote: > Just want to get some opinion from the list members about an > idea proposed in an IETF draft. The equivalent idea when > applied to TCP is sequence number reset. The idea is that > assuming an application can access TCP sequence number with > each byte of data, an app is allowed to reset the TCP sequence > number when it wants to. The sequence number is set to a number > not acceptable (add 231) in the current connection. Note that > there is no clear usage proposed in that draft nor any reason > that it is needed, just a mechanism to do it. I want to see > whether folks on this list think that it is a good or bad idea? > And why? There was a long thread on this topic on this list; check the archives starting March 24, 2011. My view of the conclusion - bad idea. TCP has only one stateful handshake - during connection establishment. Resetting the numbers requires a stateful handshake in the middle of a connection, which TCP doesn't support. Adding a mechanism to do so is as much work as starting a new TCP connection, if not more. Joe > Kristen Eisenberg > Billige Fl?ge > Marketing GmbH > Emanuelstr. 3, > 10317 Berlin > Deutschland > Telefon: +49 (33) > 5310967 > Email: > utebachmeier at > gmail.com > Site: > http://flug.airego.de - Billige Fl?ge vergleichen From L.Wood at surrey.ac.uk Tue Oct 11 10:23:10 2011 From: L.Wood at surrey.ac.uk (L.Wood@surrey.ac.uk) Date: Tue, 11 Oct 2011 18:23:10 +0100 Subject: [e2e] TCP sequence number reset In-Reply-To: <4E946896.8040503@isi.edu> References: <1318243554.59681.YahooMailNeo@web122316.mail.ne1.yahoo.com> <4E946896.8040503@isi.edu> Message-ID: Joe, the email below is an exact copy of a mail in the archives: http://mailman.postel.org/pipermail/end2end-interest/2011-March/008130.html I wonder if this is a sophisticated spam attack, to allow propagation of the url in the signature. (Billige Fl?ge - cheap flights.) > -----Original Message----- > From: end2end-interest-bounces at postel.org > [mailto:end2end-interest-bounces at postel.org] On Behalf Of Joe Touch > Sent: 11 October 2011 17:03 > To: Kristen Eisenberg > Cc: end2end-interest at postel.org > Subject: Re: [e2e] TCP sequence number reset > > Hi, Kristen, > > On 10/10/2011 3:45 AM, Kristen Eisenberg wrote: > > Just want to get some opinion from the list members about an idea > > proposed in an IETF draft. The equivalent idea when applied > to TCP is > > sequence number reset. The idea is that assuming an application can > > access TCP sequence number with each byte of data, an app > is allowed > > to reset the TCP sequence number when it wants to. The > sequence number > > is set to a number not acceptable (add 231) in the current > connection. > > Note that there is no clear usage proposed in that draft nor any > > reason that it is needed, just a mechanism to do it. I want to see > > whether folks on this list think that it is a good or bad idea? > > And why? > > There was a long thread on this topic on this list; check the > archives starting March 24, 2011. > > My view of the conclusion - bad idea. TCP has only one > stateful handshake - during connection establishment. > Resetting the numbers requires a stateful handshake in the > middle of a connection, which TCP doesn't support. Adding a > mechanism to do so is as much work as starting a new TCP > connection, if not more. > > Joe > > > > Kristen Eisenberg > > Billige Fl?ge > > Marketing GmbH > > Emanuelstr. 3, > > 10317 Berlin > > Deutschland > > Telefon: +49 (33) > > 5310967 > > Email: > > utebachmeier at > > gmail.com > > Site: > > http://flug.airego.de - Billige Fl?ge vergleichen > From touch at isi.edu Tue Oct 11 10:40:25 2011 From: touch at isi.edu (Joe Touch) Date: Tue, 11 Oct 2011 10:40:25 -0700 Subject: [e2e] IGNORE POST -- Re: TCP sequence number reset In-Reply-To: References: <1318243554.59681.YahooMailNeo@web122316.mail.ne1.yahoo.com> <4E946896.8040503@isi.edu> Message-ID: <4E947F89.3090404@isi.edu> Hi, Lloyd, Oh - yes, that's possible. To all on the list, please ignore the post as a result. Joe (as list admin) On 10/11/2011 10:23 AM, L.Wood at surrey.ac.uk wrote: > Joe, > > the email below is an exact copy of a mail in the archives: > http://mailman.postel.org/pipermail/end2end-interest/2011-March/008130.html > > I wonder if this is a sophisticated spam attack, to allow propagation > of the url in the signature. (Billige Fl?ge - cheap flights.) > > >> -----Original Message----- >> From: end2end-interest-bounces at postel.org >> [mailto:end2end-interest-bounces at postel.org] On Behalf Of Joe Touch >> Sent: 11 October 2011 17:03 >> To: Kristen Eisenberg >> Cc: end2end-interest at postel.org >> Subject: Re: [e2e] TCP sequence number reset >> >> Hi, Kristen, >> >> On 10/10/2011 3:45 AM, Kristen Eisenberg wrote: >>> Just want to get some opinion from the list members about an idea >>> proposed in an IETF draft. The equivalent idea when applied >> to TCP is >>> sequence number reset. The idea is that assuming an application can >>> access TCP sequence number with each byte of data, an app >> is allowed >>> to reset the TCP sequence number when it wants to. The >> sequence number >>> is set to a number not acceptable (add 231) in the current >> connection. >>> Note that there is no clear usage proposed in that draft nor any >>> reason that it is needed, just a mechanism to do it. I want to see >>> whether folks on this list think that it is a good or bad idea? >>> And why? >> >> There was a long thread on this topic on this list; check the >> archives starting March 24, 2011. >> >> My view of the conclusion - bad idea. TCP has only one >> stateful handshake - during connection establishment. >> Resetting the numbers requires a stateful handshake in the >> middle of a connection, which TCP doesn't support. Adding a >> mechanism to do so is as much work as starting a new TCP >> connection, if not more. >> >> Joe >> >> >>> Kristen Eisenberg >>> Billige Fl?ge >>> Marketing GmbH >>> Emanuelstr. 3, >>> 10317 Berlin >>> Deutschland >>> Telefon: +49 (33) >>> 5310967 >>> Email: >>> utebachmeier at >>> gmail.com From valerio.arnaboldi at iit.cnr.it Fri Oct 14 02:34:17 2011 From: valerio.arnaboldi at iit.cnr.it (Valerio Arnaboldi) Date: Fri, 14 Oct 2011 11:34:17 +0200 (CEST) Subject: [e2e] Pervasive and Mobile Computing journal: Special Issue on Pervasive Urban Applications Message-ID: <60797.146.48.98.205.1318584857.squirrel@webmail.iit.cnr.it> ======================== CALL FOR PAPERS ========================= Elsevier - Pervasive and Mobile Computing Special Issue on Pervasive Urban Applications ================================================================== Over the past decade, the development of digital networks and operations has produced an unprecedented wealth of information. Handheld electronics, location devices, telecommunications networks, and a wide assortment of tags and sensors are constantly producing a rich stream of data reflecting various aspects of urban life. For urban planners and designers, these accumulations of digital traces are valuable sources of data in capturing the pulse of the city in an astonishing degree of temporal and spatial detail. Yet this condition of the hybrid city - which operates simultaneously in the digital and physical realms - also poses difficult questions about privacy, scale, and design, among many others. These questions must be addressed as we move toward achieving an augmented, fine-grained understanding of how the city functions - socially, economically and yes, even psychologically. This special issue aims to advance understanding of research challenges and opportunities in applying the pervasive computing paradigm to urban spaces. We are seeking multi-disciplinary contributions that reveal interesting aspects about urban life and exploit the digital traces to create novel urban applications that benefit citizens, urban planners, and policy makers. In this special issue, we are seeking high quality papers reporting original research results on Pervasive Urban Applications with a preference for works including evaluation studies based on empirical data of actual urban environments. Relevant topics include (but are not limited to): - Pervasive computing applications for urban planning and design - Mining of data collected from urban networks e.g. transportation, energy - Urban mobility and geo-localization - Multi-source urban information integration - Real-time urban information processing - Knowledge representation and reasoning on city data - Case studies and applications of mixed urban sensing and mining - Analysis of social networks in urban space - Middleware for mobile urban computing - Context-aware systems for urban space - Pervasive urban applications for smart cities - Intelligent urban transportation systems - Empirical evaluation of pervasive urban applications - Wireless sensor networks, and social network sensing for pervasive urban applications - Security, privacy, reputation, and trust issues in urban computing - Impact of pervasive technologies in urban space e.g. social, economical, and psychological. Submission process: All submissions must be prepared according to the Guide for Authors as published in the Journal website at http://www.ees.elsevier.com/pmc/. Authors should select SI: Pervasive Urban Applications, from the pull-down menu during the submission process. All contributions must not have been previously published or be under consideration for publication elsewhere. A submission based on one or more papers that appeared elsewhere must have major value-added extensions over what appeared previously (at least 33% new material). Authors are requested to submit their relevant, previously published articles and a summary document explaining the enhancements made in the journal version. Important Dates: Paper submission deadline: November 15, 2011 Final Notification: May 15, 2012 Guest Editors of the Special Issue: Francesco Calabrese, IBM Research, Dublin, Ireland, fcalabre at ie.ibm.com Marco Conti, IIT-CNR, Pisa, Italy, marco.conti at iit.cnr.it Dominik Dahlem, MIT, USA, dahlem at mit.edu Giusy Di Lorenzo, IBM Research, Dublin, Ireland, giusydil at ie.ibm.com Santi Phithakkitnukoon, Newcastle University, UK, santi at newcastle.ac.uk