From gih at apnic.net Thu Jul 14 17:21:37 2011 From: gih at apnic.net (Geoff Huston) Date: Fri, 15 Jul 2011 10:21:37 +1000 Subject: [e2e] Internet routing table In-Reply-To: References: <20110629011555.A53580@gds.best.vwh.net> Message-ID: On 29/06/2011, at 1:00 PM, Anoop Ghanwani wrote: > > This pretty much is what I'm looking for except that the > data are weird. The archives here list only about 65K > routes: > http://www-01.pch.net/resources/data/routing-tables/archive/2011/netnod.woodynet.pch.net/ > There may be some kind of truncation problem. > > So then I tried this one: > http://www-01.pch.net/resources/data/routing-tables/archive/2011/route-collector.ams.pch.net/ > and it lists only ~173K prefixes. > > When I look here > http://bgp.potaroo.net/ > it seems like I should find on the order > of 350K prefixes. > > What am I doing wrong? If you want a simple snapshot, then try http://bgp.potaroo.net/as6447/bgptable.txt (for Ipv4) and http://bgp.potaroo.net/v6/as6447/bgptable.txt (for Ipv6) these are routeviews snapshots, and hopefully the format is self explanatory. Geoff From detlef.bosau at web.de Fri Jul 22 04:33:31 2011 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 22 Jul 2011 13:33:31 +0200 Subject: [e2e] TCP Timeouts and TripleDupACK Message-ID: <4E29600B.1020501@web.de> Hi. Are there some papers out there comparing how often TCP congestion is detected by timeout and how often it is detected by triple duplicate ack? I'm basically interested, whether timeouts could be overcome completely or whether there will be a permanent need for a working timeout scheme in TCP. Thanks. Detlef -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de ------------------------------------------------------------------ From lachlan.andrew at gmail.com Fri Jul 22 05:21:40 2011 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Fri, 22 Jul 2011 22:21:40 +1000 Subject: [e2e] TCP Timeouts and TripleDupACK In-Reply-To: <4E29600B.1020501@web.de> References: <4E29600B.1020501@web.de> Message-ID: Greetings Detlef, I don't have any figures, but I don't think we can ever do away with timeouts. There is always a chance that all ACKs get lost, and so if we want to have reliability without the possibility of a deadlock, we need a timeout to break out of waiting state. Cheers, Lachlan On 22 July 2011 21:33, Detlef Bosau wrote: > Hi. > > Are there some papers out there comparing how often TCP congestion is > detected by timeout and how often it is detected by triple duplicate ack? > > I'm basically interested, whether timeouts could be overcome completely or > whether there will be a permanent need for a working timeout scheme in TCP. > > Thanks. > > Detlef > > -- > ------------------------------------------------------------------ > Detlef Bosau > Galileistra?e 30 > 70565 Stuttgart ? ? ? ? ? ? ? ? ? ? ? ? ? ?Tel.: ? +49 711 5208031 > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? mobile: +49 172 6819937 > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? skype: ? ? detlef.bosau > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ICQ: ? ? ? ? ?566129673 > detlef.bosau at web.de ? ? ? ? ? ? ? ? ? ? http://www.detlef-bosau.de > ------------------------------------------------------------------ > > > -- Lachlan Andrew? Centre for Advanced Internet Architectures (CAIA) Swinburne University of Technology, Melbourne, Australia Ph +61 3 9214 4837 From david.borman at windriver.com Fri Jul 22 06:51:20 2011 From: david.borman at windriver.com (Borman, David) Date: Fri, 22 Jul 2011 13:51:20 +0000 Subject: [e2e] TCP Timeouts and TripleDupACK In-Reply-To: <4E29600B.1020501@web.de> References: <4E29600B.1020501@web.de> Message-ID: <3B3C8465-1C1C-4030-BD78-337F88966877@windriver.com> TCP runs over IP, which is unreliable, so you'll always need a mechanism to detect lost packets. In TCP that is done via timeouts to detect the lack of response to data packets; which handles either the outbound data or returning ACK getting lost. -David Borman On Jul 22, 2011, at 6:33 AM, Detlef Bosau wrote: > Hi. > > Are there some papers out there comparing how often TCP congestion is detected by timeout and how often it is detected by triple duplicate ack? > > I'm basically interested, whether timeouts could be overcome completely or whether there will be a permanent need for a working timeout scheme in TCP. > > Thanks. > > Detlef > > -- > ------------------------------------------------------------------ > Detlef Bosau > Galileistra?e 30 > 70565 Stuttgart Tel.: +49 711 5208031 > mobile: +49 172 6819937 > skype: detlef.bosau > ICQ: 566129673 > detlef.bosau at web.de http://www.detlef-bosau.de > ------------------------------------------------------------------ > From mellia at tlc.polito.it Fri Jul 22 08:27:23 2011 From: mellia at tlc.polito.it (Marco Mellia) Date: Fri, 22 Jul 2011 08:27:23 -0700 Subject: [e2e] TCP Timeouts and TripleDupACK In-Reply-To: <4E29600B.1020501@web.de> References: <4E29600B.1020501@web.de> Message-ID: <4E2996DB.1020309@tlc.polito.it> I agree with other saying that you cannot avoid timeouts in general. At best, you can reduce them.. In any case, you can check [1] S. Jaiswal, G. Iannaccone, C. Diot, J. Kurose, D. Towsley, Measurement and classification of out-of-sequence packets in a tier-1 IP backbone, IEEE/ACM Transaction on Networking 15 (1) (2007) 54--66 [2]S. Rewaskar, J. Kaur, F.D. Smith, A passive state-machine approach for accurate analysis of TCP out-of-sequence segments, ACM SIGCOMM Computer Communication Review archive 36 (3) (2006) 51--64. But the best source is: ;) M.Mellia, M.Meo, L.Muscariello, D.Rossi, ``Passive analysis of TCP anomalies'', Computer Networks, Vol.52, No.14, 2008 [algorithm implemented in tstat, and results are available online :)] http://tstat.tlc.polito.it/web.shtml then - select polito/LIVE as trace - tcp::stats -> total number of anomalies Note that the algorithm has been fine tuned to 2007 TCP... so today it may need some refinement.. We also did some work on how to reduce the number of RTOs [4] M.Mellia, M.Meo, C.Casetti, ``TCP Smart Framing: a Segmentation Algorithm to Reduce TCP latency'', IEEE/ACM Transactions on Networking, Vol. 13, No. 2, pp. 316--329, ISSN: 1063-6692, April 2005 [5] D.Ciullo, M.Mellia, M.Meo, ``Two Schemes to Reduce Latency in Short Lived TCP Flows'', IEEE Communications Letters, Vol.\ 13, No.\ 10, October 2009 Hope this helps Ciao Marco > > Hi. > > Are there some papers out there comparing how often TCP congestion is > detected by timeout and how often it is detected by triple duplicate ack? > > I'm basically interested, whether timeouts could be overcome > completely or whether there will be a permanent need for a working > timeout scheme in TCP. > > Thanks. > > Detlef > -- Ciao, /\/\/\rco +-----------------------------------+ | Marco Mellia - Assistant Professor| | Skypeid: mgmellia | | Tel: +39-011-564-4173 | | Cel: +39-331-6714789 | /"\ .. . . . . . . . . . . . . | Politecnico di Torino | \ / . ASCII Ribbon Campaign . | Corso Duca degli Abruzzi 24 | X .- NO HTML/RTF in e-mail . | Torino - 10129 - Italy | / \ .- NO Word docs in e-mail. | http://www.telematica.polito.it | .. . . . . . . . . . . . . +-----------------------------------+ The box said "Requires Windows 95 or Better." So I installed Linux. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20110722/281bfbc9/attachment.html From anil at cmmacs.ernet.in Fri Jul 22 10:03:07 2011 From: anil at cmmacs.ernet.in (anil@cmmacs.ernet.in) Date: Fri, 22 Jul 2011 22:33:07 +0530 (IST) Subject: [e2e] TCP Timeouts and TripleDupACK In-Reply-To: <4E29600B.1020501@web.de> References: <4E29600B.1020501@web.de> Message-ID: <1549.115.241.75.48.1311354187.squirrel@202.41.64.20> Hi, We all agree that recovery of lost data packet through RTO mechanism is relatively much slower and triple ACK scheme can do the job faster. However, there are scenarios in which triple ACKs may not get triggered at all. This can happen if packet loss occurs when IW is small, and hence there are not adequate data packets in flight to trigger triple ACKs. Example: connection is in the beginning of slow start either because it is a new connection or because it is restarting after a long idle period. So, it would be difficult to completely do away with timeouts. Anil > Hi. > > Are there some papers out there comparing how often TCP congestion is > detected by timeout and how often it is detected by triple duplicate ack? > > I'm basically interested, whether timeouts could be overcome completely > or whether there will be a permanent need for a working timeout scheme > in TCP. > > Thanks. > > Detlef > > -- > ------------------------------------------------------------------ > Detlef Bosau > Galileistra?e 30 > 70565 Stuttgart Tel.: +49 711 5208031 > mobile: +49 172 6819937 > skype: detlef.bosau > ICQ: 566129673 > detlef.bosau at web.de http://www.detlef-bosau.de > ------------------------------------------------------------------ > > From faber at isi.edu Fri Jul 22 11:50:23 2011 From: faber at isi.edu (Ted Faber) Date: Fri, 22 Jul 2011 11:50:23 -0700 Subject: [e2e] TCP Timeouts and TripleDupACK In-Reply-To: <4E29600B.1020501@web.de> References: <4E29600B.1020501@web.de> Message-ID: <20110722185022.GG34384@zod.isi.edu> On Fri, Jul 22, 2011 at 01:33:31PM +0200, Detlef Bosau wrote: > I'm basically interested, whether timeouts could be overcome completely > or whether there will be a permanent need for a working timeout scheme > in TCP. I can't think of any other reasonable way to detect loss in a one-segment window. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20110722/c97bd6ae/attachment.bin From detlef.bosau at web.de Thu Jul 28 05:37:30 2011 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 28 Jul 2011 14:37:30 +0200 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: <4E31580A.7020705@web.de> On 01/17/2011 09:52 PM, SCHARF, Michael wrote: > > 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 > I just had a look at these older posts - and I'm afraid, you may be completely at cross-purposes. From what I've seen from Richard, Richards concern is to get TCP RTT samples with a much finer resolution than we do today. Particularly your own work targets at the feasibility for the RTT sampling mechanism from RFC 2988 (IIRC) for WWAN. While I don't think that we really have an issue with the TCP clock resolution, at least no new one, finding suitable RTOs for WWAN is an important issue for TCP in conjunction with WWAN. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de ------------------------------------------------------------------ From william.allen.simpson at gmail.com Thu Jul 28 13:48:29 2011 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Thu, 28 Jul 2011 16:48:29 -0400 Subject: [e2e] [tcpm] RTTM + timestamps In-Reply-To: <4E31580A.7020705@web.de> References: <5FDC413D5FA246468C200652D63E627A0C4E3E0E@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0C5BBDCC@LDCMVEXC1-PRD.hq.netapp.com> <133D9897FB9C5E4E9DF2779DC91E947C026F629F@SLFSNX.rcs.alcatel-research.de> <4E31580A.7020705@web.de> Message-ID: <4E31CB1D.5010005@gmail.com> On 7/28/11 8:37 AM, Detlef Bosau wrote: > From what I've seen from Richard, Richards concern is to get TCP RTT samples with a much finer resolution than we do today. > > Particularly your own work targets at the feasibility for the RTT sampling mechanism from RFC 2988 (IIRC) for WWAN. > > While I don't think that we really have an issue with the TCP clock resolution, at least no new one, finding suitable RTOs for WWAN is an important issue for TCP in conjunction with WWAN. > A couple of years ago, when I first asked this list about TCPCT related work, *several* folks wanted finer grained resolution. So, I added the 64-bit NTP4-format timestamps. Then, many months later, a naysayer raised the possibility that NTP5 will someday replace NTP4. I had to redo the format to be even more extensible, rendering my extant code obsolete.... But I don't know anybody actually writing the code for 64-bit timestamps though, let alone NTP5-sized. Would folks be interested in a draft describing them? Would that help move things along? From detlef.bosau at web.de Thu Jul 28 14:25:22 2011 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 28 Jul 2011 23:25:22 +0200 Subject: [e2e] [tcpm] RTTM + timestamps In-Reply-To: <4E31CB1D.5010005@gmail.com> References: <5FDC413D5FA246468C200652D63E627A0C4E3E0E@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0C5BBDCC@LDCMVEXC1-PRD.hq.netapp.com> <133D9897FB9C5E4E9DF2779DC91E947C026F629F@SLFSNX.rcs.alcatel-research.de> <4E31580A.7020705@web.de> <4E31CB1D.5010005@gmail.com> Message-ID: <4E31D3C2.9020209@web.de> On 07/28/2011 10:48 PM, William Allen Simpson wrote: >> > > A couple of years ago, when I first asked this list about TCPCT related > work, *several* folks wanted finer grained resolution. So, I added the > 64-bit NTP4-format timestamps. Then, many months later, a naysayer > raised > the possibility that NTP5 will someday replace NTP4. I had to redo the > format to be even more extensible, rendering my extant code obsolete.... > > But I don't know anybody actually writing the code for 64-bit timestamps > though, let alone NTP5-sized. Would folks be interested in a draft > describing them? Would that help move things along? As I said, I don't think that there is an open issue with the granulation - and your post confirms this position. At least in that particular respect, that our time stamps _are_ fine enough or, if necessary, can be made so. One important question is, of course, the resolution of clocks and OS timers in practical implementations. In some private e-mail conservation, a timer with a resolution of 10^(-12) seconds was suggested - and my simple and harsh reaction was: This is complete nonsense. However, if our clocks and OS timers could yield a resolution like this, it is nice to know, that we can define time stamps to have this implemented. The origin of my question is that I work with WWAN and I'm looking for a reasonable way to model WWAN links in some generic manner. There are dozens of simulations around which model particular technologies, topologies, scenarios and so on. However, there is nothing generic which is not likely to be criticized as too much technology dependent etc.. Therefore, I'm basically interested in an approach which discusses the relevant problems of timers in WWAN, where the focus shall be the structural ones. Not that ones which are due to the n technologies we have - and overcome with the n plus first. This evening, I had a very first glance at the "peak hopper" paper - however, what left me alone was the simulation. It is always fine work to confirm an RTO design with NS2 simulations, however the everlasting question arises whether the simulations confirm the RTO design - or the RTO desin confirms the simulator. In other words: Are the underlying models and the simulation scenario realistic? Are the results meaningful? Personally, I tend to to simulations in that direction that I want to simulate the significant problems with WWAN - only these and not the stuff whether a certain simulation model works exactly like the Ultime Omega Brand New Wirelss WAN from Lucent or whomever. I would be grateful to see concrete time series from real WWAN measurements, so one could discuss if, e.g., spurious timeouts are an issue or not. (This is an open depate for about 15 years now.) Or whether short time "disconnections" (what ever this means in WWAN) are an issue or not. Or whether recovery from temporarily short throughput is an issue or not. I think there are lots of interesting questions and I'm, as always ;-), in some lack of dialogue partners here, but I'm looking forward to turning this into some better direction here. Detlef -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de ------------------------------------------------------------------ From rs at netapp.com Fri Jul 29 10:06:55 2011 From: rs at netapp.com (Scheffenegger, Richard) Date: Fri, 29 Jul 2011 18:06:55 +0100 Subject: [e2e] [tcpm] RTTM + timestamps In-Reply-To: <4E31CB1D.5010005@gmail.com> References: <5FDC413D5FA246468C200652D63E627A0C4E3E0E@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0C5BBDCC@LDCMVEXC1-PRD.hq.netapp.com> <133D9897FB9C5E4E9DF2779DC91E947C026F629F@SLFSNX.rcs.alcatel-research.de> <4E31580A.7020705@web.de> <4E31CB1D.5010005@gmail.com> Message-ID: <5FDC413D5FA246468C200652D63E627A0F729169@LDCMVEXC1-PRD.hq.netapp.com> It appears to me, that somehow finer timestamp clock (and distinct from that, value representation) resolution and larger timestamp range got all mixed up in these discussions. As I see it, there is no pressing need for timestamp clock counters exceeding 32 bit; However, there is some room for improvement to make better use of these bits (and if that is no longer sufficient, an expansion would be required). Using NTP4 [5] timestamps directly, as suggested, would implicitly define the timestamp value resolution (the timestamp clock could still run at a different granularity). Shifting the existing 32-bit field so that the least significant bit "counts" at the natural frequency of the timestamp clock appears to be a different approach which can achieve similar goals. Ideally, for RTT measurement purposes*, the timestamp clock should run at a rate at least as high as the tcp clock. (Often, timestamp clock and tcp clock are identical). Furthermore, to use timestamps effectively, the timestamp clock should "tick" at least once per RTT. With heuristics like Eifel, spurious RTO, and reordering detection is not possible if the timestamp clock resolution does not allow to resolve the Path RTT. On the other end of the constraints, PAWS only requires the timestamp clock to tick once per sequence number overflow, and otherwise as slow as feasible... But suggesting to change the timestamp clock rate to something (significantly) higher than the TCP clock rate does not necessarily require larger timestamp fields of 64 or 128 bits... It only allows to cover extreme edge cases at the same time, without adaptive heuristics. There may also be some misconceptions around http://tools.ietf.org/html/draft-scheffenegger-tcpm-timestamp-negotiatio n-02 where the number of significant bits to signal a clock rate is mistaken to imply that the timestamp clock MUST run at a similar high frequency. Quite the opposite - the timestamp clock duration is signaled with 10 significant bits, across a few orders of magnitude (in the draft, between 16 sec and 8 ns - the latter allowing a clock source like a x86_64 RDTSC at optimal resolution). Using NTP4 [5] timestamps directly would not only possibly imply a clock resolution of the sender, which is actually never used, but also enable direct manipulation of timestamp values. However, TCPCT only provide some means of signaling larger timestamp clock values, without stipulating their content at all. If native NTP timestamp format were to be used, the only possible protection would be a random timestamp offset, unique for each tcp flow. Nevertheless, for certain time-based heuristics, for example CUBIC, such a static offset doesn't help at all (a malicious user can still manipulate the reflected timestamps to cause the sender more data to send, than intended). Larger timestamps could not be used for anything more advanced than simple (and crude) RTT measurements / PAWS detection, while very expensive workarounds (i.e. Linux with the fix for the CUBIC exploit) become necessary. The draft aims at providing the means to open up the interpretation of a timestamp value by the receiver, which includes different semantics under certain circumstances, providing means to protect the value against tampering, and of course shifting the timestamp clock value so that it can be used optimally for a specific environment (WAN or LAN, high or low speed, emphasis on PAWS or emphasis on enhanced TCP congestion control heuristics using RTT / OWDV as input). *) In addition to RTT measurements, one way delay variance (OWDV) measurements would need a timestamp clock resolution at least a few (binary) magnitudes more granular than the RTT of the path. Richard Scheffenegger > -----Original Message----- > From: William Allen Simpson [mailto:william.allen.simpson at gmail.com] > Sent: Donnerstag, 28. Juli 2011 22:48 > To: end2end-interest at postel.org > Cc: Scheffenegger, Richard > Subject: Re: [e2e] [tcpm] RTTM + timestamps > > On 7/28/11 8:37 AM, Detlef Bosau wrote: > > From what I've seen from Richard, Richards concern is to get TCP RTT > samples with a much finer resolution than we do today. > > > > Particularly your own work targets at the feasibility for the RTT > sampling mechanism from RFC 2988 (IIRC) for WWAN. > > > > While I don't think that we really have an issue with the TCP clock > resolution, at least no new one, finding suitable RTOs for WWAN is an > important issue for TCP in conjunction with WWAN. > > > A couple of years ago, when I first asked this list about TCPCT related > work, *several* folks wanted finer grained resolution. So, I added the > 64-bit NTP4-format timestamps. Then, many months later, a naysayer > raised > the possibility that NTP5 will someday replace NTP4. I had to redo the > format to be even more extensible, rendering my extant code > obsolete.... > > But I don't know anybody actually writing the code for 64-bit > timestamps > though, let alone NTP5-sized. Would folks be interested in a draft > describing them? Would that help move things along? From detlef.bosau at web.de Sat Jul 30 04:43:02 2011 From: detlef.bosau at web.de (Detlef Bosau) Date: Sat, 30 Jul 2011 13:43:02 +0200 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: <4E33EE46.90801@web.de> Just see this post. On 01/17/2011 03:35 PM, Alexander Zimmermann wrote: > Eh... With RFC1323, you take RTT samples when loss occurs. You don't take anything, particularly no RTT samples, when loss occurs. >> However, solving the retransmission ambiguity problem - > The problem is solved, isn't it? Eifel? > The timer ambiguity was originally solved by Karn & Partridge. To my understanding, this ambguity does not even occur when timestamps are used. Do you agree? > 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. There are lots of papers in that direction, however, I don't see a reasonable way to infer the true reason for a concrete packet loss on an end to end basis. And that is a different story from RTT sampling. > > >> 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? Again, I think, Eifel solves a different problem. Eifel deals with dectecting spurious timeouts. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de ------------------------------------------------------------------ From alexander.zimmermann at comsys.rwth-aachen.de Sat Jul 30 06:59:45 2011 From: alexander.zimmermann at comsys.rwth-aachen.de (Alexander Zimmermann) Date: Sat, 30 Jul 2011 15:59:45 +0200 Subject: [e2e] [tcpm] RTTM + timestamps In-Reply-To: <4E33EE46.90801@web.de> References: <5FDC413D5FA246468C200652D63E627A0C4E3E0E@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0C5BBDCC@LDCMVEXC1-PRD.hq.netapp.com> <687258D3-D8AF-4F33-BACC-A6F0F8468E80@comsys.rwth-aachen.de> <4E33EE46.90801@web.de> Message-ID: <48D29CD3-344E-4ECB-B08E-D2D3B88B8CD8@comsys.rwth-aachen.de> Detlef, why do you hijack this thread? This is a TCPM not an e2e thread! Nobody can follow crazy cross-posting. Sorry, you waste my time. I don't reply on this. Alex Am 30.07.2011 um 13:43 schrieb Detlef Bosau: > Just see this post. > > On 01/17/2011 03:35 PM, Alexander Zimmermann wrote: >> Eh... With RFC1323, you take RTT samples when loss occurs. > > You don't take anything, particularly no RTT samples, when loss occurs. > >>> However, solving the retransmission ambiguity problem - >> The problem is solved, isn't it? Eifel? >> > > The timer ambiguity was originally solved by Karn & Partridge. To my understanding, this ambguity does not even occur when timestamps are used. Do you agree? > > >> 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. > > There are lots of papers in that direction, however, I don't see a reasonable way to infer the true reason for a concrete packet loss on an end to end basis. > > And that is a different story from RTT sampling. > >> >> >>> 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? > > Again, I think, Eifel solves a different problem. > > Eifel deals with dectecting spurious timeouts. > > -- > ------------------------------------------------------------------ > Detlef Bosau > Galileistra?e 30 > 70565 Stuttgart Tel.: +49 711 5208031 > mobile: +49 172 6819937 > skype: detlef.bosau > ICQ: 566129673 > detlef.bosau at web.de http://www.detlef-bosau.de > ------------------------------------------------------------------ > > // // 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: 243 bytes Desc: Signierter Teil der Nachricht Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20110730/497e0bb3/PGP.bin From detlef.bosau at web.de Sat Jul 30 07:56:08 2011 From: detlef.bosau at web.de (Detlef Bosau) Date: Sat, 30 Jul 2011 16:56:08 +0200 Subject: [e2e] [tcpm] RTTM + timestamps In-Reply-To: <48D29CD3-344E-4ECB-B08E-D2D3B88B8CD8@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> <4E33EE46.90801@web.de> <48D29CD3-344E-4ECB-B08E-D2D3B88B8CD8@comsys.rwth-aachen.de> Message-ID: <4E341B88.6050701@web.de> On 07/30/2011 03:59 PM, Alexander Zimmermann wrote: > Detlef, > > why do you hijack this thread? This is a TCPM not an e2e thread! Nobody can follow crazy cross-posting. I beg you pardon? May I quote from your original message header? > Message-id:<687258D3-D8AF-4F33-BACC-A6F0F8468E80 at comsys.rwth-aachen.de> > References:<5FDC413D5FA246468C200652D63E627A0C4E3E0E at LDCMVEXC1-PRD.hq.netapp.com> > <5FDC413D5FA246468C200652D63E627A0C5BBDCC at LDCMVEXC1-PRD.hq.netapp.com> > To: "Scheffenegger, Richard" > X-Pgp-Agent: GPGMail 1.3.1 > X-Mailer: Apple Mail (2.1082) > X-ISI-4-43-8-MailScanner: Found to be clean > X-MailScanner-From: alexander.zimmermann at comsys.rwth-aachen.de > Cc: tcpm at ietf.org, iccrg at cs.ucl.ac.uk, end2end-interest at postel.org, > Mark Allman, Matt Mathis > Subject: Re: [e2e] [tcpm] RTTM + timestamps > X-BeenThere: end2end-interest at postel.org Please pay your appreciated consideration to the Cc: header. > Sorry, you waste my time. I don't reply on this. > I'm a bit curious about this kind of response. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de ------------------------------------------------------------------ From rs at netapp.com Sat Jul 30 13:03:47 2011 From: rs at netapp.com (Scheffenegger, Richard) Date: Sat, 30 Jul 2011 21:03:47 +0100 Subject: [e2e] [tcpm] RTTM + timestamps In-Reply-To: <4E33EE46.90801@web.de> References: <5FDC413D5FA246468C200652D63E627A0C4E3E0E@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0C5BBDCC@LDCMVEXC1-PRD.hq.netapp.com><687258D3-D8AF-4F33-BACC-A6F0F8468E80@comsys.rwth-aachen.de> <4E33EE46.90801@web.de> Message-ID: <5FDC413D5FA246468C200652D63E627A0F7291DC@LDCMVEXC1-PRD.hq.netapp.com> Detlef, > >> However, solving the retransmission ambiguity problem - > > The problem is solved, isn't it? Eifel? > > > > The timer ambiguity was originally solved by Karn & Partridge. To my > understanding, this ambguity does not even occur when timestamps are > used. Do you agree? Timer (RTTM?) ambiguity != retransmission ambiguity. The semantics of RFC1323 explicitly make it impossible to disambiguate a received retransmission from a delayed original transmission, whenever there is still a preceding hole in the received sequence space. But these semantics were designed, to always result in conservative RTT estimates, even when dealing with delayed ACKs and ACK loss, without requiring any other signal.(*) Furthermore, the disambiguation (which will only work for the first hole under RFC1323) will only work when the timestamp value has changed between the original transmission and the retransmission. Thus the timestamp clock tick delay must be shorter than the RTT. With common timestamp clock granularities of 10..100 ms, it's easy to see that this may work for intercontinental paths, but not for continental, regional or local paths (not to mention data center / LAN environments). Thus there are two issues: o) The typical timestamp granularity is too coarse for a high fraction of sessions; o) Secondly, the current timestamp semantics do not allow discrimination of non-contiguous received segments between original vs. retransmitted segment, because of a deliberate loss of accuracy to "solve" the RTTM issue during loss episodes. Note that the latter is redundant, if the session is using SACK. With SACK, timestamp semantics can be changed during loss/reorder episodes at least, without introducing any RTTM ambiguity. Richard (*) originally, timestamps and selective acknowledgement were discussed in one RFC, which would have allowed synergistic semantics. Later, SACK was split off (see RFC1072 evolving to RFC1323/2018) and there was not much interest at the time in this topic. From detlef.bosau at web.de Sat Jul 30 13:45:47 2011 From: detlef.bosau at web.de (Detlef Bosau) Date: Sat, 30 Jul 2011 22:45:47 +0200 Subject: [e2e] [tcpm] RTTM + timestamps In-Reply-To: <5FDC413D5FA246468C200652D63E627A0F7291DC@LDCMVEXC1-PRD.hq.netapp.com> References: <5FDC413D5FA246468C200652D63E627A0C4E3E0E@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0C5BBDCC@LDCMVEXC1-PRD.hq.netapp.com><687258D3-D8AF-4F33-BACC-A6F0F8468E80@comsys.rwth-aachen.de> <4E33EE46.90801@web.de> <5FDC413D5FA246468C200652D63E627A0F7291DC@LDCMVEXC1-PRD.hq.netapp.com> Message-ID: <4E346D7B.5070307@web.de> First of all: Do we discuss this matter on the e2e list? Or the tcpm list? Frankly spoken, I felt somewhat hurt this afternoon. On 07/30/2011 10:03 PM, Scheffenegger, Richard wrote: >> >> The timer ambiguity was originally solved by Karn& Partridge. To my >> understanding, this ambguity does not even occur when timestamps are >> used. Do you agree? > > Timer (RTTM?) ambiguity != retransmission ambiguity. > > The semantics of RFC1323 explicitly make it impossible to > disambiguate a received retransmission from a delayed > original transmission, whenever there is still a preceding > hole in the received sequence space. > > But these semantics were designed, to always result in > conservative RTT estimates, even when dealing with > delayed ACKs and ACK loss, without requiring any > other signal.(*) > What is the meaning of "conservative" here? Does this mean "if in doubt, the RTT should be rather too large than too small"? Or the other way round? To my understanding, this should be the meaning. Is this correct or am I wrong here? > Furthermore, the disambiguation (which will only work for > the first hole under RFC1323) will only work when the > timestamp value has changed between the original > transmission and the retransmission. Hang on. Do we talk about timers or timestamps here? IIRC, the timestamp, 1323 is talking about, is simply reflected by the receiver. So it does not matter, to which packet the timestamp belongs. Actually, you measure the timestamp's RTT itself. > Thus the timestamp > clock tick delay must be shorter than the RTT. Not quite. I read a few discussions in this direction during the last days. When talking about TCP, these discussions miss the point. In the very case of TCP, and we should make clear what we are talking about, we want to estimate a confidence interval for the RTT. Hence, when the sender's clock granulation is 1 second and the RTT estimator yields 1 second and the variance estimator yields 0, the RTO would be 1 second or 2 second (G or 2 G, refer to 2988...) and when the actual RTT is 0.000000000000000000000000000000000000000000000000000000000000000000001 second, the resulting RTO is, at least, sufficiently large. It is an immediate result from the well known principle of robustness, that we must not exclude systems from the internet for the only reason of being unable to provide for a timer resolution smaller than, say, 0.1 seconds. Anyoune here will agree, that a timer resolution should be "reasonable small". However, from my point of view, 0.1 seconds _is_ reasonable small. Should we discourage the use of TCP/IP on a single Ethernet segment for that reason? > With common timestamp clock granularities of > 10..100 ms, it's easy to see that this may work for > intercontinental paths, but not for continental, regional or > local paths (not to mention data center / LAN environments). Please ignore my ignorance, Richard. Perhaps I'm a bit stupid and have a certain lack of experience. However, from what I see _HERE_, actually in this very moment, is: TCP/IP works in my living room. With nodes being less than 5 meters apart and connected by an ordinary 802.11 WLAN. It is, however, a completely different story, whether we're talking of some "general purpose one size fits all" network or some special purpose network which is particularly designed e.g. for a mesh used in some multiprocessor machine. Perhaps, you do not even have some kind of mesh which reminds you of an Ethernet or something like that, but reminds of some synchronous data bus or something like that. In this particular mailing list, we talk about internetworking. So we should agree on the assumptions which can be made for nodes in an internetwork. These may differ from the assumptions which can be made for interprocessor communication on a blade. Do you agree here? > Thus there are two issues: > o) The typical timestamp granularity is too coarse for a > high fraction of sessions; Is this so? And should we exclude all nodes from the Internet which cannot provide for a "sufficiently fine timestamp granularity"? > o) Secondly, the current timestamp semantics do not allow > discrimination of non-contiguous received segments between > original vs. retransmitted segment, because of a deliberate > loss of accuracy to "solve" the RTTM issue during loss > episodes. Is this mainly a matter of accuracy? Or do we have other issues as well? Detlef -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de ------------------------------------------------------------------ From detlef.bosau at web.de Sun Jul 31 17:39:02 2011 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 01 Aug 2011 02:39:02 +0200 Subject: [e2e] [tcpm] RTTM + timestamps In-Reply-To: <5FDC413D5FA246468C200652D63E627A0F7291DC@LDCMVEXC1-PRD.hq.netapp.com> References: <5FDC413D5FA246468C200652D63E627A0C4E3E0E@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0C5BBDCC@LDCMVEXC1-PRD.hq.netapp.com><687258D3-D8AF-4F33-BACC-A6F0F8468E80@comsys.rwth-aachen.de> <4E33EE46.90801@web.de> <5FDC413D5FA246468C200652D63E627A0F7291DC@LDCMVEXC1-PRD.hq.netapp.com> Message-ID: <4E35F5A6.7000407@web.de> On 07/30/2011 10:03 PM, Scheffenegger, Richard wrote: > > Timer (RTTM?) ambiguity != retransmission ambiguity. > > The semantics of RFC1323 explicitly make it impossible to > disambiguate a received retransmission from a delayed > original transmission, whenever there is still a preceding > hole in the received sequence space. > I see the point, however: Following page 13 of RFC 1323, we have: > A TSecr value received in a segment is used to update the > averaged RTT measurement only if the segment acknowledges > some new data, i.e., only if it advances the left edge of the > send window. Neither a retransmission nor a pure ACK caused by a hole will lead to the acknowledgement of yet unacknowledged data. Do you agree here? Either way, the sender will simply ignore the TSecr. > But these semantics were designed, to always result in > conservative RTT estimates, even when dealing with > delayed ACKs and ACK loss, without requiring any > other signal.(*) > O.k., IIRC I asked for the meaning of "conservative" here. Having looked at the RFC, the answer is: conservative regarding congestion control. I.e. a sender must not send to much data. So, the RTT should rather be overestimated than underestimated. Admittedly, this means that we avoid congestion - at the expense of a better throughput. > Furthermore, the disambiguation (which will only work for > the first hole under RFC1323) will only work when the > timestamp value has changed between the original > transmission and the retransmission. At least, for TCP RTTM, this disambiguation is simply not necessary, because the TSecr, you refer to, are not taken into account. What you perhaps refer to is the case that a first sending attempt for a packet failed while the second is successful. The first attempt will not cause an acknowledgment to be sent, while the first successful retransmission will lead to a reasonable RTTM. Hence, in case of several transmissions being necessary for a packet, you will measure a proper "ping pong time" for the very first successful transmission. Is this correct? (Perhaps, I have to think it over for the delayed ack case.) So, looking at the Karn & Partridge paper, we avoid both, case "3.1", measuring from the first transmission, which makes the RTO too conservative, and "3.2", measuring from the most recent transmission, which makes the RTO too aggressive. Detlef -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de ------------------------------------------------------------------