From detlef.bosau at web.de Mon Jan 4 12:20:41 2010 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 04 Jan 2010 21:20:41 +0100 Subject: [e2e] Some questions about TCP. In-Reply-To: <20091125191855.CA65C6BE59A@mercury.lcs.mit.edu> References: <20091125191855.CA65C6BE59A@mercury.lcs.mit.edu> Message-ID: <4B424D99.8080005@web.de> Hi again and first of all a happy new year to all! At least for me, the discussion during the last weeks shed quite some light on my open issues. Perhaps my basic misconception was, that DUPACKs are always are pure acks. Hence, when acknowledgements are sent piggyback with normal data packets, these ACKs are never considered as DUPACKs. I was particurly pointed to the definition of a DUPACK as given in RFC 5681. Now, some minor questions are still left. 1.: What is the correct behaviour of a TCP receiver when it receives data which is already acknowledged? The question arises in the context of SNOOP, because SNOOP introduces a DUPACK filtering in cases where a packet is duplicated by the SNOOP recovery mechanism. To my understanding, the correct behaviour would simply do nothing. Neither does the duplicate packet affect the receiver's cumulative acknowledgement counter, nor any indication for a pure ack is given. So, the most appropriate behaviour is to simply ignore the packet. With particular respect to SNOOP, this kind of understanding will render the DUPACK filtering unnecessary, because packet duplication does not cause DUPACKs. Q: Is this correct? 2.: The RTO handling as defined in RFC 2988 does not specify a particular timer handling for TCP Reno. However, to my understanding any pending retransmission timer should be canceled after having received three DUPACKs, because the fast retransmit algorithm includes a "Go Back N", hence _any_ _unacknowledged_ _data_ is retransmitted anyway and a still pending timer is likely to cause a premature timeout. So, it makes sense to me to cancel any pending timer in this case and hence start with a new timer upon the transmission of the next packet. Q: Is this correct? My questions may be a bit annoying, but from what I've seen in the last weeks, particularly in quite some private mail off list, is that there is quite some unspoken agreement here and that quite some information in the RFC is given a bit between the lines. One of these is the _definite_ distinction between "piggyback acks", which are _never_ DUPACKs and pure acks, which _can_ be DUPACKS, under certain conditions given in RFC 5681. Regards Detlef -- Detlef Bosau Galileistra?e 30 70565 Stuttgart phone: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From touch at ISI.EDU Tue Jan 5 15:49:15 2010 From: touch at ISI.EDU (Joe Touch) Date: Tue, 05 Jan 2010 15:49:15 -0800 Subject: [e2e] Changes to end2end-interest for the new year... Message-ID: <4B43CFFB.4030001@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all, and Happy New Year. As Aaron Falk noted in his post a few weeks ago (Nov 23, 2009), the IRTF End2End Research Group (E2E RG) has shut down as of Jan. 1, 2010. This mailing list was originally created to serve that RG. This list will continue as an independent service to the community through ISI's Postel Center. The list will no longer be affiliated with the IRTF, but will continue to use its existing name (permission was granted to do so by Aaron, FWIW). I will continue to manage the list, and have created an advisory group to handle list management issues (a role previously performed by the E2E RG chairs). The members serve 3 year staggered terms, and are replaced based on the recommendations of the existing members and myself. The following people have agreed to serve as initial the initial advisory group: E2E Mailing List Advisory Group Members: Term: ------------------------------------------------------------ Karen Sollins (former E2E RG co-chair) 1/10-1/11 Craig Partridge (former E2E RG co-chair) 1/10-1/12 Henning Schulzrinne 1/10-1/13 The list policies will remain in their current form for the forseeable future; we can revisit them as needed. I will be updating the list info pages at postel.org and the Mailman list info pages very shortly with this information. Please do not hesitate to contact me if you have any questions. Joe Touch (list admin) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAktDz/sACgkQE5f5cImnZrsHkwCgrtHGcAhO1c3qvMc/TWX7RlCx OqAAnA14D+oFnm4R5X/5So0bKFUjzDam =Fxco -----END PGP SIGNATURE----- From vkawadia at bbn.com Thu Jan 7 11:37:19 2010 From: vkawadia at bbn.com (Vikas Kawadia) Date: Thu, 07 Jan 2010 14:37:19 -0500 Subject: [e2e] Mobicom 2010 CFP Message-ID: <4B4637EF.4070000@bbn.com> CALL FOR PAPERS MobiCom 2010: The Sixteenth Annual International Conference on Mobile Computing and Networking (Co-located with ACM MobiHoc 2010) Late September, 2010. Chicago, IL, USA http://www.sigmobile.org/mobicom/2010/ Sponsored by ACM SIGMOBILE IMPORTANT DATES: Abstract submission due: March 5, 2010 (11:59PM PST) Paper submission due: March 12, 2010 (11:59PM PST) Notification of acceptance: June 21, 2010 Camera-ready version due: July 15, 2010 ACM MobiCom 2010, the Annual International Conference on Mobile Computing and Networking, is the sixteenth in a series of annual conferences sponsored by ACM SIGMOBILE dedicated to addressing the challenges in the areas of mobile computing and wireless and mobile networking. The conference will be held in Chicago, IL, USA, in late September, 2010. The MobiCom conference series serves as a highly selective, premier international forum addressing networks, systems, algorithms, and applications that support mobile computers and wireless networks. Besides the regular conference program, MobiCom?10 will also include a set of workshops and tutorials, panels, research demonstrations, and a poster session that includes the ACM Student Research Competition. More information on these activities, including submission deadlines, can be found at http://www.sigmobile.org/mobicom/2010/. PAPERS: Authors are invited to submit full papers presenting new research related to the theory and/or practice of mobile computing and/or wireless networking. Areas of interest include, but are not limited to: * Architectures, protocols, and algorithms for various wireless and mobile networks, such as wireless LANs, wireless mesh networks, cellular data networks, delaytolerant networks, mobile ad hoc networks, sensor networks, personal area networks, and vehicular networks * Design, implementation, and evaluation of wireless systems and mobile applications * Algorithms and models for wireless networks and mobile applications * Fundamental understanding of mobile computing and wireless networking * Measurements and performance evaluation of mobile and wireless networks * Cross-layer design for mobile and wireless networks ranging from the PHY layer to applications * Networks involving novel technologies such as UWB, MIMO, directional antennas, and software radios * Architectures, algorithms and protocols for dynamic spectrum usage, white spaces, and cognitive networks * Techniques that deal with low power and energy limitations * Operating system and middleware support for mobile computing and networking * Security, privacy, and trustworthiness of mobile and wireless systems * Integration and interworking of wired and wireless networks * Emerging topics, e.g., social networking applications enabled by mobile and wireless networking systems MobiCom?10 will be a diverse conference and we strongly encourage the submission of mobile systems, experimental and theoretical papers. The program committee will evaluate each paper using metrics that are appropriate for the topic area. For example, a systems or experimental paper in the protocol area will be evaluated based on the innovations in the protocol design, practical implementation, and realistic evaluation, whereas a more theoretical paper may be evaluated mostly based on innovation within the algorithm design. At the same time, the evaluation of wireless and mobile networking technologies is challenging because of the significant impact that the physical environment has on performance. For this reason, all papers must carefully describe and justify the evaluation methodology that is used and identify its strengths and weaknesses. The program committee will referee all papers, and accepted papers will be published in the conference proceedings. CHALLENGES PAPERS: The conference strongly encourages the submission of short papers in the field of mobile computing and wireless networking that present revolutionary new ideas or that challenge existing assumptions prevalent among the research community. These "challenges papers" should provide stimulating ideas or visions that may open up exciting avenues and/or influence the direction of future research. Descriptions of new products or evolution of existing work are not appropriate topics for papers in this category. While an exhaustive evaluation of the proposed ideas is not necessary, insight and in- depth understanding of the issues is expected. Challenges papers will be reviewed by the MobiCom program committee and will be part of the technical program and published in ACM MobiCom proceedings. They should be submitted using the same submission procedure adopted for the full papers. The title of these papers must start with the word "Challenges:" i.e., "Challenges: Rest of the Title." SUBMISSION INSTRUCTIONS: All paper submissions will be handled electronically. Authors should prepare a PDF or PostScript version of their full paper. Papers must (i) be no longer than 12 pages (8 pages for "Challenges" papers), (ii) be in font size no smaller than 10 points, (iii) have pages in double column format with each column having dimensions 9.25? X 3.33?, a space of 0.33? between the two columns, and with no more than 55 lines of text per column, and (iv) fit properly on US "Letter"-sized paper (8.5? X 11?). More detailed instructions will be available in the conference web pages. This year, authors will be given the option of submitting a few slides that summarize their paper and its contributions. The slides will not be revealed to the reviewers until just before the TPC meeting. They will be used only to better facilitate discussions during the TPC meeting. More details will be available on the conference web page. All submitted papers will be judged based on their quality through double-blind reviewing, where the identities of the authors are withheld from the reviewers. Authors' names must not appear in the paper or in the PostScript or PDF file. Submitted papers must be original work, and a paper with substantial similarity must neither be already published, nor be currently under review for publication in any other venue. Please direct any questions about the paper submission process to the Program Co-Chairs at mobicom_pcchairs at acm.org. BEST PAPER AWARD: All papers will be considered for the Best Paper Award. The program committee will select a number of candidates for the award among accepted papers. The winner will be selected at the conference, considering both the paper and the presentation. The winner will receive a plaque and a cash award. General Chair Nitin H. Vaidya University of Illinois at Urbana-Champaign Program Co-Chairs Suman Banerjee University of Wisconsin-Madison Dina Katabi Massachusetts Institute of Technology Steering Committee Victor Bahl Imrich Chlamtac David B. Johnson ACM Program Coordinator Fran Spinola FOR MORE INFORMATION: Please contact the General Chair or Program Co-Chairs for more information. For information on ACM SIGMOBILE and the MobiCom series of conferences, see http://www.sigmobile.org/ or contact mobicom_info at acm.org. From vkawadia at bbn.com Thu Jan 7 11:38:29 2010 From: vkawadia at bbn.com (Vikas Kawadia) Date: Thu, 07 Jan 2010 14:38:29 -0500 Subject: [e2e] Mobihoc 2010 CFP Message-ID: <4B463835.5060003@bbn.com> MobiHoc 2010 The 11th ACM International Symposium on Mobile Ad Hoc Networking and Computing Planned for September 2010, Chicago, IL, USA http://www.sigmobile.org/mobihoc/2010/ Sponsored by ACM SIGMOBILE ACM MobiHoc is the premier international symposium dedicated to addressing challenges emerging from wireless ad hoc networking and computing. With its highly selective technical program, the symposium will bring together researchers and practitioners from a broad spectrum of wireless networking research to present the most up-to-date results and achievements in the field. We invite paper submissions on mobile ad hoc networks, wireless sensor networks, wireless mesh networks, vehicular networks and ad hoc computing systems, with the focus being on issues at and above the MAC layer. Besides theoretical works, papers on practical issues are also very welcome. Areas of interest include, but are not limited to the following: * Applications and middleware support * Transport, network, and MAC protocols * Energy efficiency * Location discovery * Cross-layer design and control * Network resilience, fault-tolerance, and reliability * Functional computation and data aggregation * Modeling and performance analysis * Scaling laws and fundamental limits * Network coding * Opportunistic and delay-tolerant networks * Vehicular networks * Cognitive radio networks * Distributed sensing, actuation, control, and coordination * Trust, security and privacy * System design and testbeds * Measurements from experimental systems The symposium especially encourages the submission of exploratory studies that identify new challenges in the network design, innovative services, and applications that may stimulate far-reaching future research. This year's symposium will assign a Best Paper Award among all the papers submitted to the conference. PAPERS Original Paper Submission Guidelines - PDF Papers must report new results substantiated by experimentation, simulation, or analysis. All submissions will be handled electronically and must be in PDF format. Paper submissions for regular papers must be limited to 10 pages (US letter size, 8.5 x 11 inches) including text, figures and references. The font size must be at least 10 points. Accepted papers will be published in the symposium proceedings. All submitted papers would be judged based on their quality through double-blind reviewing, where the identities of the authors are withheld from the reviewers. Authors' names must NOT appear in the paper or in the PDF file. Submitted papers must not be currently under review for any other publication. Before submitting your paper, please check the description of the conference scope in the Call for Papers . Instructions on paper submission and formatting are available on the symposium webpage (http://www.sigmobile.org/mobihoc/2010). Note that the margin must be 1 inch on all sides. Please direct any questions about the paper submission process to the Program Co-Chairs. IMPORTANT DATES Paper Abstract Registration February 12, 2010 Paper Submission Deadline February 19, 2010 Notification of Acceptance: June 4, 2010 Camera-Ready Version Deadline: June 25, 2010 General Chair: Nitin Vaidya TPC Co-Chairs: Christoph Lindemann Jitendra Padhye From eblanton at cs.ohiou.edu Tue Jan 19 06:23:15 2010 From: eblanton at cs.ohiou.edu (Ethan Blanton) Date: Tue, 19 Jan 2010 09:23:15 -0500 Subject: [e2e] Some questions about TCP. In-Reply-To: <4B424D99.8080005@web.de> References: <20091125191855.CA65C6BE59A@mercury.lcs.mit.edu> <4B424D99.8080005@web.de> Message-ID: <20100119142315.GA30938@colt> Detlef Bosau spake unto us the following wisdom: > 1.: What is the correct behaviour of a TCP receiver when it receives > data which is already acknowledged? Send an ACK for the current cumulative ACK point. Whether that is an ACK piggybacked on an outgoing data segment or a pure ACK is immaterial in this case. See RFC 793: 3. If the connection is in a synchronized state (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), any unacceptable segment (out of window sequence number or unacceptible acknowledgment number) must elicit only an empty acknowledgment segment containing the current send-sequence number and an acknowledgment indicating the next sequence number expected to be received, and the connection remains in the same state. > The question arises in the context of SNOOP, because SNOOP introduces a > DUPACK filtering in cases where a packet is duplicated by the SNOOP > recovery mechanism. > > To my understanding, the correct behaviour would simply do nothing. This is broken, and can prevent progress on the connection. If the sender of this out-of-window segment sent it because it has not received a valid acknowledgement for the segment, then failing to acknowledge it with the current cumulative ACK point will leave the sender in loss recovery indefinitely. [Snip question on RTO; I'm not going to take a position on this, as it seems valid to me to either leave the current timer running, or restart it on Fast Retransmit. The decision in this case probably depends on how conservative your RTO is. Certainly it is *not* valid to start a new RTO only on transmission of new, previously unsent data.] > My questions may be a bit annoying, but from what I've seen in the last > weeks, particularly in quite some private mail off list, is that there > is quite some unspoken agreement here and that quite some information in > the RFC is given a bit between the lines. > > One of these is the _definite_ distinction between "piggyback acks", > which are _never_ DUPACKs and pure acks, which > _can_ be DUPACKS, under certain conditions given in RFC 5681. I feel like the definition of duplicate acknowledgment (for non-SACK loss recovery) is pretty clear in 5681, and should clear up any ambiguity which was present prior to this document. Ethan -- The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 481 bytes Desc: Digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20100119/cc5ca5af/attachment.bin From detlef.bosau at web.de Tue Jan 19 07:53:05 2010 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 19 Jan 2010 16:53:05 +0100 Subject: [e2e] Some questions about TCP. In-Reply-To: <20100119142315.GA30938@colt> References: <20091125191855.CA65C6BE59A@mercury.lcs.mit.edu> <4B424D99.8080005@web.de> <20100119142315.GA30938@colt> Message-ID: <4B55D561.6030204@web.de> Ethan Blanton wrote: > Detlef Bosau spake unto us the following wisdom: > >> 1.: What is the correct behaviour of a TCP receiver when it receives >> data which is already acknowledged? >> > > Send an ACK for the current cumulative ACK point. Whether that is an > ACK piggybacked on an outgoing data segment or a pure ACK is > immaterial in this case. See RFC 793: > Not quite, because only pure ACKs can be "DupAcks", refer to RFC 5681. And the focus of my question is DupAck filtering (see Hari Balakrishnans PhD thesis). > > >> The question arises in the context of SNOOP, because SNOOP introduces a >> DUPACK filtering in cases where a packet is duplicated by the SNOOP >> recovery mechanism. >> >> To my understanding, the correct behaviour would simply do nothing. >> > > This is broken, and can prevent progress on the connection. If the > Why? Perhaps, "doing nothing" is misleading. Of course, the receiver maintains its ACK counter and sends this piggybacked with the next sent segment. However, it does not send a _pure_ ACK, hence does not see any "DupAcks". That's what I wanted to say. > sender of this out-of-window segment sent it because it has not > received a valid acknowledgement for the segment, then failing to > acknowledge it with the current cumulative ACK point will leave the > sender in loss recovery indefinitely. > Really? First: Is a duplicate packet really an out of sequence packet? Out of window is not yet clear to me, because the receiver does not see the actual window. Second: When the sender did not receive an acknowledgement for this segment (it may be an erroneous retransmission due to a lost ACK) on time, it must retransmit the segment. As often as necessary. > [Snip question on RTO; I'm not going to take a position on this, as it > seems valid to me to either leave the current timer running, or > restart it on Fast Retransmit. The decision in this case probably > depends on how conservative your RTO is. Certainly it is *not* valid > to start a new RTO only on transmission of new, previously unsent > data.] > > The more I think about it, I tend to start a new RTO, because otherwise there is a high probability to stall the Reno recovery and to end up in an a Tahoe slow start... But I'm eager to learn on this one, that's why I asked. Detlef >> My questions may be a bit annoying, but from what I've seen in the last >> weeks, particularly in quite some private mail off list, is that there >> is quite some unspoken agreement here and that quite some information in >> the RFC is given a bit between the lines. >> >> One of these is the _definite_ distinction between "piggyback acks", >> which are _never_ DUPACKs and pure acks, which >> _can_ be DUPACKS, under certain conditions given in RFC 5681. >> > > I feel like the definition of duplicate acknowledgment (for non-SACK > loss recovery) is pretty clear in 5681, and should clear up any > ambiguity which was present prior to this document. > > Ethan > > -- Detlef Bosau Galileistra?e 30 70565 Stuttgart phone: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From eblanton at cs.ohiou.edu Tue Jan 19 09:19:48 2010 From: eblanton at cs.ohiou.edu (Ethan Blanton) Date: Tue, 19 Jan 2010 12:19:48 -0500 Subject: [e2e] Some questions about TCP. In-Reply-To: <4B55D561.6030204@web.de> References: <20091125191855.CA65C6BE59A@mercury.lcs.mit.edu> <4B424D99.8080005@web.de> <20100119142315.GA30938@colt> <4B55D561.6030204@web.de> Message-ID: <20100119171948.GB30938@colt> Detlef Bosau spake unto us the following wisdom: > Ethan Blanton wrote: >> Detlef Bosau spake unto us the following wisdom: >>> 1.: What is the correct behaviour of a TCP receiver when it receives >>> data which is already acknowledged? >> >> Send an ACK for the current cumulative ACK point. Whether that is an >> ACK piggybacked on an outgoing data segment or a pure ACK is >> immaterial in this case. See RFC 793: > > Not quite, because only pure ACKs can be "DupAcks", refer to RFC 5681. I'm quite familiar with RFC 5681. ;-) The point is, whether the ACK you send is a duplicate ACK or an ACK piggybacked on a data segment, either way you will prevent the *correctness* issue which could cause the connection to fail to make progress. > And the focus of my question is DupAck filtering (see Hari Balakrishnans > PhD thesis). My answer is orthogonal to dupack filtering. The point is, the receiver must emit *some* sort of packet containing the current cumulative ACK point to prevent dead/livelock (depending on how you want to look at it) ending in abortive connection termination. >>> The question arises in the context of SNOOP, because SNOOP introduces >>> a DUPACK filtering in cases where a packet is duplicated by the >>> SNOOP recovery mechanism. >>> >>> To my understanding, the correct behaviour would simply do nothing. >> >> This is broken, and can prevent progress on the connection. If the >> > > Why? Perhaps, "doing nothing" is misleading. > > Of course, the receiver maintains its ACK counter and sends this > piggybacked with the next sent segment. However, it does not send a > _pure_ ACK, hence does not see any "DupAcks". > > That's what I wanted to say. If and only if the receiver has data available to send, and can send it immediately or nearly immediately according to the various congestion control rules in place, then it is perfectly fine from a *correctness* point of view to stifle the duplicate ACK. I believe the standard calls for an immediate duplicate ACK, although, as someone (Noel? Bob?) previously pointed out, RFC 793 does not use the term "duplicate ACK" in precisely this fashion. >> sender of this out-of-window segment sent it because it has not >> received a valid acknowledgement for the segment, then failing to >> acknowledge it with the current cumulative ACK point will leave the >> sender in loss recovery indefinitely. > > Really? First: Is a duplicate packet really an out of sequence packet? > Out of window is not yet clear to me, because the receiver does not > see the actual window. Second: When the sender did not receive an > acknowledgement for this segment (it may be an erroneous > retransmission due to a lost ACK) on time, it must retransmit the > segment. As often as necessary. Yes. Read RFC 793. A duplicate packet which falls below RCV.NXT is out of sequence. A duplicate packet falling between RCV.NXT and the end of the receiver's window (RCV.NXT + RCV.WND) may be another issue; it is, however, also my opinion that emitting an immediate dup ACK for such a segment is the correct behavior. The problem with your retransmission scenario, is that if the receiver does not emit a segment with the correct cum ACK point in response to segments falling below the current receive window, the sender could continue to retransmit the same unacceptable segment indefinitely. Consider this: Sender: SND.NXT = 1 SND.UNA = 3 SMSS = 2 Receiver: RCV.NXT = 3 RCV.WND = 10 S: Seq 1 len 2 (Rxt 1) R: (Seq < RCV.NXT, ignore) S: Seq 1 len 2 (Rxt 2) R: (ignore again) : : S: (abort connection due to failure to progress) On the other hand, correct behavior: S: Seq 1 len 2 (Rxt 1) R: (Seq < RCV.NXT) ACK 3 S: (update SND.NXT; send new data) Seq 3 len 2 Note that failing to emit some sort of acknowledgment leads to a connection abort, whereas the acknowledgment in the second case can be either a duplicate acknowledgment or new data carrying an ACK field. The *only* time this matters is when the receiver has no data to send in the reverse direction, or cannot send it, in which case it MUST emit a duplicate acknowledgment for the sake of correctness. Ethan -- The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 481 bytes Desc: Digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20100119/d85edd28/attachment.bin From detlef.bosau at web.de Wed Jan 20 03:23:29 2010 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 20 Jan 2010 12:23:29 +0100 Subject: [e2e] Is DUPACK filtering even _harmful_? Re: Some questions about TCP. In-Reply-To: <20100119171948.GB30938@colt> References: <20091125191855.CA65C6BE59A@mercury.lcs.mit.edu> <4B424D99.8080005@web.de> <20100119142315.GA30938@colt> <4B55D561.6030204@web.de> <20100119171948.GB30938@colt> Message-ID: <4B56E7B1.8040300@web.de> Ethan Blanton wrote: >> Not quite, because only pure ACKs can be "DupAcks", refer to RFC 5681. >> > > I'm quite familiar with RFC 5681. ;-) > Oh, I forgot about it..... I apologize, Highness ;-) However, you gave an helpful answer to my question. Basically, you point to a scenario where missing _acks_ lead to a livelock. Correct? O.k., then you are correct and we must consider "old" packets out of sequence, becuase - a segment _beyond_ the ack point as sean by the receiver indicates one or more lost _segments_. - a segment _before_ "" one or more lost _ACKs_. The latter will end up in a livelock, as long as the sender does not recognize the correct ack point and hence the receiver MUST signal exactly this. Luckily, packet duplication does not cause a problem here, because as soon as the sender got the correct ack point, there may be any number of copies of the recognized ACKs on the net: As the cumulative ack point as seen by the sender has changed, these ACKs are no longer DupAcks followed by your definition given in RFC 5681. Correct? O.k., now for something completely different. (No, I don't sell parrots.) When my understanding is correct, the DupAck filtering as done in Snoop is actually harmful: IIRC, the SNOOP agent looks for acks on L2 and in case of a missing ACK, it may retransmit a cached segment. Actually, this may cause MH to emit an ACK, as you said in your post, and actually, IIRC the SNOOP agent deletes duplicates of this ACK. Now: _First_, this will go wrong if the first (the "tolerated") ACK does not reach FH. In that case, the first ACK is lost on the path, the next ones are killed by the SNOOP agent - and MH will run into a livelock. _Second_ BS does not know whether an ACK by MH is a DupAck or not, because whether a pure ACK is a DupAck or not depends, among the other conditions mentioned in your RFC, upon the cumulative ack point as seen by the receiver - which is not known to the SNOOP Agent. Hence, in summary, packet duplication does not lead to DUPACK confusion, _AND_ any agent, middlebox, router, whatever must not delete ACKs, because this may cause severe harm. Do you agree here? Detlef -- Detlef Bosau Galileistra?e 30 70565 Stuttgart phone: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From paalh at ifi.uio.no Sun Jan 17 23:45:28 2010 From: paalh at ifi.uio.no (=?iso-8859-1?Q?P=E5l_Halvorsen?=) Date: Mon, 18 Jan 2010 08:45:28 +0100 (CET) Subject: [e2e] NOSSDAV 2010: Call for Papers Message-ID: **** NOSSDAV 2010 CALL FOR PAPERS **** NOSSDAV 2010 Amsterdam, The Netherlands. June 2-4, 2010 http://nsl.cs.sfu.ca/nossdav10/ NOSSDAV 2010 is the 20th anniversary of SIGMM's leading workshop on network and operating systems support for digital audio and video. The workshop, hosted by the Centrum Wiskunde & Informatica (CWI) and the Vrije Universiteit Amsterdam (VU), 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 2010, we will accept papers on a broad ranges of topics related to the transmission and presentation of digital audio/video objects. We are particularly interested in soliciting articles that discuss systems-level support for distributed social networking, as well as papers that focus on local dispatching and performance aspects of multi-core processors. 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 GPU's, graphics and virtual environments * Networked games / Real-time immersive systems * Multimedia communications and system security Please contact the workshop general and program chairs to check if your topic is within the scope of NOSSDAV. In all cases, the quality of presentation (writing style, clarity for persons outside the direct field) will play a role in submission evaluation. This year's review process will contain a number of experimental components. One of these is ability for authors and reviewers to participate in a double-open review procedure. In this voluntary trial, the names of the submitting authors AND the names of the participating reviewers will be made available during the process. (We hope that 25% of the submissions will participate in this experiment.) Submissions should be at most SIX pages, using standard ACM proceedings style. Each submission should contain a one-page extended abstract that explains the core contributions of the work to a wide NOSSDAV audience. Authors of papers selected by the program committee (and one wild-card paper selected by NOSSDAV participants) will be invited to submit an extended version of their papers to a special issue of ACM/Springer Multimedia Systems Journal. Important Dates (Firm) Paper Deadline: 17 February 2010 Decision Notification: 25 March 2010 Camera Ready Due: 9 April 2010