From mirja.kuehlewind@ikr.uni-stuttgart.de Wed Feb 1 09:18:22 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B1B11E813C for ; Wed, 1 Feb 2012 09:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.349 X-Spam-Level: X-Spam-Status: No, score=-0.349 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_38=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsIrifGe5w3b for ; Wed, 1 Feb 2012 09:18:21 -0800 (PST) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 78CAC11E8115 for ; Wed, 1 Feb 2012 09:18:21 -0800 (PST) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 58E03633B1; Wed, 1 Feb 2012 18:18:19 +0100 (CET) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 45A4359A8A; Wed, 1 Feb 2012 18:18:19 +0100 (CET) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: Matt Mathis Date: Wed, 1 Feb 2012 18:18:17 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201202011818.17771.mkuehle@ikr.uni-stuttgart.de> Cc: "tcpm@ietf.org" Subject: [tcpm] Review of PRR X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 17:18:23 -0000 Hi Matt, I reviewed the PRR algorithm. Actually I read your IMC paper and not the draft but I hope its the same algorithm ;-) Let me summarize the main points from my understanding and then I have some questions/comments: I think there are 3 changes compared to the current Linux implementation: 1) You removed the limitation that the cwnd can't be larger that fight_size+1 in recovery -> Agreed, this limitation does not make sense and really causes problems 2) Make reduction dependent on congestion control -> This is an implementational thing. Currently Linux will reduce (hard-coded) on every second ACK which will (eventually) lead to a havling of the cwnd. I agree that this decision should be made by the CC algo but its mainly Linux not providing an easy interface to do so. 3) SS like increase in recovery -> This follows directly from point 2. There is a way to reset the cwnd after recovery to any value but Linux will still limit the cwnd to flight_size+max_burst_size. max_burst_size is (hard-coded) 3 in Linux and this limitation make sense to avoid large bursts. Here comes your SS idea into the game. You try to maintain the min cwnd close to ssthresh in recovery to avoid any bursts right after recovery when you set your cwnd to the value determined by the congestion control algorithm. Here my comments: 1) Bursts: As said above the limitation to flight_size+1 is wrong and causes a too conservation behavior of the Linux kernel. But actually the problem is mainly because of the +1. I believe there should still be a limitation of the max burst size (e.g. 3 as used by Linux). In your algorithm it possible to have very arge burst in under certain circumstances, right? At least there should be: At the end of recovery: cwnd = min(ssthresh, flight_size + max_burst_size) 2) SS: The SS thing is a smart idea but I'm not sure if its really needed. You run into the SS part if you have large burst losses or you are application-limited. I would say both cases are worth to be conservative. As soon as you leave recovery and your cwnd is below ssthresh you will be in slow start anyway. You paper is saying in your measurement you were in 32% in the slow start phase at the beginning of recovery. This seems to be a really high value. Do you know what's happening there? Is this due to application limitations or burst losses? I would guess its loss. But if you have a lot of small transmission which hardly leave slow start, it might also explain this number. Maybe both cases even need to be handled differently...? 3) DeliveredData: You are using the number of ack'ed bytes. That means you need to have the cwnd and ssthresh also in bytes (not sure if this is said explicitly anyway). The Linux kernel mostly used number of packets and also assumes that there will be an ACK for every new packet in recovery. These assumptions might be not correct anymore. But I'm not sure if this should be changed implicit in this proposal. This might be an important topic on its own which might have more implications (if implemented every correctly). And I have two more questions: 2) In the paper you say this algorithm will be in the mainline of the Linux kernel. I checked and I dont think it is there yet...? Do you have a patch available? 3) And one completely different question: In the paper you say ECN is disabled on Google servers. Why is this? Regards, Mirja From mattmathis@google.com Wed Feb 1 11:01:52 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C7C11E8071 for ; Wed, 1 Feb 2012 11:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7AjPAN-ZvIl for ; Wed, 1 Feb 2012 11:01:51 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id D9D2A11E8079 for ; Wed, 1 Feb 2012 11:01:50 -0800 (PST) Received: by eekc41 with SMTP id c41so421781eek.31 for ; Wed, 01 Feb 2012 11:01:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:x-system-of-record:content-type; bh=6Xu6VQhqj60PX4Sc8MfNT7TEnVtNrlhLVdO5CN96e8c=; b=RIpUVafAv4qOq2b+K77hdtBy7rnyI+23+28SAu5Et16FiOp8eGpOfbGHsB3qSYo5Jj f/61mmGZy6pZ6NL6hfNNEkfZIkly20KsRbm6Ax9iApzZ33//VRm/vtCPDE49vJzEr2Wx 3Mql6RnFT1LhfwepJnmNOc0HA+RrRPIqLKG5Q= Received: by 10.14.99.71 with SMTP id w47mr2784859eef.78.1328122909980; Wed, 01 Feb 2012 11:01:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.14.99.71 with SMTP id w47mr2784851eef.78.1328122909815; Wed, 01 Feb 2012 11:01:49 -0800 (PST) Received: by 10.213.22.78 with HTTP; Wed, 1 Feb 2012 11:01:49 -0800 (PST) In-Reply-To: <201202011818.17771.mkuehle@ikr.uni-stuttgart.de> References: <201202011818.17771.mkuehle@ikr.uni-stuttgart.de> Date: Wed, 1 Feb 2012 11:01:49 -0800 Message-ID: From: Matt Mathis To: =?ISO-8859-1?Q?Mirja_K=FChlewind?= X-System-Of-Record: true Content-Type: multipart/alternative; boundary=bcaec521555b41f5eb04b7ebb608 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Review of PRR X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 19:01:52 -0000 --bcaec521555b41f5eb04b7ebb608 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable First the quick answers: PRR is in Linux 3.2-rc1. The implementation in Linux uses packet counts, not bytes. Yes this causes a number of artifacts. The transactional nature of the web and video (codic) pacing both cause frequent "application stalls" which cause much of our intuition about how TCP typically operates to be somewhat inaccurate. I believe that all of your suggestions were evaluated empirically and didn't pan out. Several alternative algorithms were tested but not described in the paper. I can speak to the one that surprised me, where my intuition initially matched yours, but the numbers just didn't agree. The issue is SS during recovery. Consider the situation were the cwnd=3DFlightSize=3D10, and you lose 8 packets. Without slowstart during t= he recovery it would be completed with a window of 2, taking 5 RTTs. Furthermore any additional losses are very likely to cause a timeout. Compare this to RFC3517, which allows a 3 packet burst, to complete the recovery in 2 RTTs. Although this seems like a corner case, it happens frequently enough to be statistically significant in the measurement data. For PRR, in this case each of the two ACKs will cause 2 segments to be sent (4 total), as does the first ACK of the next RTT (thus pipe=3D5). Note that both RFC3517 and PRR send 3 extra packets during recovery, either in a burst or in response to three different ACKs. It turns out that due to the risk of additional losses, PRR's average performance is slightly better than RFC3517, even though under identical conditions PRR transmits exactly the same amount of data but slightly later. If the existing standard had not specify something so aggressive, we may have chosen to to do it as as you suggest, but proposing a new standard that performs worse than the existing standard was a non-starter. I am working on an ID that proposes to re-factor TCP congestion control, which will bring the many of your observations into focus. Re: ECN. Last time we checked it caused a measurable increase in the number of failed user requests, probably due to return paths that unconditionally discard packets with ECN marks. Note that the forward path must be delivering them, which seems rather odd. But yes, we are tinkering with ECN, and would like to help foster its deployment. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay On Wed, Feb 1, 2012 at 9:18 AM, Mirja K=FChlewind < mirja.kuehlewind@ikr.uni-stuttgart.de> wrote: > Hi Matt, > > I reviewed the PRR algorithm. Actually I read your IMC paper and not the > draft > but I hope its the same algorithm ;-) > > Let me summarize the main points from my understanding and then I have so= me > questions/comments: > > I think there are 3 changes compared to the current Linux implementation: > > 1) You removed the limitation that the cwnd can't be larger that > fight_size+1 > in recovery > -> Agreed, this limitation does not make sense and really causes proble= ms > > 2) Make reduction dependent on congestion control > -> This is an implementational thing. Currently Linux will reduce > (hard-coded) on every second ACK which will (eventually) lead to a havlin= g > of > the cwnd. I agree that this decision should be made by the CC algo but it= s > mainly Linux not providing an easy interface to do so. > > 3) SS like increase in recovery > -> This follows directly from point 2. There is a way to reset the cwnd > after recovery to any value but Linux will still limit the cwnd to > flight_size+max_burst_size. max_burst_size is (hard-coded) 3 in Linux and > this limitation make sense to avoid large bursts. Here comes your SS idea > into the game. You try to maintain the min cwnd close to ssthresh in > recovery > to avoid any bursts right after recovery when you set your cwnd to the > value > determined by the congestion control algorithm. > > Here my comments: > > 1) Bursts: > As said above the limitation to flight_size+1 is wrong and causes a too > conservation behavior of the Linux kernel. But actually the problem is > mainly > because of the +1. I believe there should still be a limitation of the > max burst size (e.g. 3 as used by Linux). In your algorithm it possible t= o > have very arge burst in under certain circumstances, right? > At least there should be: > At the end of recovery: > cwnd =3D min(ssthresh, flight_size + max_burst_size) > > 2) SS: > The SS thing is a smart idea but I'm not sure if its really needed. You r= un > into the SS part if you have large burst losses or you are > application-limited. I would say both cases are worth to be conservative. > As > soon as you leave recovery and your cwnd is below ssthresh you will be in > slow start anyway. You paper is saying in your measurement you were in 32= % > in > the slow start phase at the beginning of recovery. This seems to be a > really > high value. Do you know what's happening there? Is this due to applicatio= n > limitations or burst losses? I would guess its loss. But if you have a lo= t > of > small transmission which hardly leave slow start, it might also explain > this > number. Maybe both cases even need to be handled differently...? > > 3) DeliveredData: > You are using the number of ack'ed bytes. That means you need to have the > cwnd > and ssthresh also in bytes (not sure if this is said explicitly anyway). > The > Linux kernel mostly used number of packets and also assumes that there wi= ll > be an ACK for every new packet in recovery. These assumptions might be no= t > correct anymore. But I'm not sure if this should be changed implicit in > this > proposal. This might be an important topic on its own which might have mo= re > implications (if implemented every correctly). > > And I have two more questions: > 2) In the paper you say this algorithm will be in the mainline of the Lin= ux > kernel. I checked and I dont think it is there yet...? Do you have a patc= h > available? > 3) And one completely different question: In the paper you say ECN is > disabled > on Google servers. Why is this? > > Regards, > Mirja > > > > --bcaec521555b41f5eb04b7ebb608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable First the quick answers: PRR is in Linux 3.2-rc1.

The im= plementation in Linux uses packet counts, not bytes. =A0Yes this causes a n= umber of artifacts.

The transactional nature of th= e web and video (codic) pacing both cause frequent "application stalls= " which cause much of our intuition about how TCP typically operates t= o be somewhat inaccurate.

I believe that all of your suggestions were evaluated= =A0empirically and didn't pan out. =A0Several alternative algorithms we= re tested but not described in the paper. =A0 I can speak to the one that= =A0surprised=A0me, where my intuition=A0initially=A0matched yours, but the = numbers just didn't agree.

The issue is SS during recovery. =A0 =A0Consider the si= tuation were the cwnd=3DFlightSize=3D10, and you lose 8 packets. =A0Without= slowstart during the recovery it would be completed with a window of 2, ta= king 5 RTTs. =A0Furthermore any additional losses are very likely to cause = a timeout. =A0 =A0Compare this to RFC3517, which allows a 3 packet burst, t= o complete the recovery in 2 RTTs.

Although this seems like a=A0corner=A0case, it happens = frequently enough to be statistically significant in the measurement data. = =A0 For PRR, in this case each of the two ACKs will cause 2 segments to be = sent (4 total), as does the first ACK of the next RTT (thus pipe=3D5). =A0 = Note that both RFC3517 and PRR send 3 extra packets during recovery, either= in a burst or in=A0response=A0to =A0three different ACKs.

It turns out that due to the risk of additional losses,= PRR's average=A0performance=A0is =A0slightly better than RFC3517, even= though=A0under identical conditions PRR=A0transmits exactly the same amoun= t of data but slightly later.

If the existing standard had not specify something so a= ggressive, we may have chosen to to do it as as you suggest, but proposing = a new=A0standard=A0that=A0performs=A0worse than the=A0existing=A0standard w= as a non-starter.

I am working on an ID that proposes to=A0re-factor TCP = congestion control, which=A0will bring the many of your observations into f= ocus.

Re: ECN. =A0Last time we checked it caused a= measurable increase in the number of failed=A0user requests, probably due = to return paths that unconditionally discard packets with ECN marks. =A0Not= e that the forward path must be delivering them, which seems rather odd. = =A0 =A0But yes, we are tinkering with ECN, and would like to help foster it= s deployment.

Thanks,
--MM--
The best way to predict the future is to create it. =A0- Alan Kay=



On Wed, Feb 1, 2012 at 9:18 AM, Mirja K= =FChlewind <mirja.kuehlewind@ikr.uni-stuttgart.de&= gt; wrote:
Hi Matt,

I reviewed the PRR algorithm. Actually I read your IMC paper and not the dr= aft
but I hope its the same algorithm ;-)

Let me summarize the main points from my understanding and then I have some=
questions/comments:

I think there are 3 changes compared to the current Linux implementation:
1) You removed the limitation that the cwnd can't be larger that fight_= size+1
in recovery
=A0 -> Agreed, this limitation does not make sense and really causes pr= oblems

2) Make reduction dependent on congestion control
=A0 -> This is an implementational thing. Currently Linux will reduce (hard-coded) on every second ACK which will (eventually) lead to a havling = of
the cwnd. I agree that this decision should be made by the CC algo but its<= br> mainly Linux not providing an easy interface to do so.

3) SS like increase in recovery
=A0 -> This follows directly from point 2. There is a way to reset the = cwnd
after recovery to any value but Linux will still limit the cwnd to
flight_size+max_burst_size. max_burst_size is (hard-coded) 3 in Linux and this limitation make sense to avoid large bursts. Here comes your SS idea into the game. You try to maintain the min cwnd close to ssthresh in recove= ry
to avoid any bursts right after recovery when you set your cwnd to the valu= e
determined by the congestion control algorithm.

Here my comments:

1) Bursts:
As said above the limitation to flight_size+1 is wrong and causes a too
conservation behavior of the Linux kernel. But actually the problem is main= ly
because of the +1. I believe there should still be a limitation of the
max burst size (e.g. 3 as used by Linux). In your algorithm it possible to<= br> have very arge burst in under certain circumstances, right?
At least there should be:
=A0 =A0 =A0 =A0At the end of recovery:
=A0 =A0 =A0 =A0cwnd =3D min(ssthresh, flight_size + max_burst_size)

2) SS:
The SS thing is a smart idea but I'm not sure if its really needed. You= run
into the SS part if you have large burst losses or you are
application-limited. I would say both cases are worth to be conservative. A= s
soon as you leave recovery and your cwnd is below ssthresh you will be in slow start anyway. You paper is saying in your measurement you were in 32% = in
the slow start phase at the beginning of recovery. This seems to be a reall= y
high value. Do you know what's happening there? Is this due to applicat= ion
limitations or burst losses? I would guess its loss. But if you have a lot = of
small transmission which hardly leave slow start, it might also explain thi= s
number. Maybe both cases even need to be handled differently...?

3) DeliveredData:
You are using the number of ack'ed bytes. That means you need to have t= he cwnd
and ssthresh also in bytes (not sure if this is said explicitly anyway). Th= e
Linux kernel mostly used number of packets and also assumes that there will=
be an ACK for every new packet in recovery. These assumptions might be not<= br> correct anymore. But I'm not sure if this should be changed implicit in= this
proposal. This might be an important topic on its own which might have more=
implications (if implemented every correctly).

And I have two more questions:
2) In the paper you say this algorithm will be in the mainline of the Linux=
kernel. I checked and I dont think it is there yet...? Do you have a patch<= br> available?
3) And one completely different question: In the paper you say ECN is disab= led
on Google servers. Why is this?

Regards,
Mirja




--bcaec521555b41f5eb04b7ebb608-- From ycheng@google.com Wed Feb 1 13:20:20 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC50411E80D2 for ; Wed, 1 Feb 2012 13:20:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.677 X-Spam-Level: X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-xhmTlTqJ53 for ; Wed, 1 Feb 2012 13:20:20 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id BA07D11E8072 for ; Wed, 1 Feb 2012 13:20:19 -0800 (PST) Received: by obbwd15 with SMTP id wd15so2217345obb.31 for ; Wed, 01 Feb 2012 13:20:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type; bh=ZB+mKxABo4AQ19CWdiVqbr13eR3yCB2vAmJ2N/tmE+s=; b=AbHlBA/AUdkTuBqAgRkOLit6PawaosImxLG2ihn7VUE9KdRuQqhjV95F/028Lqy4O4 jX2nELe3cqhw2ZDU8JXjTv6Hzt6AJNwL7iusGfvL8QfDdbh4Jw8YsYfd1ewN8dmkRDP9 nDS77IKOdUIpGOkbzRzLGT2oiHg5n54M+BdzE= Received: by 10.182.231.7 with SMTP id tc7mr177732obc.29.1328131219283; Wed, 01 Feb 2012 13:20:19 -0800 (PST) Received: by 10.182.231.7 with SMTP id tc7mr177724obc.29.1328131219199; Wed, 01 Feb 2012 13:20:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.154.36 with HTTP; Wed, 1 Feb 2012 13:19:59 -0800 (PST) In-Reply-To: References: <201202011818.17771.mkuehle@ikr.uni-stuttgart.de> From: Yuchung Cheng Date: Wed, 1 Feb 2012 16:19:59 -0500 Message-ID: To: =?ISO-8859-1?Q?Mirja_K=FChlewind?= X-System-Of-Record: true Content-Type: text/plain; charset=ISO-8859-1 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Review of PRR X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 21:20:20 -0000 On Wed, Feb 1, 2012 at 2:01 PM, Matt Mathis wrote: > First the quick answers: PRR is in Linux 3.2-rc1. FYI: http://patchwork.ozlabs.org/patch/110857/ From wwwrun@rfc-editor.org Wed Feb 1 17:33:14 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9D921F8716; Wed, 1 Feb 2012 17:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.128 X-Spam-Level: X-Spam-Status: No, score=-102.128 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyikxzb4rV9s; Wed, 1 Feb 2012 17:33:13 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id E8A0021F8715; Wed, 1 Feb 2012 17:33:13 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 77117B1E00F; Wed, 1 Feb 2012 17:14:34 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120202011434.77117B1E00F@rfc-editor.org> Date: Wed, 1 Feb 2012 17:14:34 -0800 (PST) Cc: tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] RFC 6528 on Defending against Sequence Number Attacks X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 01:33:14 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6528 Title: Defending against Sequence Number Attacks Author: F. Gont, S. Bellovin Status: Standards Track Stream: IETF Date: February 2012 Mailbox: fgont@si6networks.com, bellovin@acm.org Pages: 12 Characters: 26917 Obsoletes: RFC1948 Updates: RFC0793 I-D Tag: draft-ietf-tcpm-rfc1948bis-02.txt URL: http://www.rfc-editor.org/rfc/rfc6528.txt This document specifies an algorithm for the generation of TCP Initial Sequence Numbers (ISNs), such that the chances of an off-path attacker guessing the sequence numbers in use by a target connection are reduced. This document revises (and formally obsoletes) RFC 1948, and takes the ISN generation algorithm originally proposed in that document to Standards Track, formally updating RFC 793. [STANDARDS-TRACK] This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From iesg-secretary@ietf.org Thu Feb 2 08:09:14 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD42721F8574; Thu, 2 Feb 2012 08:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDFMdPcHB1HX; Thu, 2 Feb 2012 08:09:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A9621F85AE; Thu, 2 Feb 2012 08:09:13 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120202160913.11567.35397.idtracker@ietfa.amsl.com> Date: Thu, 02 Feb 2012 08:09:13 -0800 Cc: tcpm chair , tcpm mailing list , RFC Editor Subject: [tcpm] Protocol Action: 'The NewReno Modification to TCP's Fast Recovery Algorithm' to Proposed Standard (draft-ietf-tcpm-rfc3782-bis-05.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 16:09:14 -0000 The IESG has approved the following document: - 'The NewReno Modification to TCP's Fast Recovery Algorithm' (draft-ietf-tcpm-rfc3782-bis-05.txt) as a Proposed Standard This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Wesley Eddy and David Harrington. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc3782-bis/ Technical Summary >From the abstract: RFC 5681 documents the following four intertwined TCP congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. RFC 5681 explicitly allows certain modifications of these algorithms, including modifications that use the TCP Selective Acknowledgement (SACK) option (RFC 2883), and modifications that respond to "partial acknowledgments" (ACKs which cover new data, but not all the data outstanding when loss was detected) in the absence of SACK. This document describes a specific algorithm for responding to partial acknowledgments, referred to as NewReno. This response to partial acknowledgments was first proposed by Janey Hoe. This document obsoletes RFC 3782. Working Group Summary Nothing exceptional occurred during the working group process for this document. Document Quality This document is an update to TCP NewReno, to address issues that have been found with existing RFC 3782 implementations, of which there are several. In the Acknowledgments section: Many thanks to Anil Agarwal, Mark Allman, Armando Caro, Jeffrey Hsu, Vern Paxson, Kacheong Poon, Keyur Shah, and Bernie Volz for detailed feedback on this document or on its precursor, RFC 2582. Jeffrey Hsu provided clarifications on the handling of the recover variable that were applied to RFC 3782 as errata, and now are in Section 8 of this document. Yoshifumi Nishida contributed a modification to the fast recovery algorithm to account for the case in which flightsize is 0 when the TCP sender leaves fast recovery, and the TCP receiver uses delayed acknowledgments. Alexander Zimmermann provided several suggestions to improve the clarity of the document. Personnel David Borman (david.borman@windriver.com) is the document shepherd. Wes Eddy (wes@mti-systems.com) is the responsible AD. From mirja.kuehlewind@ikr.uni-stuttgart.de Fri Feb 3 09:04:02 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A0A21F8545 for ; Fri, 3 Feb 2012 09:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.316 X-Spam-Level: X-Spam-Status: No, score=-1.316 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_38=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAJet1fp7uDv for ; Fri, 3 Feb 2012 09:04:01 -0800 (PST) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 678BA21F852D for ; Fri, 3 Feb 2012 09:04:01 -0800 (PST) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 17327633B1; Fri, 3 Feb 2012 18:04:00 +0100 (CET) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 036DD59A8A; Fri, 3 Feb 2012 18:04:00 +0100 (CET) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: Matt Mathis Date: Fri, 3 Feb 2012 18:03:59 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201202011818.17771.mkuehle@ikr.uni-stuttgart.de> In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201202031803.59164.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Review of PRR X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 17:04:02 -0000 Hi Matt, I agree with a lot of things you said. But regarding your example of cwnd 1= 0=20 and 8 losses I'm not sure. You say its not a corner case. I understand that= =20 you have many small flows not leaving slow start. But in this case you have= =20 lost 80% of your packet. I would have expected a max loss of 50% of my=20 packets in SS. For me that means 80% is a really high load situation and I= =20 should be even more careful...!?! Mirja Btw. if this is not a corner case maybe IW of 10 is not a good idea... On Wednesday 01 February 2012 20:01:49 Matt Mathis wrote: > First the quick answers: PRR is in Linux 3.2-rc1. > > The implementation in Linux uses packet counts, not bytes. Yes this caus= es > a number of artifacts. > > The transactional nature of the web and video (codic) pacing both cause > frequent "application stalls" which cause much of our intuition about how > TCP typically operates to be somewhat inaccurate. > > I believe that all of your suggestions were evaluated empirically and > didn't pan out. Several alternative algorithms were tested but not > described in the paper. I can speak to the one that surprised me, where > my intuition initially matched yours, but the numbers just didn't agree. > > The issue is SS during recovery. Consider the situation were the > cwnd=3DFlightSize=3D10, and you lose 8 packets. Without slowstart during= the > recovery it would be completed with a window of 2, taking 5 RTTs. > Furthermore any additional losses are very likely to cause a timeout. > Compare this to RFC3517, which allows a 3 packet burst, to complete the > recovery in 2 RTTs. > > Although this seems like a corner case, it happens frequently enough to be > statistically significant in the measurement data. For PRR, in this case > each of the two ACKs will cause 2 segments to be sent (4 total), as does > the first ACK of the next RTT (thus pipe=3D5). Note that both RFC3517 a= nd > PRR send 3 extra packets during recovery, either in a burst or > in response to three different ACKs. > > It turns out that due to the risk of additional losses, PRR's > average performance is slightly better than RFC3517, even though under > identical conditions PRR transmits exactly the same amount of data but > slightly later. > > If the existing standard had not specify something so aggressive, we may > have chosen to to do it as as you suggest, but proposing a > new standard that performs worse than the existing standard was a > non-starter. > > I am working on an ID that proposes to re-factor TCP congestion control, > which will bring the many of your observations into focus. > > Re: ECN. Last time we checked it caused a measurable increase in the > number of failed user requests, probably due to return paths that > unconditionally discard packets with ECN marks. Note that the forward pa= th > must be delivering them, which seems rather odd. But yes, we are > tinkering with ECN, and would like to help foster its deployment. > > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay > > > > On Wed, Feb 1, 2012 at 9:18 AM, Mirja K=FChlewind < > > mirja.kuehlewind@ikr.uni-stuttgart.de> wrote: > > Hi Matt, > > > > I reviewed the PRR algorithm. Actually I read your IMC paper and not the > > draft > > but I hope its the same algorithm ;-) > > > > Let me summarize the main points from my understanding and then I have > > some questions/comments: > > > > I think there are 3 changes compared to the current Linux implementatio= n: > > > > 1) You removed the limitation that the cwnd can't be larger that > > fight_size+1 > > in recovery > > -> Agreed, this limitation does not make sense and really causes > > problems > > > > 2) Make reduction dependent on congestion control > > -> This is an implementational thing. Currently Linux will reduce > > (hard-coded) on every second ACK which will (eventually) lead to a > > havling of > > the cwnd. I agree that this decision should be made by the CC algo but > > its mainly Linux not providing an easy interface to do so. > > > > 3) SS like increase in recovery > > -> This follows directly from point 2. There is a way to reset the cw= nd > > after recovery to any value but Linux will still limit the cwnd to > > flight_size+max_burst_size. max_burst_size is (hard-coded) 3 in Linux a= nd > > this limitation make sense to avoid large bursts. Here comes your SS id= ea > > into the game. You try to maintain the min cwnd close to ssthresh in > > recovery > > to avoid any bursts right after recovery when you set your cwnd to the > > value > > determined by the congestion control algorithm. > > > > Here my comments: > > > > 1) Bursts: > > As said above the limitation to flight_size+1 is wrong and causes a too > > conservation behavior of the Linux kernel. But actually the problem is > > mainly > > because of the +1. I believe there should still be a limitation of the > > max burst size (e.g. 3 as used by Linux). In your algorithm it possible > > to have very arge burst in under certain circumstances, right? > > At least there should be: > > At the end of recovery: > > cwnd =3D min(ssthresh, flight_size + max_burst_size) > > > > 2) SS: > > The SS thing is a smart idea but I'm not sure if its really needed. You > > run into the SS part if you have large burst losses or you are > > application-limited. I would say both cases are worth to be conservativ= e. > > As > > soon as you leave recovery and your cwnd is below ssthresh you will be = in > > slow start anyway. You paper is saying in your measurement you were in > > 32% in > > the slow start phase at the beginning of recovery. This seems to be a > > really > > high value. Do you know what's happening there? Is this due to > > application limitations or burst losses? I would guess its loss. But if > > you have a lot of > > small transmission which hardly leave slow start, it might also explain > > this > > number. Maybe both cases even need to be handled differently...? > > > > 3) DeliveredData: > > You are using the number of ack'ed bytes. That means you need to have t= he > > cwnd > > and ssthresh also in bytes (not sure if this is said explicitly anyway). > > The > > Linux kernel mostly used number of packets and also assumes that there > > will be an ACK for every new packet in recovery. These assumptions might > > be not correct anymore. But I'm not sure if this should be changed > > implicit in this > > proposal. This might be an important topic on its own which might have > > more implications (if implemented every correctly). > > > > And I have two more questions: > > 2) In the paper you say this algorithm will be in the mainline of the > > Linux kernel. I checked and I dont think it is there yet...? Do you have > > a patch available? > > 3) And one completely different question: In the paper you say ECN is > > disabled > > on Google servers. Why is this? > > > > Regards, > > Mirja =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From mirja.kuehlewind@ikr.uni-stuttgart.de Fri Feb 3 09:04:15 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8E621F856A for ; Fri, 3 Feb 2012 09:04:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6F8lfoKbNHv for ; Fri, 3 Feb 2012 09:04:14 -0800 (PST) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 89C7D21F855B for ; Fri, 3 Feb 2012 09:04:14 -0800 (PST) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id D0C97633B1; Fri, 3 Feb 2012 18:04:13 +0100 (CET) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id C507C59A8A; Fri, 3 Feb 2012 18:04:13 +0100 (CET) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: Yuchung Cheng Date: Fri, 3 Feb 2012 18:04:13 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201202011818.17771.mkuehle@ikr.uni-stuttgart.de> In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201202031804.13070.mkuehle@ikr.uni-stuttgart.de> Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Review of PRR X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 17:04:15 -0000 thx. On Wednesday 01 February 2012 22:19:59 Yuchung Cheng wrote: > On Wed, Feb 1, 2012 at 2:01 PM, Matt Mathis wrote: > > First the quick answers: PRR is in Linux 3.2-rc1. > > FYI: http://patchwork.ozlabs.org/patch/110857/ From mattmathis@google.com Fri Feb 3 12:44:38 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0CD21F854C for ; Fri, 3 Feb 2012 12:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bb1zF6yopOLw for ; Fri, 3 Feb 2012 12:44:37 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFDF21F8508 for ; Fri, 3 Feb 2012 12:44:36 -0800 (PST) Received: by eaae12 with SMTP id e12so1529205eaa.31 for ; Fri, 03 Feb 2012 12:44:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:x-system-of-record:content-type; bh=LP8YOxRaxBVe52EjJy7CZRo7/OUUkCcs2+KGh0CFmAs=; b=12vZJlLq62FLJ47YMyX24OAAeOJT8vyX7oCK0AweCqIb6Qmo6bVaY7WpH7L+8Uu+Vp 2aG0zAu/nVYgWdozw+gqJ91ooqP7O/kP9NEmpf2yegafXvzqp/B+ipP9KM/R07nxRdFC sXx/XXnjfcO1/Xg6MII80HUlDkZj3ckeftVDY= Received: by 10.213.2.74 with SMTP id 10mr2246906ebi.130.1328301875187; Fri, 03 Feb 2012 12:44:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.213.2.74 with SMTP id 10mr2246895ebi.130.1328301873785; Fri, 03 Feb 2012 12:44:33 -0800 (PST) Received: by 10.213.22.78 with HTTP; Fri, 3 Feb 2012 12:44:33 -0800 (PST) In-Reply-To: <201202031803.59164.mirja.kuehlewind@ikr.uni-stuttgart.de> References: <201202011818.17771.mkuehle@ikr.uni-stuttgart.de> <201202031803.59164.mirja.kuehlewind@ikr.uni-stuttgart.de> Date: Fri, 3 Feb 2012 12:44:33 -0800 Message-ID: From: Matt Mathis To: Mirja Kuehlewind X-System-Of-Record: true Content-Type: multipart/alternative; boundary=0015174478f2576c6d04b81561d9 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Review of PRR X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 20:44:38 -0000 --0015174478f2576c6d04b81561d9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I should have been clearer. The "not a corner case" I was referring to was losses exceeding the chosen window reduction, which is the situation that causes 3517 to send bursts and PRR to invoke slowstarts during recovery. We observe that this happens in 32% of the recovery events. You are correct that a single connection into a single bottleneck should not cause more than %50 losses. The most likely cause are bursts on other connections. Note that depending on how the packets from two concurrent slowstarts are interleaved, you expect the losses from to be slightly asymmetric. If the receiver is doing "fast ACKs" to speed slowstart, then you would expect more than 50% losses to be reasonably common. However, the primary cause for our data was probably QUBIC itself, which only invokes a 30% reduction. This plus fast ACK plus drop tail is likely cause losses to frequently exceed the target reduction. We do not have data on how frequently connections experience 80% losses And you are correct, IW10 could be contributing. We tried to quantify that, but couldn't. What is really needed is a TCP header study from within an ISP, just upstream of the primary bottleneck, for all sorts of types of bottleneck gear, clients and content sources. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay On Fri, Feb 3, 2012 at 9:03 AM, Mirja Kuehlewind < mirja.kuehlewind@ikr.uni-stuttgart.de> wrote: > Hi Matt, > > I agree with a lot of things you said. But regarding your example of cwnd > 10 > and 8 losses I'm not sure. You say its not a corner case. I understand th= at > you have many small flows not leaving slow start. But in this case you ha= ve > lost 80% of your packet. I would have expected a max loss of 50% of my > packets in SS. For me that means 80% is a really high load situation and = I > should be even more careful...!?! > > Mirja > > Btw. if this is not a corner case maybe IW of 10 is not a good idea... > > > On Wednesday 01 February 2012 20:01:49 Matt Mathis wrote: > > First the quick answers: PRR is in Linux 3.2-rc1. > > > > The implementation in Linux uses packet counts, not bytes. Yes this > causes > > a number of artifacts. > > > > The transactional nature of the web and video (codic) pacing both cause > > frequent "application stalls" which cause much of our intuition about h= ow > > TCP typically operates to be somewhat inaccurate. > > > > I believe that all of your suggestions were evaluated empirically and > > didn't pan out. Several alternative algorithms were tested but not > > described in the paper. I can speak to the one that surprised me, whe= re > > my intuition initially matched yours, but the numbers just didn't agree= . > > > > The issue is SS during recovery. Consider the situation were the > > cwnd=3DFlightSize=3D10, and you lose 8 packets. Without slowstart duri= ng the > > recovery it would be completed with a window of 2, taking 5 RTTs. > > Furthermore any additional losses are very likely to cause a timeout. > > Compare this to RFC3517, which allows a 3 packet burst, to complete th= e > > recovery in 2 RTTs. > > > > Although this seems like a corner case, it happens frequently enough to > be > > statistically significant in the measurement data. For PRR, in this > case > > each of the two ACKs will cause 2 segments to be sent (4 total), as doe= s > > the first ACK of the next RTT (thus pipe=3D5). Note that both RFC3517= and > > PRR send 3 extra packets during recovery, either in a burst or > > in response to three different ACKs. > > > > It turns out that due to the risk of additional losses, PRR's > > average performance is slightly better than RFC3517, even though under > > identical conditions PRR transmits exactly the same amount of data but > > slightly later. > > > > If the existing standard had not specify something so aggressive, we ma= y > > have chosen to to do it as as you suggest, but proposing a > > new standard that performs worse than the existing standard was a > > non-starter. > > > > I am working on an ID that proposes to re-factor TCP congestion control= , > > which will bring the many of your observations into focus. > > > > Re: ECN. Last time we checked it caused a measurable increase in the > > number of failed user requests, probably due to return paths that > > unconditionally discard packets with ECN marks. Note that the forward > path > > must be delivering them, which seems rather odd. But yes, we are > > tinkering with ECN, and would like to help foster its deployment. > > > > Thanks, > > --MM-- > > The best way to predict the future is to create it. - Alan Kay > > > > > > > > On Wed, Feb 1, 2012 at 9:18 AM, Mirja K=FChlewind < > > > > mirja.kuehlewind@ikr.uni-stuttgart.de> wrote: > > > Hi Matt, > > > > > > I reviewed the PRR algorithm. Actually I read your IMC paper and not > the > > > draft > > > but I hope its the same algorithm ;-) > > > > > > Let me summarize the main points from my understanding and then I hav= e > > > some questions/comments: > > > > > > I think there are 3 changes compared to the current Linux > implementation: > > > > > > 1) You removed the limitation that the cwnd can't be larger that > > > fight_size+1 > > > in recovery > > > -> Agreed, this limitation does not make sense and really causes > > > problems > > > > > > 2) Make reduction dependent on congestion control > > > -> This is an implementational thing. Currently Linux will reduce > > > (hard-coded) on every second ACK which will (eventually) lead to a > > > havling of > > > the cwnd. I agree that this decision should be made by the CC algo bu= t > > > its mainly Linux not providing an easy interface to do so. > > > > > > 3) SS like increase in recovery > > > -> This follows directly from point 2. There is a way to reset the > cwnd > > > after recovery to any value but Linux will still limit the cwnd to > > > flight_size+max_burst_size. max_burst_size is (hard-coded) 3 in Linux > and > > > this limitation make sense to avoid large bursts. Here comes your SS > idea > > > into the game. You try to maintain the min cwnd close to ssthresh in > > > recovery > > > to avoid any bursts right after recovery when you set your cwnd to th= e > > > value > > > determined by the congestion control algorithm. > > > > > > Here my comments: > > > > > > 1) Bursts: > > > As said above the limitation to flight_size+1 is wrong and causes a t= oo > > > conservation behavior of the Linux kernel. But actually the problem i= s > > > mainly > > > because of the +1. I believe there should still be a limitation of th= e > > > max burst size (e.g. 3 as used by Linux). In your algorithm it possib= le > > > to have very arge burst in under certain circumstances, right? > > > At least there should be: > > > At the end of recovery: > > > cwnd =3D min(ssthresh, flight_size + max_burst_size) > > > > > > 2) SS: > > > The SS thing is a smart idea but I'm not sure if its really needed. Y= ou > > > run into the SS part if you have large burst losses or you are > > > application-limited. I would say both cases are worth to be > conservative. > > > As > > > soon as you leave recovery and your cwnd is below ssthresh you will b= e > in > > > slow start anyway. You paper is saying in your measurement you were i= n > > > 32% in > > > the slow start phase at the beginning of recovery. This seems to be a > > > really > > > high value. Do you know what's happening there? Is this due to > > > application limitations or burst losses? I would guess its loss. But = if > > > you have a lot of > > > small transmission which hardly leave slow start, it might also expla= in > > > this > > > number. Maybe both cases even need to be handled differently...? > > > > > > 3) DeliveredData: > > > You are using the number of ack'ed bytes. That means you need to have > the > > > cwnd > > > and ssthresh also in bytes (not sure if this is said explicitly > anyway). > > > The > > > Linux kernel mostly used number of packets and also assumes that ther= e > > > will be an ACK for every new packet in recovery. These assumptions > might > > > be not correct anymore. But I'm not sure if this should be changed > > > implicit in this > > > proposal. This might be an important topic on its own which might hav= e > > > more implications (if implemented every correctly). > > > > > > And I have two more questions: > > > 2) In the paper you say this algorithm will be in the mainline of the > > > Linux kernel. I checked and I dont think it is there yet...? Do you > have > > > a patch available? > > > 3) And one completely different question: In the paper you say ECN is > > > disabled > > > on Google servers. Why is this? > > > > > > Regards, > > > Mirja > > > > -- > ------------------------------------------------------------------- > Dipl.-Ing. Mirja K=FChlewind > Institute of Communication Networks and Computer Engineering (IKR) > University of Stuttgart, Germany > Pfaffenwaldring 47, D-70569 Stuttgart > > tel: +49(0)711/685-67973 > email: mirja.kuehlewind@ikr.uni-stuttgart.de > web: www.ikr.uni-stuttgart.de > ------------------------------------------------------------------- > --0015174478f2576c6d04b81561d9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I should have been clearer. =A0 The "not a corner case" I was ref= erring to was losses exceeding the=A0chosen=A0window reduction, which is th= e situation that causes 3517 to send bursts and PRR to invoke slowstarts du= ring recovery. =A0 We observe that this happens in 32% of the recovery even= ts.

You are correct that a single connection into a single bottl= eneck should not cause more than %50 losses. =A0 The most likely cause are = bursts on other connections. =A0Note that depending on how the packets from= two concurrent=A0slowstarts=A0are interleaved, you expect the losses from = to be slightly=A0asymmetric. =A0=A0=A0If the receiver is doing "fast A= CKs" to speed slowstart, then you would expect more than 50% losses to= be=A0reasonably=A0common.

However, the primary cause for our data was probably QU= BIC itself, which only invokes a 30% reduction. =A0This=A0plus fast ACK plu= s drop tail is likely cause losses to=A0frequently=A0exceed=A0the target=A0= reduction.

We do not have data on how frequently connections exper= ience 80% losses

And you are correct, IW10 could b= e contributing. =A0We tried to quantify that, but couldn't. =A0What is = really needed is =A0a TCP header study from=A0within=A0an ISP, just upstrea= m of the=A0primary=A0bottleneck, for all sorts of types of bottleneck gear,= clients and content sources.

Thanks,
--MM--
The best way to predic= t the future is to create it. =A0- Alan Kay



On Fri, Feb 3, 2012 at 9:03 AM, Mirja Ku= ehlewind <mirja.kuehlewind@ikr.uni-stuttgart.de>= ; wrote:
Hi Matt,

I agree with a lot of things you said. But regarding your example of cwnd 1= 0
and 8 losses I'm not sure. You say its not a corner case. I understand = that
you have many small flows not leaving slow start. But in this case you have=
lost 80% of your packet. I would have expected a max loss of 50% of my
packets in SS. For me that means 80% is a really high load situation and I<= br> should be even more careful...!?!

Mirja

Btw. if this is not a corner case maybe IW of 10 is not a good idea...


On Wednesday 01 February 2012 20:01:49 Matt Mathis wrote:
> First the quick answers: PRR is in Linux 3.2-rc1.
>
> The implementation in Linux uses packet counts, not bytes. =A0Yes this= causes
> a number of artifacts.
>
> The transactional nature of the web and video (codic) pacing both caus= e
> frequent "application stalls" which cause much of our intuit= ion about how
> TCP typically operates to be somewhat inaccurate.
>
> I believe that all of your suggestions were evaluated empirically and<= br> > didn't pan out. =A0Several alternative algorithms were tested but = not
> described in the paper. =A0 I can speak to the one that surprised me, = where
> my intuition initially matched yours, but the numbers just didn't = agree.
>
> The issue is SS during recovery. =A0 =A0Consider the situation were th= e
> cwnd=3DFlightSize=3D10, and you lose 8 packets. =A0Without slowstart d= uring the
> recovery it would be completed with a window of 2, taking 5 RTTs.
> =A0Furthermore any additional losses are very likely to cause a timeou= t.
> =A0Compare this to RFC3517, which allows a 3 packet burst, to complete= the
> recovery in 2 RTTs.
>
> Although this seems like a corner case, it happens frequently enough t= o be
> statistically significant in the measurement data. =A0 For PRR, in thi= s case
> each of the two ACKs will cause 2 segments to be sent (4 total), as do= es
> the first ACK of the next RTT (thus pipe=3D5). =A0 Note that both RFC3= 517 and
> PRR send 3 extra packets during recovery, either in a burst or
> in response to =A0three different ACKs.
>
> It turns out that due to the risk of additional losses, PRR's
> average performance is =A0slightly better than RFC3517, even though un= der
> identical conditions PRR transmits exactly the same amount of data but=
> slightly later.
>
> If the existing standard had not specify something so aggressive, we m= ay
> have chosen to to do it as as you suggest, but proposing a
> new standard that performs worse than the existing standard was a
> non-starter.
>
> I am working on an ID that proposes to re-factor TCP congestion contro= l,
> which will bring the many of your observations into focus.
>
> Re: ECN. =A0Last time we checked it caused a measurable increase in th= e
> number of failed user requests, probably due to return paths that
> unconditionally discard packets with ECN marks. =A0Note that the forwa= rd path
> must be delivering them, which seems rather odd. =A0 =A0But yes, we ar= e
> tinkering with ECN, and would like to help foster its deployment.
>
> Thanks,
> --MM--
> The best way to predict the future is to create it. =A0- Alan Kay
>
>
>
> On Wed, Feb 1, 2012 at 9:18 AM, Mirja K=FChlewind <
>
> mirja.kuehlewind@ikr.uni-stuttgart.de> wrote:
> > Hi Matt,
> >
> > I reviewed the PRR algorithm. Actually I read your IMC paper and = not the
> > draft
> > but I hope its the same algorithm ;-)
> >
> > Let me summarize the main points from my understanding and then I= have
> > some questions/comments:
> >
> > I think there are 3 changes compared to the current Linux impleme= ntation:
> >
> > 1) You removed the limitation that the cwnd can't be larger t= hat
> > fight_size+1
> > in recovery
> > =A0 -> Agreed, this limitation does not make sense and really = causes
> > problems
> >
> > 2) Make reduction dependent on congestion control
> > =A0 -> This is an implementational thing. Currently Linux will= reduce
> > (hard-coded) on every second ACK which will (eventually) lead to = a
> > havling of
> > the cwnd. I agree that this decision should be made by the CC alg= o but
> > its mainly Linux not providing an easy interface to do so.
> >
> > 3) SS like increase in recovery
> > =A0 -> This follows directly from point 2. There is a way to r= eset the cwnd
> > after recovery to any value but Linux will still limit the cwnd t= o
> > flight_size+max_burst_size. max_burst_size is (hard-coded) 3 in L= inux and
> > this limitation make sense to avoid large bursts. Here comes your= SS idea
> > into the game. You try to maintain the min cwnd close to ssthresh= in
> > recovery
> > to avoid any bursts right after recovery when you set your cwnd t= o the
> > value
> > determined by the congestion control algorithm.
> >
> > Here my comments:
> >
> > 1) Bursts:
> > As said above the limitation to flight_size+1 is wrong and causes= a too
> > conservation behavior of the Linux kernel. But actually the probl= em is
> > mainly
> > because of the +1. I believe there should still be a limitation o= f the
> > max burst size (e.g. 3 as used by Linux). In your algorithm it po= ssible
> > to have very arge burst in under certain circumstances, right? > > At least there should be:
> > =A0 =A0 =A0 =A0At the end of recovery:
> > =A0 =A0 =A0 =A0cwnd =3D min(ssthresh, flight_size + max_burst_siz= e)
> >
> > 2) SS:
> > The SS thing is a smart idea but I'm not sure if its really n= eeded. You
> > run into the SS part if you have large burst losses or you are > > application-limited. I would say both cases are worth to be conse= rvative.
> > As
> > soon as you leave recovery and your cwnd is below ssthresh you wi= ll be in
> > slow start anyway. You paper is saying in your measurement you we= re in
> > 32% in
> > the slow start phase at the beginning of recovery. This seems to = be a
> > really
> > high value. Do you know what's happening there? Is this due t= o
> > application limitations or burst losses? I would guess its loss. = But if
> > you have a lot of
> > small transmission which hardly leave slow start, it might also e= xplain
> > this
> > number. Maybe both cases even need to be handled differently...?<= br> > >
> > 3) DeliveredData:
> > You are using the number of ack'ed bytes. That means you need= to have the
> > cwnd
> > and ssthresh also in bytes (not sure if this is said explicitly a= nyway).
> > The
> > Linux kernel mostly used number of packets and also assumes that = there
> > will be an ACK for every new packet in recovery. These assumption= s might
> > be not correct anymore. But I'm not sure if this should be ch= anged
> > implicit in this
> > proposal. This might be an important topic on its own which might= have
> > more implications (if implemented every correctly).
> >
> > And I have two more questions:
> > 2) In the paper you say this algorithm will be in the mainline of= the
> > Linux kernel. I checked and I dont think it is there yet...? Do y= ou have
> > a patch available?
> > 3) And one completely different question: In the paper you say EC= N is
> > disabled
> > on Google servers. Why is this?
> >
> > Regards,
> > Mirja



--
-------------------------------------------------------------------
Dipl.-Ing. Mirja K=FChlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973
email: mirja.kuehlewind@ikr.uni-stuttgart.de
web: www.ikr.= uni-stuttgart.de
-------------------------------------------------------------------

--0015174478f2576c6d04b81561d9-- From pasi.sarolahti@iki.fi Wed Feb 8 05:01:18 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE49B21F86A4 for ; Wed, 8 Feb 2012 05:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.799 X-Spam-Level: X-Spam-Status: No, score=-105.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbXyGDxkB6mL for ; Wed, 8 Feb 2012 05:01:18 -0800 (PST) Received: from smtp-3.hut.fi (smtp-3.hut.fi [130.233.228.93]) by ietfa.amsl.com (Postfix) with ESMTP id D461921F86A2 for ; Wed, 8 Feb 2012 05:01:17 -0800 (PST) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-3.hut.fi (8.13.6/8.12.10) with ESMTP id q18D1Gw6016975 for ; Wed, 8 Feb 2012 15:01:16 +0200 Received: from smtp-3.hut.fi ([130.233.228.93]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 29673-836 for ; Wed, 8 Feb 2012 15:01:16 +0200 (EET) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-3.hut.fi (8.13.6/8.12.10) with ESMTP id q18D1CH4016968 for ; Wed, 8 Feb 2012 15:01:12 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 837E41E12C for ; Wed, 8 Feb 2012 15:01:12 +0200 (EET) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Es9cZNIaqJtf for ; Wed, 8 Feb 2012 15:01:08 +0200 (EET) Received: from pc106.netlab.hut.fi (pc106.netlab.hut.fi [130.233.154.106]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id 7861F1E0C1 for ; Wed, 8 Feb 2012 15:01:08 +0200 (EET) From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Feb 2012 15:01:06 +0200 Message-Id: <263ACA35-149C-4896-8FFE-69CB7E096626@iki.fi> To: tcpm@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Subject: [tcpm] WGLC for draft-ietf-tcpm-3517bis-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 13:01:19 -0000 Hello, The authors of "A Conservative Selective Acknowledgment (SACK)-based = Loss Recovery Algorithm for TCP" (draft-ietf-tcpm-3517bis-01) think the = latest version addresses all comments made on the draft. Therefore, this = mail starts Working Group Last Call for the draft, intended to be = published as Proposed Standard. The WGLC ends on Friday, February 24, = i.e., within a bit over two weeks.=20 Please read the draft and send any comments to the TCPM mailing list by = the above deadline. If you think the draft is ok and ready to be = published without further changes, indicating that would also be = helpful. The draft is available at = http://tools.ietf.org/html/draft-ietf-tcpm-3517bis-01 - Pasi From abartomeu@swissms.ch Wed Feb 8 04:15:38 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B870E21F8637 for ; Wed, 8 Feb 2012 04:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.885 X-Spam-Level: X-Spam-Status: No, score=-0.885 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILrFOnRO2qZn for ; Wed, 8 Feb 2012 04:15:38 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id F394621F8636 for ; Wed, 8 Feb 2012 04:15:37 -0800 (PST) Received: by eaal12 with SMTP id l12so161274eaa.31 for ; Wed, 08 Feb 2012 04:15:37 -0800 (PST) Received: by 10.14.194.134 with SMTP id m6mr8524689een.4.1328703337095; Wed, 08 Feb 2012 04:15:37 -0800 (PST) Received: from abartomeu-imac-c.eng.swissms.ch ([213.172.47.200]) by mx.google.com with ESMTPS id n58sm4575511een.10.2012.02.08.04.15.35 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 08 Feb 2012 04:15:36 -0800 (PST) From: =?iso-8859-1?Q?=C1ngel_Bartomeu_Bonillo?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Feb 2012 13:15:32 +0100 Message-Id: <920E9EEF-0BD8-4CB4-B385-149FCBC799E1@swissms.ch> To: tcpm@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [tcpm] Aid passive estimate of tcp performance X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 14:40:14 -0000 Hello, I recently faced the problem of passively estimating the packet loss of = TCP connection. After a bit of investigating the literature I found that = there are tens of papers addressing this issue but I couldn't find any = perfect solution.=20 Since this is an important issue for network operators I have been = thinking that there would be a very easy solution by just making the two = TCP connection end points to account for its sent segments and report it = to the other end point in the FIN segment. This approach could be used as well for other measurable parameters = along the TCP session without the need for any other offline method and = It would be very helpful for detecting failures along networks.=20 Any comments? Thanks for your time.= From perfgeek@mac.com Wed Feb 8 08:32:59 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB03B21F8608 for ; Wed, 8 Feb 2012 08:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbPUZaFz+Qsa for ; Wed, 8 Feb 2012 08:32:57 -0800 (PST) Received: from asmtpout014.mac.com (asmtpout014.mac.com [17.148.16.89]) by ietfa.amsl.com (Postfix) with ESMTP id 0940221F85F8 for ; Wed, 8 Feb 2012 08:32:57 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Received: from [192.168.1.65] (76-220-56-223.lightspeed.sntcca.sbcglobal.net [76.220.56.223]) by asmtp014.mac.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0LZ300E9Z1YUIV20@asmtp014.mac.com> for tcpm@ietf.org; Wed, 08 Feb 2012 16:32:56 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7361,1.0.260,0.0.0000 definitions=2012-02-08_07:2012-02-08, 2012-02-08, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1202080144 From: rick jones In-reply-to: <920E9EEF-0BD8-4CB4-B385-149FCBC799E1@swissms.ch> Date: Wed, 08 Feb 2012 08:32:54 -0800 Content-transfer-encoding: quoted-printable Message-id: <555E24DE-0950-4471-B5B3-4902CF0AA833@mac.com> References: <920E9EEF-0BD8-4CB4-B385-149FCBC799E1@swissms.ch> To: =?iso-8859-1?Q?=C1ngel_Bartomeu_Bonillo?= X-Mailer: Apple Mail (2.1084) Cc: tcpm@ietf.org Subject: Re: [tcpm] Aid passive estimate of tcp performance X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 16:32:59 -0000 On Feb 8, 2012, at 4:15 AM, =C1ngel Bartomeu Bonillo wrote: > Hello, >=20 > I recently faced the problem of passively estimating the packet loss = of TCP connection. After a bit of investigating the literature I found = that there are tens of papers addressing this issue but I couldn't find = any perfect solution.=20 > Since this is an important issue for network operators I have been = thinking that there would be a very easy solution by just making the two = TCP connection end points to account for its sent segments and report it = to the other end point in the FIN segment. > This approach could be used as well for other measurable parameters = along the TCP session without the need for any other offline method and = It would be very helpful for detecting failures along networks.=20 >=20 > Any comments? If the count is reported in a FIN segment, isn't that rather like = closing the barn door after the horses have left? At least as far as = doing anything for that connection is concerned. So, already we are = talking about operating on timescales larger than connection lifetimes. = And what would the side receiving the count-containing FIN do with this = information? Sure, now it is known on both ends, but the problem still = lies somewhere in the middle (not always, but often). Is it expected = that points along the middle will be sniffing this? What would they do = in response? What could they (reasonably) do in response with that = information just from TCP vs any other transports? When a sending TCP sends the first FIN with a count at the end of a MB = window would it retransmit the FIN, even if the first was received, to = include retransmissions in that last window's-worth of data? How long = would the receiving TCP wait for this "final tally, really" FIN to = arrive after it sent the ACK to SEQfin to then pass-along the count to a = higher layer, somehow? I think we are already asking for enough angels to dance on the TCP = pin-header. rick jones= From ycheng@google.com Wed Feb 8 08:43:32 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9585B21F861D for ; Wed, 8 Feb 2012 08:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.827 X-Spam-Level: X-Spam-Status: No, score=-102.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ra25gJkcYeqA for ; Wed, 8 Feb 2012 08:43:31 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C896C21F8617 for ; Wed, 8 Feb 2012 08:43:31 -0800 (PST) Received: by obbwd15 with SMTP id wd15so1245082obb.31 for ; Wed, 08 Feb 2012 08:43:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type:content-transfer-encoding; bh=rIpTRPhdmBk6n7DbBdebAFTXlNNwlOffGizVp8i+WtE=; b=L3TA80wL3JMw89dVuyqYDvJiGNBUU3q9KDR/RKW/2rbIXBOfe3314s8PZ52XrT9W5r dHmqsAeDr34nXrvemMfgJu7bDpOxtp5+HRuIevFAW+a3tcX+NDc8ZE01nIUoEuA1I3Oy 1I+YQbPhA4ruSj8XDVngO9DOD6YscmYAZx6HY= Received: by 10.182.72.35 with SMTP id a3mr26667988obv.16.1328719411417; Wed, 08 Feb 2012 08:43:31 -0800 (PST) Received: by 10.182.72.35 with SMTP id a3mr26667963obv.16.1328719411267; Wed, 08 Feb 2012 08:43:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.212.37 with HTTP; Wed, 8 Feb 2012 08:43:11 -0800 (PST) In-Reply-To: <555E24DE-0950-4471-B5B3-4902CF0AA833@mac.com> References: <920E9EEF-0BD8-4CB4-B385-149FCBC799E1@swissms.ch> <555E24DE-0950-4471-B5B3-4902CF0AA833@mac.com> From: Yuchung Cheng Date: Wed, 8 Feb 2012 08:43:11 -0800 Message-ID: To: rick jones X-System-Of-Record: true Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tcpm@ietf.org Subject: Re: [tcpm] Aid passive estimate of tcp performance X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 16:43:32 -0000 I second that. Even TCP end host can not get this 100%: spurious retransmission can not be perfectly detected w/ ack path loss for instance. On Wed, Feb 8, 2012 at 8:32 AM, rick jones wrote: > > On Feb 8, 2012, at 4:15 AM, =C1ngel Bartomeu Bonillo wrote: > >> Hello, >> >> I recently faced the problem of passively estimating the packet loss of = TCP connection. After a bit of investigating the literature I found that th= ere are tens of papers addressing this issue but I couldn't find any perfec= t solution. >> Since this is an important issue for network operators I have been think= ing that there would be a very easy solution by just making the two TCP con= nection end points to account for its sent segments and report it to the ot= her end point in the FIN segment. >> This approach could be used as well for other measurable parameters alon= g the TCP session without the need for any other offline method and It woul= d be very helpful for detecting failures along networks. >> >> Any comments? > > If the count is reported in a FIN segment, isn't that rather like closing= the barn door after the horses have left? =A0At least as far as doing anyt= hing for that connection is concerned. =A0So, already we are talking about = operating on timescales larger than connection lifetimes. =A0And what would= the side receiving the count-containing FIN do with this information? Sure= , now it is known on both ends, but the problem still lies somewhere in the= middle (not always, but often). =A0Is it expected that points along the mi= ddle will be sniffing this? =A0What would they do in response? =A0What coul= d they (reasonably) do in response with that information just from TCP vs a= ny other transports? > > When a sending TCP sends the first FIN with a count at the end of a MB wi= ndow would it retransmit the FIN, even if the first was received, to includ= e retransmissions in that last window's-worth of data? =A0How long would th= e receiving TCP wait for this "final tally, really" FIN to arrive after it = sent the ACK to SEQfin to then pass-along the count to a higher layer, some= how? > > I think we are already asking for enough angels to dance on the TCP pin-h= eader. > > rick jones > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Wed Feb 8 09:46:29 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABA321F873A for ; Wed, 8 Feb 2012 09:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.865 X-Spam-Level: X-Spam-Status: No, score=-102.865 tagged_above=-999 required=5 tests=[AWL=-0.566, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Dfmvh99z8Tn for ; Wed, 8 Feb 2012 09:46:28 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 679F621F85C0 for ; Wed, 8 Feb 2012 09:46:26 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q18Hjhwk022528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Feb 2012 09:45:43 -0800 (PST) Message-ID: <4F32B4C7.6070102@isi.edu> Date: Wed, 08 Feb 2012 09:45:43 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?=C1ngel_Bartomeu_Bonillo?= References: <920E9EEF-0BD8-4CB4-B385-149FCBC799E1@swissms.ch> In-Reply-To: <920E9EEF-0BD8-4CB4-B385-149FCBC799E1@swissms.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Aid passive estimate of tcp performance X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 17:46:29 -0000 On 2/8/2012 4:15 AM, Ángel Bartomeu Bonillo wrote: > Hello, > > I recently faced the problem of passively estimating the packet loss > of TCP connection. After a bit of investigating the literature I > found that there are tens of papers addressing this issue but I > couldn't find any perfect solution. Since this is an important issue > for network operators I have been thinking that there would be a very > easy solution by just making the two TCP connection end points to > account for its sent segments and report it to the other end point in > the FIN segment. This approach could be used as well for other > measurable parameters along the TCP session without the need for any > other offline method and It would be very helpful for detecting > failures along networks. > > Any comments? Regardless of when you do this - either at the end of a connection, or during a connection - the ONLY information you can provide is "here is a list of segments I have not yet received". However, that list is irrelevant. Those segments might be in the network and may still arrive - after you report, after the connection is over, etc. There is no way to KNOW that a segment is lost vs. late. Even when you retransmit a segment (e.g., because it is basically overdue, either because your side's timer expired or the other side sent either a SACK or ACK indicating a gap), you don't know that the first segment was lost - it could arrive after the timer expires. Even though segments have TTLs, and TTLs are *supposed* to be decremented once every second or once every hop (whichever is greater), there are devices that queue packets for long periods (e.g., when a link is interrupted) and send them on later (even though they should have been dropped). So there is no such information as "lost segments"; the best you know is retransmissions. However, keep in mind that there are lots of TCP connections that are terminated without a FIN (e.g., using a RST - I don't think it's appropriate in many cases, but the method is in widespread use). Joe From abartomeu@swissms.ch Wed Feb 8 09:53:03 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3422C21F8589 for ; Wed, 8 Feb 2012 09:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.662 X-Spam-Level: X-Spam-Status: No, score=-2.662 tagged_above=-999 required=5 tests=[AWL=0.637, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLwVcRR0qRZ0 for ; Wed, 8 Feb 2012 09:53:02 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 45B8121F85EC for ; Wed, 8 Feb 2012 09:53:01 -0800 (PST) Received: by eekc41 with SMTP id c41so282060eek.31 for ; Wed, 08 Feb 2012 09:53:01 -0800 (PST) Received: by 10.213.22.78 with SMTP id m14mr354173ebb.32.1328723581084; Wed, 08 Feb 2012 09:53:01 -0800 (PST) Received: from abartomeu-imac-c.eng.swissms.ch ([213.172.47.200]) by mx.google.com with ESMTPS id n17sm4622016eei.3.2012.02.08.09.52.58 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 08 Feb 2012 09:53:00 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?=C1ngel_Bartomeu_Bonillo?= In-Reply-To: <555E24DE-0950-4471-B5B3-4902CF0AA833@mac.com> Date: Wed, 8 Feb 2012 18:52:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <920E9EEF-0BD8-4CB4-B385-149FCBC799E1@swissms.ch> <555E24DE-0950-4471-B5B3-4902CF0AA833@mac.com> To: rick jones X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQlWJV0CX3gX7hNocKCHpDvbQBclTo2/DHs0eFbyNndDmibzg9Zpo7xVNz4HaYM31yZOzcqe Cc: tcpm@ietf.org Subject: Re: [tcpm] Aid passive estimate of tcp performance X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 17:53:03 -0000 Hi Rick,=20 El 08/02/2012, a las 17:32, rick jones escribi=F3: >=20 > On Feb 8, 2012, at 4:15 AM, =C1ngel Bartomeu Bonillo wrote: >=20 >> Hello, >>=20 >> I recently faced the problem of passively estimating the packet loss = of TCP connection. After a bit of investigating the literature I found = that there are tens of papers addressing this issue but I couldn't find = any perfect solution.=20 >> Since this is an important issue for network operators I have been = thinking that there would be a very easy solution by just making the two = TCP connection end points to account for its sent segments and report it = to the other end point in the FIN segment. >> This approach could be used as well for other measurable parameters = along the TCP session without the need for any other offline method and = It would be very helpful for detecting failures along networks.=20 >>=20 >> Any comments? >=20 > If the count is reported in a FIN segment, isn't that rather like = closing the barn door after the horses have left? At least as far as = doing anything for that connection is concerned. So, already we are = talking about operating on timescales larger than connection lifetimes. = And what would the side receiving the count-containing FIN do with this = information? Sure, now it is known on both ends, but the problem still = lies somewhere in the middle (not always, but often). Is it expected = that points along the middle will be sniffing this? What would they do = in response? What could they (reasonably) do in response with that = information just from TCP vs any other transports? >=20 I'm talking about timescales larger than the connection lifetimes. This = would be a mechanism so TCP can report how many packets it sent out. If = both ends send at the end of the session the number of packets they sent = out the other peer and anyone in the middle would be able to estimate de = loss in both directions. The idea is to enable TCP so it can report a little but valuable = information about its performance once the connection finished. This is = not a mechanism so TCP can adapt to losses in the middle of a = communication but rather a long term mechanism for network operators and = such. Nowadays many of the end user services use TCP and the end to end = packet loss is many times impossible to calculate mainly because only = the sending node knows the real number of packets sent out. For example = in the uplink direction on a mobile network. I think that adding just a couple of bytes (as a TCP option) to the FIN = segment would give a priceless information for network operators. > When a sending TCP sends the first FIN with a count at the end of a MB = window would it retransmit the FIN, even if the first was received, to = include retransmissions in that last window's-worth of data? How long = would the receiving TCP wait for this "final tally, really" FIN to = arrive after it sent the ACK to SEQfin to then pass-along the count to a = higher layer, somehow? The idea much simpler: the peer adds the num of packets sent during the = connection as an option in the FIN. There is no need to change TCP = behavior.=20 >=20 > I think we are already asking for enough angels to dance on the TCP = pin-header. >=20 > rick jones From Donald.Smith@CenturyLink.com Wed Feb 8 10:06:06 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93C521F8633 for ; Wed, 8 Feb 2012 10:06:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njjRTEp1JJ-g for ; Wed, 8 Feb 2012 10:06:05 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 512B421F8625 for ; Wed, 8 Feb 2012 10:06:05 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id q18I64FX007544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Feb 2012 11:06:04 -0700 (MST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id E706C1E005D; Wed, 8 Feb 2012 12:05:58 -0600 (CST) Received: from sudnp796.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id BC4361E0050; Wed, 8 Feb 2012 12:05:58 -0600 (CST) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id q18I5wJm029531; Wed, 8 Feb 2012 11:05:58 -0700 (MST) Received: from qtdenexhtm22.AD.QINTRA.COM (qtdenexhtm22.ad.qintra.com [151.119.91.231]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id q18I5rfe029401 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Wed, 8 Feb 2012 11:05:58 -0700 (MST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Wed, 8 Feb 2012 11:05:56 -0700 From: "Smith, Donald" To: "'Joe Touch'" , =?iso-8859-1?Q?=27=C1ngel_Bartomeu_Bonillo=27?= Date: Wed, 8 Feb 2012 11:05:55 -0700 Thread-Topic: [tcpm] Aid passive estimate of tcp performance Thread-Index: AczmiaDeYLJFpQ0uRbq4FX1YajbsUQAAcV4A Message-ID: References: <920E9EEF-0BD8-4CB4-B385-149FCBC799E1@swissms.ch> <4F32B4C7.6070102@isi.edu> In-Reply-To: <4F32B4C7.6070102@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "'tcpm@ietf.org'" Subject: Re: [tcpm] Aid passive estimate of tcp performance X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 18:06:06 -0000 Just agreeing with Joe, Many applications uses resets instead of a FIN hand= shake to terminate connections to speed things up especially browsers. http://pages.cpsc.ucalgary.ca/~carey/papers/2005/TCP-Resets.pdf When packets collide the controllers cease transmission AND wait a random t= ime before retransmission (mostly)! Donald.Smith@CenturyLink.com > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Joe Touch > Sent: Wednesday, February 08, 2012 10:46 AM > To: =C1ngel Bartomeu Bonillo > Cc: tcpm@ietf.org > Subject: Re: [tcpm] Aid passive estimate of tcp performance > > > > On 2/8/2012 4:15 AM, =C1ngel Bartomeu Bonillo wrote: > > Hello, > > > > I recently faced the problem of passively estimating the packet loss > > of TCP connection. After a bit of investigating the literature I > found > > that there are tens of papers addressing this issue but I couldn't > > find any perfect solution. Since this is an important issue for > > network operators I have been thinking that there would be a very > easy > > solution by just making the two TCP connection end points to account > > for its sent segments and report it to the other end point in the FIN > > segment. This approach could be used as well for other measurable > > parameters along the TCP session without the need for any other > > offline method and It would be very helpful for detecting failures > > along networks. > > > > Any comments? > > Regardless of when you do this - either at the end of a connection, or > during a connection - the ONLY information you can provide is "here is > a list of segments I have not yet received". > > However, that list is irrelevant. Those segments might be in the > network and may still arrive - after you report, after the connection > is over, etc. > > There is no way to KNOW that a segment is lost vs. late. > > Even when you retransmit a segment (e.g., because it is basically > overdue, either because your side's timer expired or the other side > sent either a SACK or ACK indicating a gap), you don't know that the > first segment was lost - it could arrive after the timer expires. > > Even though segments have TTLs, and TTLs are *supposed* to be > decremented once every second or once every hop (whichever is greater), > there are devices that queue packets for long periods (e.g., when a > link is interrupted) and send them on later (even though they should > have been dropped). > > So there is no such information as "lost segments"; the best you know > is retransmissions. > > However, keep in mind that there are lots of TCP connections that are > terminated without a FIN (e.g., using a RST - I don't think it's > appropriate in many cases, but the method is in widespread use). > > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From lars@netapp.com Wed Feb 8 10:16:13 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C2B21F8709 for ; Wed, 8 Feb 2012 10:16:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.224 X-Spam-Level: X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkdiYZ1-pNqn for ; Wed, 8 Feb 2012 10:16:12 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0718021F8700 for ; Wed, 8 Feb 2012 10:16:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.73,384,1325491200"; d="p7s'?scan'208";a="623684730" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 08 Feb 2012 10:16:08 -0800 Received: from sacrsexc2-prd.hq.netapp.com (sacrsexc2-prd.hq.netapp.com [10.99.115.28]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q18IG83c021450; Wed, 8 Feb 2012 10:16:08 -0800 (PST) Received: from SACMVEXC4-PRD.hq.netapp.com ([10.99.115.26]) by sacrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 10:16:00 -0800 Received: from VMWEXCEHT04-PRD.hq.netapp.com ([10.106.77.34]) by SACMVEXC4-PRD.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Feb 2012 10:16:00 -0800 Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.193]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.01.0355.002; Wed, 8 Feb 2012 10:16:00 -0800 From: "Eggert, Lars" To: =?iso-8859-1?Q?=C1ngel_Bartomeu_Bonillo?= Thread-Topic: [tcpm] Aid passive estimate of tcp performance Thread-Index: AQHM5m+VLaixrR8hE0OEu42bafz7HZYzt9oAgAAWVwCAAAZ3AA== Date: Wed, 8 Feb 2012 18:15:58 +0000 Message-ID: <9CB105FE-AFD1-482B-BB6E-0B66FBFB29F3@netapp.com> References: <920E9EEF-0BD8-4CB4-B385-149FCBC799E1@swissms.ch> <555E24DE-0950-4471-B5B3-4902CF0AA833@mac.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_38511537-385A-42C6-A326-08B41CBFA332"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-OriginalArrivalTime: 08 Feb 2012 18:16:00.0531 (UTC) FILETIME=[B602B630:01CCE68D] Cc: "" Subject: Re: [tcpm] Aid passive estimate of tcp performance X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 18:16:13 -0000 --Apple-Mail=_38511537-385A-42C6-A326-08B41CBFA332 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Feb 8, 2012, at 9:52, =C1ngel Bartomeu Bonillo wrote: > I'm talking about timescales larger than the connection lifetimes. = This would be a mechanism so TCP can report how many packets it sent = out. If both ends send at the end of the session the number of packets = they sent out the other peer and anyone in the middle would be able to = estimate de loss in both directions. You might want to take a look at what the CONEX WG is trying to do: = https://datatracker.ietf.org/wg/conex/charter/ Lars= --Apple-Mail=_38511537-385A-42C6-A326-08B41CBFA332 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDIwODE4MTYwMVowIwYJKoZIhvcNAQkEMRYEFNwC fTGtHHZgoiYni4JiJ8zFmVuiMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBACvI2eyB mgEdmGWi107tur5rwe4w+qRRJw2dD6MdoHf4slcQjQB/Wjv1g9b/hHaYABFQKpv07EUqB7FwTD7Y pPNXyykDnFbnGF0obQxk1FizxCIpvtXWc+aEwwOxcUO+o1BgSU66qkJLiRqG56gt2Ut+KJpFRmmV F+y104mbn6MrgieHiJTsRzN87rq3Q0ue5zSGUL6YDOwHzvTbbhkKnV6TJn23+pmtoglXQqUpm74B D7kwIJZO2Y5Af5pMZ1lint3BR1qM6O8BCansEI5/WAe3vZIdN83vsQ6KvUYw1gc8eLKYvs1KajQ5 XnpTYiXZzeXY5M9i8jnm+4rhYHVUyK0AAAAAAAA= --Apple-Mail=_38511537-385A-42C6-A326-08B41CBFA332-- From mallman@icir.org Wed Feb 8 10:23:48 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86E921F8571 for ; Wed, 8 Feb 2012 10:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.263 X-Spam-Level: X-Spam-Status: No, score=-106.263 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeAYOSFCoL6K for ; Wed, 8 Feb 2012 10:23:48 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 4E27621F84DC for ; Wed, 8 Feb 2012 10:23:48 -0800 (PST) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id q18INl7R024460; Wed, 8 Feb 2012 10:23:47 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id D007D6F406E; Wed, 8 Feb 2012 13:08:01 -0500 (EST) To: =?iso-8859-1?Q?=C1ngel_Bartomeu_Bonillo?= From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Back in the Saddle X-URL-0: http://www.icir.org/mallman-files/Document55399.jpg MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma47617-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 08 Feb 2012 13:08:01 -0500 Sender: mallman@icir.org Message-Id: <20120208180801.D007D6F406E@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] Aid passive estimate of tcp performance X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 18:23:49 -0000 ----------ma47617-1 Content-Type: text/plain Content-Disposition: inline I agree with Rick and the others. This doesn't seem terribly useful. > > When a sending TCP sends the first FIN with a count at the end of a > > MB window would it retransmit the FIN, even if the first was > > received, to include retransmissions in that last window's-worth of > > data? How long would the receiving TCP wait for this "final tally, > > really" FIN to arrive after it sent the ACK to SEQfin to then > > pass-along the count to a higher layer, somehow? > > The idea much simpler: the peer adds the num of packets sent during > the connection as an option in the FIN. There is no need to change TCP > behavior. I believe what Rick was saying was that you send a ton of packets and the last one has the FIN bit lit up. At that point these packets have no been ACKed. So, lets say the last window is 100 packets, the 100th packet has the FIN, and this makes 1000 packets in total the sender has transmitted. So, in the FIN we send "1000". Now, say 10 of the final 100 packets are lost and we have to retransmit those 10 packets. Now, the real total number of transmissions is 1010 and the number we stuffed in the FIN is wrong. If we want to get that number right then maybe we hold off on sending the FIN until the final 100 packets are ACKed (including needed retransmits). But, that is a change to TCP behavior. I think that is a relevant example. Several additional thoughts popped into my head ... - This is useless for the TCP connection. So, what is the incentive to bother stuffing it in there? Some warm and fuzzy lets help the operators notion? I doubt it. - This is useless for the TCP connection and so it doesn't make a lot of sense to me to add complexity to TCP for no tangible benefit. - You are right that passive loss estimators are not "perfect". But, I believe they get you reasonably close. How "perfect" do you need to be for operational purposes? My strong hunch is that the answer is "not perfect at all, the right order would be good". I.e., operators are going to make different decision when faced with loss rates of .1%, 1% and 10%. But, they are likely going to do the same thing with loss rates of .8%, 1%, 1.5% and 2%. Loss estimators are good enough to get you into that sort of ballpark. - If the endpoint will give you some information its for sure less work than doing the passive monitoring necessary. But, I am not sure reducing some operators' complexity by adding complexity (even modestly) to TCP is the right tradeoff. allman ----------ma47617-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk8yugEACgkQWyrrWs4yIs7WUgCdEGusRfFcVQl7yhtPFbDMyrrr poAAn2yIeKvZa6nBtYh+c50d7jc2SAYI =hzH3 -----END PGP SIGNATURE----- ----------ma47617-1-- From mellia@tlc.polito.it Wed Feb 8 10:56:23 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E8B21F8638 for ; Wed, 8 Feb 2012 10:56:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.323 X-Spam-Level: X-Spam-Status: No, score=-0.323 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oziaBlPk+EW7 for ; Wed, 8 Feb 2012 10:56:22 -0800 (PST) Received: from polito.it (eracle.polito.it [130.192.3.44]) by ietfa.amsl.com (Postfix) with ESMTP id F01A121F8635 for ; Wed, 8 Feb 2012 10:56:21 -0800 (PST) X-ExtScanner: Niversoft's FindAttachments (free) Received: from [94.34.226.43] (account d003516@polito.it HELO [192.168.1.5]) by eracle.polito.it (CommuniGate Pro SMTP 5.4.3) with ESMTPSA id 53909043; Wed, 08 Feb 2012 19:56:19 +0100 Received-SPF: none receiver=eracle.polito.it; client-ip=94.34.226.43; envelope-from=mellia@tlc.polito.it References: <20120208180801.D007D6F406E@lawyers.icir.org> In-Reply-To: <20120208180801.D007D6F406E@lawyers.icir.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <7B15E19A-6A11-425F-9AB2-BF30F30591F4@tlc.polito.it> X-Mailer: iPad Mail (9A405) From: Marco Mellia Date: Wed, 8 Feb 2012 20:01:56 +0100 To: "mallman@icir.org" Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Aid passive estimate of tcp performance X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 18:56:23 -0000 I just want to add that what the top stack sees today can be much different f= rom what the network carries... just think of offloading engines that fool t= he OS declaring a mss MTU of 16kB, then chop the segments into many smaller o= nes. Or some nasty nat box, or some load balancer in front of some server fa= rm... that is, passive tools will have a better picture in those cases... Inviato da iPad Il giorno 08/feb/2012, alle ore 19:08, Mark Allman ha scr= itto: >=20 > I agree with Rick and the others. This doesn't seem terribly useful. >=20 >>> When a sending TCP sends the first FIN with a count at the end of a >>> MB window would it retransmit the FIN, even if the first was >>> received, to include retransmissions in that last window's-worth of >>> data? How long would the receiving TCP wait for this "final tally, >>> really" FIN to arrive after it sent the ACK to SEQfin to then >>> pass-along the count to a higher layer, somehow?=20 >>=20 >> The idea much simpler: the peer adds the num of packets sent during >> the connection as an option in the FIN. There is no need to change TCP >> behavior. =20 >=20 > I believe what Rick was saying was that you send a ton of packets and > the last one has the FIN bit lit up. At that point these packets have > no been ACKed. So, lets say the last window is 100 packets, the 100th > packet has the FIN, and this makes 1000 packets in total the sender has > transmitted. So, in the FIN we send "1000". Now, say 10 of the final > 100 packets are lost and we have to retransmit those 10 packets. Now, > the real total number of transmissions is 1010 and the number we stuffed > in the FIN is wrong. If we want to get that number right then maybe we > hold off on sending the FIN until the final 100 packets are ACKed > (including needed retransmits). But, that is a change to TCP behavior. > I think that is a relevant example. >=20 > Several additional thoughts popped into my head ... >=20 > - This is useless for the TCP connection. So, what is the incentive > to bother stuffing it in there? Some warm and fuzzy lets help the > operators notion? I doubt it. >=20 > - This is useless for the TCP connection and so it doesn't make a lot > of sense to me to add complexity to TCP for no tangible benefit. >=20 > - You are right that passive loss estimators are not "perfect". But, > I believe they get you reasonably close. How "perfect" do you need > to be for operational purposes? My strong hunch is that the answer > is "not perfect at all, the right order would be good". I.e., > operators are going to make different decision when faced with loss > rates of .1%, 1% and 10%. But, they are likely going to do the same > thing with loss rates of .8%, 1%, 1.5% and 2%. Loss estimators are > good enough to get you into that sort of ballpark. >=20 > - If the endpoint will give you some information its for sure less > work than doing the passive monitoring necessary. But, I am not > sure reducing some operators' complexity by adding complexity (even > modestly) to TCP is the right tradeoff. >=20 > allman >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Wed Feb 8 10:58:06 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B7221F8562 for ; Wed, 8 Feb 2012 10:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIWDAuGAYUn2 for ; Wed, 8 Feb 2012 10:58:05 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 4330C21F855D for ; Wed, 8 Feb 2012 10:58:05 -0800 (PST) Received: from [207.151.141.96] ([207.151.141.96]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q18IusEb019494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Feb 2012 10:57:25 -0800 (PST) Message-ID: <4F32C573.6090606@isi.edu> Date: Wed, 08 Feb 2012 10:56:51 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Smith, Donald" References: <920E9EEF-0BD8-4CB4-B385-149FCBC799E1@swissms.ch> <4F32B4C7.6070102@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "'tcpm@ietf.org'" Subject: Re: [tcpm] Aid passive estimate of tcp performance X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 18:58:06 -0000 On 2/8/2012 10:05 AM, Smith, Donald wrote: > Just agreeing with Joe, Many applications uses resets instead of a FIN handshake to terminate connections to speed things up especially browsers. > > > http://pages.cpsc.ucalgary.ca/~carey/papers/2005/TCP-Resets.pdf It doesn't just "speed" things; it's reckless and dangerous, esp. since the parties tossing around these RSTs typically don't maintain TIME-WAIT before reusing those connection IDs. Joe >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >> Joe Touch >> Sent: Wednesday, February 08, 2012 10:46 AM >> To: Ángel Bartomeu Bonillo >> Cc: tcpm@ietf.org >> Subject: Re: [tcpm] Aid passive estimate of tcp performance >> >> >> >> On 2/8/2012 4:15 AM, Ángel Bartomeu Bonillo wrote: >>> Hello, >>> >>> I recently faced the problem of passively estimating the packet loss >>> of TCP connection. After a bit of investigating the literature I >> found >>> that there are tens of papers addressing this issue but I couldn't >>> find any perfect solution. Since this is an important issue for >>> network operators I have been thinking that there would be a very >> easy >>> solution by just making the two TCP connection end points to account >>> for its sent segments and report it to the other end point in the FIN >>> segment. This approach could be used as well for other measurable >>> parameters along the TCP session without the need for any other >>> offline method and It would be very helpful for detecting failures >>> along networks. >>> >>> Any comments? >> >> Regardless of when you do this - either at the end of a connection, or >> during a connection - the ONLY information you can provide is "here is >> a list of segments I have not yet received". >> >> However, that list is irrelevant. Those segments might be in the >> network and may still arrive - after you report, after the connection >> is over, etc. >> >> There is no way to KNOW that a segment is lost vs. late. >> >> Even when you retransmit a segment (e.g., because it is basically >> overdue, either because your side's timer expired or the other side >> sent either a SACK or ACK indicating a gap), you don't know that the >> first segment was lost - it could arrive after the timer expires. >> >> Even though segments have TTLs, and TTLs are *supposed* to be >> decremented once every second or once every hop (whichever is greater), >> there are devices that queue packets for long periods (e.g., when a >> link is interrupted) and send them on later (even though they should >> have been dropped). >> >> So there is no such information as "lost segments"; the best you know >> is retransmissions. >> >> However, keep in mind that there are lots of TCP connections that are >> terminated without a FIN (e.g., using a RST - I don't think it's >> appropriate in many cases, but the method is in widespread use). >> >> Joe >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly > prohibited and may be unlawful. If you have received this communication > in error, please immediately notify the sender by reply e-mail and destroy > all copies of the communication and any attachments. From touch@isi.edu Wed Feb 8 11:00:38 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A3721F85A5 for ; Wed, 8 Feb 2012 11:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.266 X-Spam-Level: X-Spam-Status: No, score=-103.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nrb0ksWtaOYb for ; Wed, 8 Feb 2012 11:00:38 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8EC21F859F for ; Wed, 8 Feb 2012 11:00:38 -0800 (PST) Received: from [207.151.141.96] ([207.151.141.96]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q18J03In020454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Feb 2012 11:00:11 -0800 (PST) Message-ID: <4F32C632.8070403@isi.edu> Date: Wed, 08 Feb 2012 11:00:02 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Marco Mellia References: <20120208180801.D007D6F406E@lawyers.icir.org> <7B15E19A-6A11-425F-9AB2-BF30F30591F4@tlc.polito.it> In-Reply-To: <7B15E19A-6A11-425F-9AB2-BF30F30591F4@tlc.polito.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" , "mallman@icir.org" Subject: Re: [tcpm] Aid passive estimate of tcp performance X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 19:00:38 -0000 Hi, all, On 2/8/2012 11:01 AM, Marco Mellia wrote: > I just want to add that what the top stack sees today can be much different from what the network carries... just think of offloading engines that fool the OS declaring a mss MTU of 16kB, then chop the segments into many smaller ones. Or some nasty nat box, or some load balancer in front of some server farm... > that is, passive tools will have a better picture in those cases... It's impossible to account for forgers; if a proxy terminates a connection for an IP address it doesn't own, all bets are off for active *and* passive analysis. Joe > > Inviato da iPad > > Il giorno 08/feb/2012, alle ore 19:08, Mark Allman ha scritto: > >> >> I agree with Rick and the others. This doesn't seem terribly useful. >> >>>> When a sending TCP sends the first FIN with a count at the end of a >>>> MB window would it retransmit the FIN, even if the first was >>>> received, to include retransmissions in that last window's-worth of >>>> data? How long would the receiving TCP wait for this "final tally, >>>> really" FIN to arrive after it sent the ACK to SEQfin to then >>>> pass-along the count to a higher layer, somehow? >>> >>> The idea much simpler: the peer adds the num of packets sent during >>> the connection as an option in the FIN. There is no need to change TCP >>> behavior. >> >> I believe what Rick was saying was that you send a ton of packets and >> the last one has the FIN bit lit up. At that point these packets have >> no been ACKed. So, lets say the last window is 100 packets, the 100th >> packet has the FIN, and this makes 1000 packets in total the sender has >> transmitted. So, in the FIN we send "1000". Now, say 10 of the final >> 100 packets are lost and we have to retransmit those 10 packets. Now, >> the real total number of transmissions is 1010 and the number we stuffed >> in the FIN is wrong. If we want to get that number right then maybe we >> hold off on sending the FIN until the final 100 packets are ACKed >> (including needed retransmits). But, that is a change to TCP behavior. >> I think that is a relevant example. >> >> Several additional thoughts popped into my head ... >> >> - This is useless for the TCP connection. So, what is the incentive >> to bother stuffing it in there? Some warm and fuzzy lets help the >> operators notion? I doubt it. >> >> - This is useless for the TCP connection and so it doesn't make a lot >> of sense to me to add complexity to TCP for no tangible benefit. >> >> - You are right that passive loss estimators are not "perfect". But, >> I believe they get you reasonably close. How "perfect" do you need >> to be for operational purposes? My strong hunch is that the answer >> is "not perfect at all, the right order would be good". I.e., >> operators are going to make different decision when faced with loss >> rates of .1%, 1% and 10%. But, they are likely going to do the same >> thing with loss rates of .8%, 1%, 1.5% and 2%. Loss estimators are >> good enough to get you into that sort of ballpark. >> >> - If the endpoint will give you some information its for sure less >> work than doing the passive monitoring necessary. But, I am not >> sure reducing some operators' complexity by adding complexity (even >> modestly) to TCP is the right tradeoff. >> >> allman >> >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From gettysjim@gmail.com Wed Feb 8 11:03:13 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4F721F85A8 for ; Wed, 8 Feb 2012 11:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5EbX+y0JA1q for ; Wed, 8 Feb 2012 11:03:12 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id A59BE21F85EA for ; Wed, 8 Feb 2012 11:03:10 -0800 (PST) Received: by qan41 with SMTP id 41so595663qan.10 for ; Wed, 08 Feb 2012 11:03:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=H8GGBk8BHxqAzNEIsJU34jIOxoKBzNtjppUmDbRPPcI=; b=gbhTyyKlpCq17mZY8EVQCOwSe1P4blnM/iaGzR6jdtJVjBKDT/TQUw8RbCrrsuON+1 MagSdViPpGoFxlrpUlijkm4hcWTX1JOUyWJzW9FSl3dbjvLYwoUOPED+wU7+/8d+Ni1g 49MJkUGx5B4LQHhmOnZHcWX47osw0YtkvQGfI= Received: by 10.224.185.71 with SMTP id cn7mr14021135qab.82.1328727789875; Wed, 08 Feb 2012 11:03:09 -0800 (PST) Received: from [192.168.1.27] (c-24-63-191-17.hsd1.ma.comcast.net. [24.63.191.17]) by mx.google.com with ESMTPS id o8sm370763qan.11.2012.02.08.11.03.07 (version=SSLv3 cipher=OTHER); Wed, 08 Feb 2012 11:03:08 -0800 (PST) Sender: Jim Gettys Message-ID: <4F32C6EB.5030404@freedesktop.org> Date: Wed, 08 Feb 2012 14:03:07 -0500 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Joe Touch References: <920E9EEF-0BD8-4CB4-B385-149FCBC799E1@swissms.ch> <4F32B4C7.6070102@isi.edu> <4F32C573.6090606@isi.edu> In-Reply-To: <4F32C573.6090606@isi.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "'tcpm@ietf.org'" Subject: Re: [tcpm] Aid passive estimate of tcp performance X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 19:03:13 -0000 On 02/08/2012 01:56 PM, Joe Touch wrote: > > > On 2/8/2012 10:05 AM, Smith, Donald wrote: >> Just agreeing with Joe, Many applications uses resets instead of a >> FIN handshake to terminate connections to speed things up especially >> browsers. >> >> >> http://pages.cpsc.ucalgary.ca/~carey/papers/2005/TCP-Resets.pdf > > It doesn't just "speed" things; it's reckless and dangerous, esp. > since the parties tossing around these RSTs typically don't maintain > TIME-WAIT before reusing those connection IDs. Joe, browsers have done this forever. If you don't like it, then it's (long past time) to make the case that they should change their behaviour. - Jim > > Joe > >>> -----Original Message----- >>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >>> Joe Touch >>> Sent: Wednesday, February 08, 2012 10:46 AM >>> To: Ángel Bartomeu Bonillo >>> Cc: tcpm@ietf.org >>> Subject: Re: [tcpm] Aid passive estimate of tcp performance >>> >>> >>> >>> On 2/8/2012 4:15 AM, Ángel Bartomeu Bonillo wrote: >>>> Hello, >>>> >>>> I recently faced the problem of passively estimating the packet loss >>>> of TCP connection. After a bit of investigating the literature I >>> found >>>> that there are tens of papers addressing this issue but I couldn't >>>> find any perfect solution. Since this is an important issue for >>>> network operators I have been thinking that there would be a very >>> easy >>>> solution by just making the two TCP connection end points to account >>>> for its sent segments and report it to the other end point in the FIN >>>> segment. This approach could be used as well for other measurable >>>> parameters along the TCP session without the need for any other >>>> offline method and It would be very helpful for detecting failures >>>> along networks. >>>> >>>> Any comments? >>> >>> Regardless of when you do this - either at the end of a connection, or >>> during a connection - the ONLY information you can provide is "here is >>> a list of segments I have not yet received". >>> >>> However, that list is irrelevant. Those segments might be in the >>> network and may still arrive - after you report, after the connection >>> is over, etc. >>> >>> There is no way to KNOW that a segment is lost vs. late. >>> >>> Even when you retransmit a segment (e.g., because it is basically >>> overdue, either because your side's timer expired or the other side >>> sent either a SACK or ACK indicating a gap), you don't know that the >>> first segment was lost - it could arrive after the timer expires. >>> >>> Even though segments have TTLs, and TTLs are *supposed* to be >>> decremented once every second or once every hop (whichever is greater), >>> there are devices that queue packets for long periods (e.g., when a >>> link is interrupted) and send them on later (even though they should >>> have been dropped). >>> >>> So there is no such information as "lost segments"; the best you know >>> is retransmissions. >>> >>> However, keep in mind that there are lots of TCP connections that are >>> terminated without a FIN (e.g., using a RST - I don't think it's >>> appropriate in many cases, but the method is in widespread use). >>> >>> Joe >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >> >> This communication is the property of CenturyLink and may contain >> confidential or privileged information. Unauthorized use of this >> communication is strictly >> prohibited and may be unlawful. If you have received this communication >> in error, please immediately notify the sender by reply e-mail and >> destroy >> all copies of the communication and any attachments. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Wed Feb 8 11:09:37 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6097311E8083 for ; Wed, 8 Feb 2012 11:09:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbVx0RwjIAkw for ; Wed, 8 Feb 2012 11:09:36 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 1E80821F84B6 for ; Wed, 8 Feb 2012 11:09:36 -0800 (PST) Received: from [207.151.141.96] ([207.151.141.96]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q18J8qCr023916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Feb 2012 11:09:20 -0800 (PST) Message-ID: <4F32C843.3010405@isi.edu> Date: Wed, 08 Feb 2012 11:08:51 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Jim Gettys References: <920E9EEF-0BD8-4CB4-B385-149FCBC799E1@swissms.ch> <4F32B4C7.6070102@isi.edu> <4F32C573.6090606@isi.edu> <4F32C6EB.5030404@freedesktop.org> In-Reply-To: <4F32C6EB.5030404@freedesktop.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "'tcpm@ietf.org'" Subject: Re: [tcpm] Aid passive estimate of tcp performance X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 19:09:37 -0000 Jim, Routers have been over-buffering forever too. Yet you continue to want to get them to change things and correctly implement the standards. That's what I want for endpoints with TCP too. Ignorance or deliberate defiance is not an excuse. These are errors that need to be corrected, since they have real implications throughout the network, both for users on those systems and those that share those addresses (e.g., behind shared NATs or proxies). Joe On 2/8/2012 11:03 AM, Jim Gettys wrote: > On 02/08/2012 01:56 PM, Joe Touch wrote: >> >> >> On 2/8/2012 10:05 AM, Smith, Donald wrote: >>> Just agreeing with Joe, Many applications uses resets instead of a >>> FIN handshake to terminate connections to speed things up especially >>> browsers. >>> >>> >>> http://pages.cpsc.ucalgary.ca/~carey/papers/2005/TCP-Resets.pdf >> >> It doesn't just "speed" things; it's reckless and dangerous, esp. >> since the parties tossing around these RSTs typically don't maintain >> TIME-WAIT before reusing those connection IDs. > > Joe, browsers have done this forever. > > If you don't like it, then it's (long past time) to make the case that > they should change their behaviour. > - Jim > >> >> Joe >> >>>> -----Original Message----- >>>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >>>> Joe Touch >>>> Sent: Wednesday, February 08, 2012 10:46 AM >>>> To: Ángel Bartomeu Bonillo >>>> Cc: tcpm@ietf.org >>>> Subject: Re: [tcpm] Aid passive estimate of tcp performance >>>> >>>> >>>> >>>> On 2/8/2012 4:15 AM, Ángel Bartomeu Bonillo wrote: >>>>> Hello, >>>>> >>>>> I recently faced the problem of passively estimating the packet loss >>>>> of TCP connection. After a bit of investigating the literature I >>>> found >>>>> that there are tens of papers addressing this issue but I couldn't >>>>> find any perfect solution. Since this is an important issue for >>>>> network operators I have been thinking that there would be a very >>>> easy >>>>> solution by just making the two TCP connection end points to account >>>>> for its sent segments and report it to the other end point in the FIN >>>>> segment. This approach could be used as well for other measurable >>>>> parameters along the TCP session without the need for any other >>>>> offline method and It would be very helpful for detecting failures >>>>> along networks. >>>>> >>>>> Any comments? >>>> >>>> Regardless of when you do this - either at the end of a connection, or >>>> during a connection - the ONLY information you can provide is "here is >>>> a list of segments I have not yet received". >>>> >>>> However, that list is irrelevant. Those segments might be in the >>>> network and may still arrive - after you report, after the connection >>>> is over, etc. >>>> >>>> There is no way to KNOW that a segment is lost vs. late. >>>> >>>> Even when you retransmit a segment (e.g., because it is basically >>>> overdue, either because your side's timer expired or the other side >>>> sent either a SACK or ACK indicating a gap), you don't know that the >>>> first segment was lost - it could arrive after the timer expires. >>>> >>>> Even though segments have TTLs, and TTLs are *supposed* to be >>>> decremented once every second or once every hop (whichever is greater), >>>> there are devices that queue packets for long periods (e.g., when a >>>> link is interrupted) and send them on later (even though they should >>>> have been dropped). >>>> >>>> So there is no such information as "lost segments"; the best you know >>>> is retransmissions. >>>> >>>> However, keep in mind that there are lots of TCP connections that are >>>> terminated without a FIN (e.g., using a RST - I don't think it's >>>> appropriate in many cases, but the method is in widespread use). >>>> >>>> Joe >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >>> >>> This communication is the property of CenturyLink and may contain >>> confidential or privileged information. Unauthorized use of this >>> communication is strictly >>> prohibited and may be unlawful. If you have received this communication >>> in error, please immediately notify the sender by reply e-mail and >>> destroy >>> all copies of the communication and any attachments. >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm From gettysjim@gmail.com Wed Feb 8 11:20:45 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F67A21F8542 for ; Wed, 8 Feb 2012 11:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjEffMPgOkxc for ; Wed, 8 Feb 2012 11:20:44 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id D97F821F8571 for ; Wed, 8 Feb 2012 11:20:43 -0800 (PST) Received: by qafi29 with SMTP id i29so3631752qaf.10 for ; Wed, 08 Feb 2012 11:20:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ztiP9c8QptJDuNGGXq6oePAQYz4Z7416vgLVX6bBWj0=; b=sQQSql9QyOAJPVZU2NtmsUIZZzkJlWfcEJnz2NRlyzvAlrp6BVJX3OJ7z79MP0g6OR e8bV7tulXhpzr6NOsdkE/fvF9R5CNeLFC3rNCaNYRmR809+EkGvRjrUrrU9QL346Z7Uf 7fAyMsnwymkmhAtjUZRlfItOO2mKGrP1J7Y7s= Received: by 10.224.183.5 with SMTP id ce5mr28754106qab.35.1328728843402; Wed, 08 Feb 2012 11:20:43 -0800 (PST) Received: from [192.168.1.27] (c-24-63-191-17.hsd1.ma.comcast.net. [24.63.191.17]) by mx.google.com with ESMTPS id fh6sm424952qab.22.2012.02.08.11.20.41 (version=SSLv3 cipher=OTHER); Wed, 08 Feb 2012 11:20:42 -0800 (PST) Sender: Jim Gettys Message-ID: <4F32CB07.9080601@freedesktop.org> Date: Wed, 08 Feb 2012 14:20:39 -0500 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Joe Touch References: <920E9EEF-0BD8-4CB4-B385-149FCBC799E1@swissms.ch> <4F32B4C7.6070102@isi.edu> <4F32C573.6090606@isi.edu> <4F32C6EB.5030404@freedesktop.org> <4F32C843.3010405@isi.edu> In-Reply-To: <4F32C843.3010405@isi.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "'tcpm@ietf.org'" Subject: Re: [tcpm] Aid passive estimate of tcp performance X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 19:20:45 -0000 On 02/08/2012 02:08 PM, Joe Touch wrote: > Jim, > > Routers have been over-buffering forever too. Yet you continue to want > to get them to change things and correctly implement the standards. > > That's what I want for endpoints with TCP too. > > Ignorance or deliberate defiance is not an excuse. These are errors > that need to be corrected, since they have real implications > throughout the network, both for users on those systems and those that > share those addresses (e.g., behind shared NATs or proxies). Over the years, I have noted a distinct lack of communications between those who understand how the bits flow, and how they are used.... For example, the transient bufferbloat phenomena is something that is pretty obvious to those who understand TCP, and completely unobvious to most who do web browsers... I believe both groups need to talk to each other, strangely. Sometimes you may find that the guys who do the applications actually have needs not being met by standards, that are well worth understanding; and conversely, the guys who do the apps may find that life is better for both them and others if they understand the standards. Just go in with an open mind and say: "We observe the browsers/servers doing the following thing that we believe is much less than optimal, why are you doing this?" rather than "You are disobeying the rules, fix it", and I think you'll get a warm welcome. - Jim > > Joe > > On 2/8/2012 11:03 AM, Jim Gettys wrote: >> On 02/08/2012 01:56 PM, Joe Touch wrote: >>> >>> >>> On 2/8/2012 10:05 AM, Smith, Donald wrote: >>>> Just agreeing with Joe, Many applications uses resets instead of a >>>> FIN handshake to terminate connections to speed things up especially >>>> browsers. >>>> >>>> >>>> http://pages.cpsc.ucalgary.ca/~carey/papers/2005/TCP-Resets.pdf >>> >>> It doesn't just "speed" things; it's reckless and dangerous, esp. >>> since the parties tossing around these RSTs typically don't maintain >>> TIME-WAIT before reusing those connection IDs. >> >> Joe, browsers have done this forever. >> >> If you don't like it, then it's (long past time) to make the case that >> they should change their behaviour. >> - Jim >> >>> >>> Joe >>> >>>>> -----Original Message----- >>>>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On >>>>> Behalf Of >>>>> Joe Touch >>>>> Sent: Wednesday, February 08, 2012 10:46 AM >>>>> To: Ángel Bartomeu Bonillo >>>>> Cc: tcpm@ietf.org >>>>> Subject: Re: [tcpm] Aid passive estimate of tcp performance >>>>> >>>>> >>>>> >>>>> On 2/8/2012 4:15 AM, Ángel Bartomeu Bonillo wrote: >>>>>> Hello, >>>>>> >>>>>> I recently faced the problem of passively estimating the packet loss >>>>>> of TCP connection. After a bit of investigating the literature I >>>>> found >>>>>> that there are tens of papers addressing this issue but I couldn't >>>>>> find any perfect solution. Since this is an important issue for >>>>>> network operators I have been thinking that there would be a very >>>>> easy >>>>>> solution by just making the two TCP connection end points to account >>>>>> for its sent segments and report it to the other end point in the >>>>>> FIN >>>>>> segment. This approach could be used as well for other measurable >>>>>> parameters along the TCP session without the need for any other >>>>>> offline method and It would be very helpful for detecting failures >>>>>> along networks. >>>>>> >>>>>> Any comments? >>>>> >>>>> Regardless of when you do this - either at the end of a >>>>> connection, or >>>>> during a connection - the ONLY information you can provide is >>>>> "here is >>>>> a list of segments I have not yet received". >>>>> >>>>> However, that list is irrelevant. Those segments might be in the >>>>> network and may still arrive - after you report, after the connection >>>>> is over, etc. >>>>> >>>>> There is no way to KNOW that a segment is lost vs. late. >>>>> >>>>> Even when you retransmit a segment (e.g., because it is basically >>>>> overdue, either because your side's timer expired or the other side >>>>> sent either a SACK or ACK indicating a gap), you don't know that the >>>>> first segment was lost - it could arrive after the timer expires. >>>>> >>>>> Even though segments have TTLs, and TTLs are *supposed* to be >>>>> decremented once every second or once every hop (whichever is >>>>> greater), >>>>> there are devices that queue packets for long periods (e.g., when a >>>>> link is interrupted) and send them on later (even though they should >>>>> have been dropped). >>>>> >>>>> So there is no such information as "lost segments"; the best you know >>>>> is retransmissions. >>>>> >>>>> However, keep in mind that there are lots of TCP connections that are >>>>> terminated without a FIN (e.g., using a RST - I don't think it's >>>>> appropriate in many cases, but the method is in widespread use). >>>>> >>>>> Joe >>>>> _______________________________________________ >>>>> tcpm mailing list >>>>> tcpm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tcpm >>>> >>>> This communication is the property of CenturyLink and may contain >>>> confidential or privileged information. Unauthorized use of this >>>> communication is strictly >>>> prohibited and may be unlawful. If you have received this >>>> communication >>>> in error, please immediately notify the sender by reply e-mail and >>>> destroy >>>> all copies of the communication and any attachments. >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm From ananth@cisco.com Wed Feb 8 11:39:18 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B37A11E8083 for ; Wed, 8 Feb 2012 11:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBpMiVfqHQcF for ; Wed, 8 Feb 2012 11:39:17 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 5356211E808A for ; Wed, 8 Feb 2012 11:39:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=6114; q=dns/txt; s=iport; t=1328729957; x=1329939557; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=DgK01yR/8oguKMVzS/cinzCpv10W99blLTo/hMZP820=; b=IrjfZA270RELSq314Pa3Lt1UjLy/a90v88sxjsokwxVXdElq2/1wKzpz AWMemE/pqNbs3gFZDsI8RU/2KPcP9slibi9VXfV2X73CVasusfwKQnxIz ENVDj9kdAmnZH5CfD6bwa9e7WbfNpNZd29/AZwqV81D+SdadaFn0vsF2L Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAFbOMk+rRDoH/2dsb2JhbABDDgiuc4EHgXIBAQECAgEBAQ8BHT4LDAQCAQgRBAEBAQoGBRIBBgEmHwkIAQEEARIIEweHY5phAZ5Wi0orMwEBBAIFA4MfBQMSeQ0CCgIVgkZjBIgTM58NWA X-IronPort-AV: E=Sophos;i="4.73,385,1325462400"; d="scan'208";a="29223227" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 08 Feb 2012 19:39:17 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q18JdG4v031192; Wed, 8 Feb 2012 19:39:17 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 11:39:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Feb 2012 11:39:15 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580E75F838@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <4F32C843.3010405@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Aid passive estimate of tcp performance Thread-Index: AczmlTk4mMGoMh/ISwmaa8fJ41hAkwAAH7tw References: <920E9EEF-0BD8-4CB4-B385-149FCBC799E1@swissms.ch><4F32B4C7.6070102@isi.edu><4F32C573.6090606@isi.edu> <4F32C6EB.5030404@freedesktop.org> <4F32C843.3010405@isi.edu> From: "Anantha Ramaiah (ananth)" To: "Joe Touch" , "Jim Gettys" X-OriginalArrivalTime: 08 Feb 2012 19:39:16.0722 (UTC) FILETIME=[57F8F520:01CCE699] Cc: tcpm@ietf.org Subject: Re: [tcpm] Aid passive estimate of tcp performance X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 19:39:18 -0000 Well, Some assumptions that existed long ago, are no longer serious or may = be not hold good for the modern internet. Lets take the example of = TIMEWAIT state which you mention below. RFC recommends 2*MSL which = translates to 4 mins. Many OS'es (Windows, Linux ) and Cisco IOS etc., = have configurable knobs to tune this value to anywhere between 30 secs = to 240 secs. Lets take up the initial window case, it was 1 segment 30 years ago, = got increased to 3 segments and now it's on it way to hit the 10 = segments mark. So things keep changing and the "degree of conservatism" = changes to adopt to the current internet. So, you just can't say these are erroneous or mis-interpretations, it = is just the way things have moved on (IMO for good in most cases) -Anantha=20 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf = Of > Joe Touch > Sent: Wednesday, February 08, 2012 11:09 AM > To: Jim Gettys > Cc: 'tcpm@ietf.org' > Subject: Re: [tcpm] Aid passive estimate of tcp performance >=20 > Jim, >=20 > Routers have been over-buffering forever too. Yet you continue to want > to get them to change things and correctly implement the standards. >=20 > That's what I want for endpoints with TCP too. >=20 > Ignorance or deliberate defiance is not an excuse. These are errors > that > need to be corrected, since they have real implications throughout the > network, both for users on those systems and those that share those > addresses (e.g., behind shared NATs or proxies). >=20 > Joe >=20 > On 2/8/2012 11:03 AM, Jim Gettys wrote: > > On 02/08/2012 01:56 PM, Joe Touch wrote: > >> > >> > >> On 2/8/2012 10:05 AM, Smith, Donald wrote: > >>> Just agreeing with Joe, Many applications uses resets instead of a > >>> FIN handshake to terminate connections to speed things up > especially > >>> browsers. > >>> > >>> > >>> http://pages.cpsc.ucalgary.ca/~carey/papers/2005/TCP-Resets.pdf > >> > >> It doesn't just "speed" things; it's reckless and dangerous, esp. > >> since the parties tossing around these RSTs typically don't = maintain > >> TIME-WAIT before reusing those connection IDs. > > > > Joe, browsers have done this forever. > > > > If you don't like it, then it's (long past time) to make the case > that > > they should change their behaviour. > > - Jim > > > >> > >> Joe > >> > >>>> -----Original Message----- > >>>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > Behalf Of > >>>> Joe Touch > >>>> Sent: Wednesday, February 08, 2012 10:46 AM > >>>> To: =C1ngel Bartomeu Bonillo > >>>> Cc: tcpm@ietf.org > >>>> Subject: Re: [tcpm] Aid passive estimate of tcp performance > >>>> > >>>> > >>>> > >>>> On 2/8/2012 4:15 AM, =C1ngel Bartomeu Bonillo wrote: > >>>>> Hello, > >>>>> > >>>>> I recently faced the problem of passively estimating the packet > loss > >>>>> of TCP connection. After a bit of investigating the literature I > >>>> found > >>>>> that there are tens of papers addressing this issue but I > couldn't > >>>>> find any perfect solution. Since this is an important issue for > >>>>> network operators I have been thinking that there would be a = very > >>>> easy > >>>>> solution by just making the two TCP connection end points to > account > >>>>> for its sent segments and report it to the other end point in = the > FIN > >>>>> segment. This approach could be used as well for other = measurable > >>>>> parameters along the TCP session without the need for any other > >>>>> offline method and It would be very helpful for detecting > failures > >>>>> along networks. > >>>>> > >>>>> Any comments? > >>>> > >>>> Regardless of when you do this - either at the end of a > connection, or > >>>> during a connection - the ONLY information you can provide is > "here is > >>>> a list of segments I have not yet received". > >>>> > >>>> However, that list is irrelevant. Those segments might be in the > >>>> network and may still arrive - after you report, after the > connection > >>>> is over, etc. > >>>> > >>>> There is no way to KNOW that a segment is lost vs. late. > >>>> > >>>> Even when you retransmit a segment (e.g., because it is basically > >>>> overdue, either because your side's timer expired or the other > side > >>>> sent either a SACK or ACK indicating a gap), you don't know that > the > >>>> first segment was lost - it could arrive after the timer expires. > >>>> > >>>> Even though segments have TTLs, and TTLs are *supposed* to be > >>>> decremented once every second or once every hop (whichever is > greater), > >>>> there are devices that queue packets for long periods (e.g., when > a > >>>> link is interrupted) and send them on later (even though they > should > >>>> have been dropped). > >>>> > >>>> So there is no such information as "lost segments"; the best you > know > >>>> is retransmissions. > >>>> > >>>> However, keep in mind that there are lots of TCP connections that > are > >>>> terminated without a FIN (e.g., using a RST - I don't think it's > >>>> appropriate in many cases, but the method is in widespread use). > >>>> > >>>> Joe > >>>> _______________________________________________ > >>>> tcpm mailing list > >>>> tcpm@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/tcpm > >>> > >>> This communication is the property of CenturyLink and may contain > >>> confidential or privileged information. Unauthorized use of this > >>> communication is strictly > >>> prohibited and may be unlawful. If you have received this > communication > >>> in error, please immediately notify the sender by reply e-mail and > >>> destroy > >>> all copies of the communication and any attachments. > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From ananth@cisco.com Wed Feb 8 12:01:22 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B9511E80A4 for ; Wed, 8 Feb 2012 12:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Xyxo64-IK8O for ; Wed, 8 Feb 2012 12:01:22 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 60BC211E809A for ; Wed, 8 Feb 2012 12:01:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=901; q=dns/txt; s=iport; t=1328731281; x=1329940881; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=TCF2CHmnZi7jqfqPGqjl6urDuI4ZuFOn5AFx850Y9PU=; b=fD3JKqSMnWq3eIkKaalfY1ApA1N68DnRoGzzWK7OtUcWk1fXX7M/GWms pOjrcUCrF9TZQYacx/0MJ3z1AB2oelSZuTbYXprqZh1mCg680Uz4zPqVt 6VJgBnCJmOYd2UkfoRgqt7DEF0z9FW6T5PeLOhVn/gbNzaU9SbZyHHIbQ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABnUMk+rRDoH/2dsb2JhbABDDq58gQeBcgEBAQMBEgEdCj8FCwIBCA4UBhgGAVYBAQQBGhqHWppsAZ5Ri0orMwEBBAIFAwkDgxMFAxJ5DQIKAoJbYwSIRp8NWA X-IronPort-AV: E=Sophos;i="4.73,385,1325462400"; d="scan'208";a="29436155" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 08 Feb 2012 20:01:21 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q18K1Lmw010580; Wed, 8 Feb 2012 20:01:21 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 12:01:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Feb 2012 12:01:20 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580E75F85E@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <4F32CB07.9080601@freedesktop.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Aid passive estimate of tcp performance Thread-Index: Aczmlsg6GsBDpVEiSwaC/Jj+6LbUFAAAq/Pg References: <920E9EEF-0BD8-4CB4-B385-149FCBC799E1@swissms.ch><4F32B4C7.6070102@isi.edu><4F32C573.6090606@isi.edu> <4F32C6EB.5030404@freedesktop.org><4F32C843.3010405@isi.edu> <4F32CB07.9080601@freedesktop.org> From: "Anantha Ramaiah (ananth)" To: "Jim Gettys" , "Joe Touch" X-OriginalArrivalTime: 08 Feb 2012 20:01:21.0090 (UTC) FILETIME=[6D5B7A20:01CCE69C] Cc: tcpm@ietf.org Subject: Re: [tcpm] Aid passive estimate of tcp performance X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 20:01:22 -0000 + 1 > Just go in with an open mind and say: "We observe the browsers/servers > doing the following thing that we believe is much less than optimal, > why > are you doing this?" rather than "You are disobeying the rules, fix > it", > and I think you'll get a warm welcome. > - Jim We have been through this before it is sad that some folks use the argument of "there is a high bar for changing TCP" and try to bury ideas which have not been standaridized and have not given a chance to get standardized. Linux TCP has many things (good) which are not IETF standards. Of course other OS'es as well. I am afraid all these are a result of the latter attitude. I thought a few times before writing this email, but alas I have a better feeling now even though in some sense it is a repeat and a viewpoint which is shared by a considerable number of folks. -Anantha From touch@isi.edu Wed Feb 8 12:55:09 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D3C11E8097 for ; Wed, 8 Feb 2012 12:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.699 X-Spam-Level: X-Spam-Status: No, score=-104.699 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLqC-lXqrKVW for ; Wed, 8 Feb 2012 12:55:04 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id B4FBD21F855E for ; Wed, 8 Feb 2012 12:54:45 -0800 (PST) Received: from [207.151.141.184] ([207.151.141.184]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q18Ks8gf009864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Feb 2012 12:54:17 -0800 (PST) Message-ID: <4F32E0EF.1090407@isi.edu> Date: Wed, 08 Feb 2012 12:54:07 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <920E9EEF-0BD8-4CB4-B385-149FCBC799E1@swissms.ch><4F32B4C7.6070102@isi.edu><4F32C573.6090606@isi.edu> <4F32C6EB.5030404@freedesktop.org> <4F32C843.3010405@isi.edu> <0C53DCFB700D144284A584F54711EC580E75F838@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580E75F838@xmb-sjc-21c.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Aid passive estimate of tcp performance X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 20:55:09 -0000 On 2/8/2012 11:39 AM, Anantha Ramaiah (ananth) wrote: > Well, > Some assumptions that existed long ago, are no longer serious or may > be not hold good for the modern internet. Where that's true, it's worth re-examining. > Lets take the example of > TIMEWAIT state which you mention below. RFC recommends 2*MSL which > translates to 4 mins. Many OS'es (Windows, Linux ) and Cisco IOS etc., > have configurable knobs to tune this value to anywhere between 30 secs > to 240 secs. It's worth understanding why. It's not with a sense that this was safe per-se; it was a sense of improving performance. That's a bad reason to make a change, especially when it's ignorant of the rationale for the safety mechanism being avoided. > Lets take up the initial window case, it was 1 segment 30 years ago, > got increased to 3 segments and now it's on it way to hit the 10 > segments mark. So things keep changing and the "degree of conservatism" > changes to adopt to the current internet. Yes, and that was done by changing the specs. > So, you just can't say these are erroneous or mis-interpretations, > it is just the way things have moved on (IMO for good in most cases) My specific experience is with the interaction between TCP and HTTP. HTTP was designed because of the ignorance of the rationale of the design of FTP - notably that it wasn't useful to open two connections to get a file when only one file per location would be useful (this is paraphrased from Berners-Lee's original papers). HTTP incurred long (200ms) delays when first deployed because of a similar ignorance about how application protocols interact with TCP - that interactive protocols with multi-byte exchanges must have Nagle off. There is a similar issue with RSTs. They're useful to terminate connections when that is the desired intent - an abort. However, they're overused by browsers for other reasons - e.g., when switching pages. There are reasons to change TCP, and to have it evolve; there are also reasons to find and declare variations "non-compliant" bugs and fix them. The distinction should be made with a full understanding of what TCP is *already* capable of, and the implications of these changes. Joe >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >> Joe Touch >> Sent: Wednesday, February 08, 2012 11:09 AM >> To: Jim Gettys >> Cc: 'tcpm@ietf.org' >> Subject: Re: [tcpm] Aid passive estimate of tcp performance >> >> Jim, >> >> Routers have been over-buffering forever too. Yet you continue to want >> to get them to change things and correctly implement the standards. >> >> That's what I want for endpoints with TCP too. >> >> Ignorance or deliberate defiance is not an excuse. These are errors >> that >> need to be corrected, since they have real implications throughout the >> network, both for users on those systems and those that share those >> addresses (e.g., behind shared NATs or proxies). >> >> Joe >> >> On 2/8/2012 11:03 AM, Jim Gettys wrote: >>> On 02/08/2012 01:56 PM, Joe Touch wrote: >>>> >>>> >>>> On 2/8/2012 10:05 AM, Smith, Donald wrote: >>>>> Just agreeing with Joe, Many applications uses resets instead of a >>>>> FIN handshake to terminate connections to speed things up >> especially >>>>> browsers. >>>>> >>>>> >>>>> http://pages.cpsc.ucalgary.ca/~carey/papers/2005/TCP-Resets.pdf >>>> >>>> It doesn't just "speed" things; it's reckless and dangerous, esp. >>>> since the parties tossing around these RSTs typically don't maintain >>>> TIME-WAIT before reusing those connection IDs. >>> >>> Joe, browsers have done this forever. >>> >>> If you don't like it, then it's (long past time) to make the case >> that >>> they should change their behaviour. >>> - Jim >>> >>>> >>>> Joe >>>> >>>>>> -----Original Message----- >>>>>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On >> Behalf Of >>>>>> Joe Touch >>>>>> Sent: Wednesday, February 08, 2012 10:46 AM >>>>>> To: Ángel Bartomeu Bonillo >>>>>> Cc: tcpm@ietf.org >>>>>> Subject: Re: [tcpm] Aid passive estimate of tcp performance >>>>>> >>>>>> >>>>>> >>>>>> On 2/8/2012 4:15 AM, Ángel Bartomeu Bonillo wrote: >>>>>>> Hello, >>>>>>> >>>>>>> I recently faced the problem of passively estimating the packet >> loss >>>>>>> of TCP connection. After a bit of investigating the literature I >>>>>> found >>>>>>> that there are tens of papers addressing this issue but I >> couldn't >>>>>>> find any perfect solution. Since this is an important issue for >>>>>>> network operators I have been thinking that there would be a very >>>>>> easy >>>>>>> solution by just making the two TCP connection end points to >> account >>>>>>> for its sent segments and report it to the other end point in the >> FIN >>>>>>> segment. This approach could be used as well for other measurable >>>>>>> parameters along the TCP session without the need for any other >>>>>>> offline method and It would be very helpful for detecting >> failures >>>>>>> along networks. >>>>>>> >>>>>>> Any comments? >>>>>> >>>>>> Regardless of when you do this - either at the end of a >> connection, or >>>>>> during a connection - the ONLY information you can provide is >> "here is >>>>>> a list of segments I have not yet received". >>>>>> >>>>>> However, that list is irrelevant. Those segments might be in the >>>>>> network and may still arrive - after you report, after the >> connection >>>>>> is over, etc. >>>>>> >>>>>> There is no way to KNOW that a segment is lost vs. late. >>>>>> >>>>>> Even when you retransmit a segment (e.g., because it is basically >>>>>> overdue, either because your side's timer expired or the other >> side >>>>>> sent either a SACK or ACK indicating a gap), you don't know that >> the >>>>>> first segment was lost - it could arrive after the timer expires. >>>>>> >>>>>> Even though segments have TTLs, and TTLs are *supposed* to be >>>>>> decremented once every second or once every hop (whichever is >> greater), >>>>>> there are devices that queue packets for long periods (e.g., when >> a >>>>>> link is interrupted) and send them on later (even though they >> should >>>>>> have been dropped). >>>>>> >>>>>> So there is no such information as "lost segments"; the best you >> know >>>>>> is retransmissions. >>>>>> >>>>>> However, keep in mind that there are lots of TCP connections that >> are >>>>>> terminated without a FIN (e.g., using a RST - I don't think it's >>>>>> appropriate in many cases, but the method is in widespread use). >>>>>> >>>>>> Joe >>>>>> _______________________________________________ >>>>>> tcpm mailing list >>>>>> tcpm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/tcpm >>>>> >>>>> This communication is the property of CenturyLink and may contain >>>>> confidential or privileged information. Unauthorized use of this >>>>> communication is strictly >>>>> prohibited and may be unlawful. If you have received this >> communication >>>>> in error, please immediately notify the sender by reply e-mail and >>>>> destroy >>>>> all copies of the communication and any attachments. >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm From Donald.Smith@CenturyLink.com Wed Feb 8 13:50:43 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD8421F85B1 for ; Wed, 8 Feb 2012 13:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r006EEULBxVL for ; Wed, 8 Feb 2012 13:50:42 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id C863721F8581 for ; Wed, 8 Feb 2012 13:50:41 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id q18LodHI006681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Feb 2012 15:50:39 -0600 (CST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 392D21E0059; Wed, 8 Feb 2012 15:50:34 -0600 (CST) Received: from suomp60i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 1C23D1E004D; Wed, 8 Feb 2012 15:50:34 -0600 (CST) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id q18LoXOt011059; Wed, 8 Feb 2012 15:50:33 -0600 (CST) Received: from qtdenexhtm20.AD.QINTRA.COM (qtdenexhtm20.ad.qintra.com [151.119.91.229]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id q18LoWwY010988 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Wed, 8 Feb 2012 15:50:33 -0600 (CST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm20.AD.QINTRA.COM ([151.119.91.229]) with mapi; Wed, 8 Feb 2012 14:50:32 -0700 From: "Smith, Donald" To: "'Joe Touch'" , "'Anantha Ramaiah (ananth)'" Date: Wed, 8 Feb 2012 14:50:31 -0700 Thread-Topic: [tcpm] Aid passive estimate of tcp performance Thread-Index: Aczmo/um4Ml+0IxeTLaMxd7KefmY/wABV94w Message-ID: References: <920E9EEF-0BD8-4CB4-B385-149FCBC799E1@swissms.ch><4F32B4C7.6070102@isi.edu><4F32C573.6090606@isi.edu> <4F32C6EB.5030404@freedesktop.org> <4F32C843.3010405@isi.edu> <0C53DCFB700D144284A584F54711EC580E75F838@xmb-sjc-21c.amer.cisco.com> <4F32E0EF.1090407@isi.edu> In-Reply-To: <4F32E0EF.1090407@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "'tcpm@ietf.org'" Subject: Re: [tcpm] Aid passive estimate of tcp performance X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 21:50:43 -0000 When packets collide the controllers cease transmission AND wait a random t= ime before retransmission (mostly)! Donald.Smith@CenturyLink.com > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Joe Touch > Sent: Wednesday, February 08, 2012 1:54 PM > To: Anantha Ramaiah (ananth) > Cc: tcpm@ietf.org > Subject: Re: [tcpm] Aid passive estimate of tcp performance > > > > On 2/8/2012 11:39 AM, Anantha Ramaiah (ananth) wrote: > > Well, > > Some assumptions that existed long ago, are no longer serious or may > > be not hold good for the modern internet. > > Where that's true, it's worth re-examining. > > > Lets take the example of > > TIMEWAIT state which you mention below. RFC recommends 2*MSL which > > translates to 4 mins. Many OS'es (Windows, Linux ) and Cisco IOS > etc., > > have configurable knobs to tune this value to anywhere between 30 > secs > > to 240 secs. > > It's worth understanding why. It's not with a sense that this was safe > per-se; it was a sense of improving performance. That's a bad reason to > make a change, especially when it's ignorant of the rationale for the > safety mechanism being avoided. It depends on what you mean by safe. If your trying to survive a ddos attac= k making those timers very low helps quite a bit and doesn't seem to affect= the clients. In what transport today does a open take more than a second or two? Same for a close with FIN those normally complete in a second or two. I realize some of these recommendations were written when a 4800baud was a = high speed link. I can see where a satalite bounce might take a few seconds but even that is= n't measured in minutes. If we made new recommendations (not changing ratios just changing the value= s by a factor of 10 or so) maybe we could convince the browser vendors and = web server vendors to not use RESETS the way so many of them do today. > > > Lets take up the initial window case, it was 1 segment 30 years ago, > > got increased to 3 segments and now it's on it way to hit the 10 > > segments mark. So things keep changing and the "degree of > conservatism" > > changes to adopt to the current internet. > > Yes, and that was done by changing the specs. > > > So, you just can't say these are erroneous or mis-interpretations, it > > is just the way things have moved on (IMO for good in most cases) > > My specific experience is with the interaction between TCP and HTTP. > HTTP was designed because of the ignorance of the rationale of the > design of FTP - notably that it wasn't useful to open two connections > to get a file when only one file per location would be useful (this is > paraphrased from Berners-Lee's original papers). HTTP incurred long > (200ms) delays when first deployed because of a similar ignorance about > how application protocols interact with TCP - that interactive > protocols with multi-byte exchanges must have Nagle off. > > There is a similar issue with RSTs. They're useful to terminate > connections when that is the desired intent - an abort. However, > they're overused by browsers for other reasons - e.g., when switching > pages. > > There are reasons to change TCP, and to have it evolve; there are also > reasons to find and declare variations "non-compliant" bugs and fix > them. The distinction should be made with a full understanding of what > TCP is *already* capable of, and the implications of these changes. > > Joe > > >> -----Original Message----- > >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf > >> Of Joe Touch > >> Sent: Wednesday, February 08, 2012 11:09 AM > >> To: Jim Gettys > >> Cc: 'tcpm@ietf.org' > >> Subject: Re: [tcpm] Aid passive estimate of tcp performance > >> > >> Jim, > >> > >> Routers have been over-buffering forever too. Yet you continue to > >> want to get them to change things and correctly implement the > standards. > >> > >> That's what I want for endpoints with TCP too. > >> > >> Ignorance or deliberate defiance is not an excuse. These are errors > >> that need to be corrected, since they have real implications > >> throughout the network, both for users on those systems and those > >> that share those addresses (e.g., behind shared NATs or proxies). > >> > >> Joe > >> > >> On 2/8/2012 11:03 AM, Jim Gettys wrote: > >>> On 02/08/2012 01:56 PM, Joe Touch wrote: > >>>> > >>>> > >>>> On 2/8/2012 10:05 AM, Smith, Donald wrote: > >>>>> Just agreeing with Joe, Many applications uses resets instead of > a > >>>>> FIN handshake to terminate connections to speed things up > >> especially > >>>>> browsers. > >>>>> > >>>>> > >>>>> http://pages.cpsc.ucalgary.ca/~carey/papers/2005/TCP-Resets.pdf > >>>> > >>>> It doesn't just "speed" things; it's reckless and dangerous, esp. > >>>> since the parties tossing around these RSTs typically don't > >>>> maintain TIME-WAIT before reusing those connection IDs. > >>> > >>> Joe, browsers have done this forever. > >>> > >>> If you don't like it, then it's (long past time) to make the case > >> that > >>> they should change their behaviour. > >>> - Jim > >>> > >>>> > >>>> Joe > >>>> > >>>>>> -----Original Message----- > >>>>>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > >> Behalf Of > >>>>>> Joe Touch > >>>>>> Sent: Wednesday, February 08, 2012 10:46 AM > >>>>>> To: =C1ngel Bartomeu Bonillo > >>>>>> Cc: tcpm@ietf.org > >>>>>> Subject: Re: [tcpm] Aid passive estimate of tcp performance > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 2/8/2012 4:15 AM, =C1ngel Bartomeu Bonillo wrote: > >>>>>>> Hello, > >>>>>>> > >>>>>>> I recently faced the problem of passively estimating the packet > >> loss > >>>>>>> of TCP connection. After a bit of investigating the literature > I > >>>>>> found > >>>>>>> that there are tens of papers addressing this issue but I > >> couldn't > >>>>>>> find any perfect solution. Since this is an important issue for > >>>>>>> network operators I have been thinking that there would be a > >>>>>>> very > >>>>>> easy > >>>>>>> solution by just making the two TCP connection end points to > >> account > >>>>>>> for its sent segments and report it to the other end point in > >>>>>>> the > >> FIN > >>>>>>> segment. This approach could be used as well for other > >>>>>>> measurable parameters along the TCP session without the need > for > >>>>>>> any other offline method and It would be very helpful for > >>>>>>> detecting > >> failures > >>>>>>> along networks. > >>>>>>> > >>>>>>> Any comments? > >>>>>> > >>>>>> Regardless of when you do this - either at the end of a > >> connection, or > >>>>>> during a connection - the ONLY information you can provide is > >> "here is > >>>>>> a list of segments I have not yet received". > >>>>>> > >>>>>> However, that list is irrelevant. Those segments might be in the > >>>>>> network and may still arrive - after you report, after the > >> connection > >>>>>> is over, etc. > >>>>>> > >>>>>> There is no way to KNOW that a segment is lost vs. late. > >>>>>> > >>>>>> Even when you retransmit a segment (e.g., because it is > basically > >>>>>> overdue, either because your side's timer expired or the other > >> side > >>>>>> sent either a SACK or ACK indicating a gap), you don't know that > >> the > >>>>>> first segment was lost - it could arrive after the timer > expires. > >>>>>> > >>>>>> Even though segments have TTLs, and TTLs are *supposed* to be > >>>>>> decremented once every second or once every hop (whichever is > >> greater), > >>>>>> there are devices that queue packets for long periods (e.g., > when > >> a > >>>>>> link is interrupted) and send them on later (even though they > >> should > >>>>>> have been dropped). > >>>>>> > >>>>>> So there is no such information as "lost segments"; the best you > >> know > >>>>>> is retransmissions. > >>>>>> > >>>>>> However, keep in mind that there are lots of TCP connections > that > >> are > >>>>>> terminated without a FIN (e.g., using a RST - I don't think it's > >>>>>> appropriate in many cases, but the method is in widespread use). > >>>>>> > >>>>>> Joe > >>>>>> _______________________________________________ > >>>>>> tcpm mailing list > >>>>>> tcpm@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/tcpm > >>>>> > >>>>> This communication is the property of CenturyLink and may contain > >>>>> confidential or privileged information. Unauthorized use of this > >>>>> communication is strictly prohibited and may be unlawful. If you > >>>>> have received this > >> communication > >>>>> in error, please immediately notify the sender by reply e-mail > and > >>>>> destroy all copies of the communication and any attachments. > >>>> _______________________________________________ > >>>> tcpm mailing list > >>>> tcpm@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/tcpm > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From ananth@cisco.com Wed Feb 8 13:57:01 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E68FD21F8594 for ; Wed, 8 Feb 2012 13:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.179 X-Spam-Level: X-Spam-Status: No, score=-6.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djQ9EoEZNAgc for ; Wed, 8 Feb 2012 13:57:01 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 579C521F8591 for ; Wed, 8 Feb 2012 13:57:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=2846; q=dns/txt; s=iport; t=1328738221; x=1329947821; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=i2DtdTJwe7vVLyXUu0+l62a4eKMKM5NAx/MmRkKTUTg=; b=FT5p3sntDJxIvePSPeG12nqfytLbOdIGE5AXUBwIDU96pE+J1rxVnz3v nOlMRB3gcn4dN8rB0OKn3Yg1bM9pk8DV+NJg2cIKyjZ0uE/gi3TL2ivXW DuPvud4yGlK9GQhzeH7jBjfZccu9M3hSMmLd8yBdeGcgGKBueE5nbjgqz 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAADvMk+rRDoI/2dsb2JhbABDDq58gQeBcgEBAQMBEgEdCj8MBAIBCBEEAQEBCgYXAQYBRQkIAQEEEwgah1qaVgGeTYtKKzMBAQQCBQODHwUDEnkNAgoCgltjBIhGnw1Y X-IronPort-AV: E=Sophos;i="4.73,386,1325462400"; d="scan'208";a="27733394" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 08 Feb 2012 21:57:01 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q18Lv1uT005244; Wed, 8 Feb 2012 21:57:01 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 13:57:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Feb 2012 13:54:22 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580E75F90F@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <4F32E0EF.1090407@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Aid passive estimate of tcp performance Thread-Index: Aczmo++vXyvAUls5TvSwWLLhvWHEGwAAKMjw References: <920E9EEF-0BD8-4CB4-B385-149FCBC799E1@swissms.ch><4F32B4C7.6070102@isi.edu><4F32C573.6090606@isi.edu> <4F32C6EB.5030404@freedesktop.org> <4F32C843.3010405@isi.edu> <0C53DCFB700D144284A584F54711EC580E75F838@xmb-sjc-21c.amer.cisco.com> <4F32E0EF.1090407@isi.edu> From: "Anantha Ramaiah (ananth)" To: "Joe Touch" X-OriginalArrivalTime: 08 Feb 2012 21:57:01.0126 (UTC) FILETIME=[95F0EE60:01CCE6AC] Cc: tcpm@ietf.org Subject: Re: [tcpm] Aid passive estimate of tcp performance X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 21:57:02 -0000 > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Wednesday, February 08, 2012 12:54 PM > To: Anantha Ramaiah (ananth) > Cc: Jim Gettys; tcpm@ietf.org > Subject: Re: [tcpm] Aid passive estimate of tcp performance >=20 >=20 >=20 > On 2/8/2012 11:39 AM, Anantha Ramaiah (ananth) wrote: > > Well, > > Some assumptions that existed long ago, are no longer serious or may > > be not hold good for the modern internet. >=20 > Where that's true, it's worth re-examining. >=20 > > Lets take the example of > > TIMEWAIT state which you mention below. RFC recommends 2*MSL which > > translates to 4 mins. Many OS'es (Windows, Linux ) and Cisco IOS > etc., > > have configurable knobs to tune this value to anywhere between 30 > secs > > to 240 secs. >=20 > It's worth understanding why. It's not with a sense that this was safe > per-se; it was a sense of improving performance. That's a bad reason to > make a change, especially when it's ignorant of the rationale for the > safety mechanism being avoided. Many changes proposed to TCP are in the areas of improving TCP performance, this one is no different. The reason you want to change initial window to a larger value is to have a better throughput. The reason you want to decrease TIMEWAIT value is to have more connections per second without port contention issues. The rationale is similar in both cases. Regarding your safety argument: having a timewait value of X was considered safe ages ago, now having a lesser value is considered safe, it is parameter change and every parameter change that affects TCP and/or has other side effects needs to evaluated carefully. I don't see any difference. >=20 > There is a similar issue with RSTs. They're useful to terminate > connections when that is the desired intent - an abort. However, > they're > overused by browsers for other reasons - e.g., when switching pages. Well, I thought RST's original intent was to detect and recover from half open connections (crash etc.,). RFC 793 does list abort as the user interface to TCP, but it doesn't tell you when you should not use abort's. (I can see that that are supplement documents that discuss RST's like RFC 3360, which mainly talks about middleboxes inappropriate usage of RST's, but I don't remember anybody mandating its (abort API) use in one way or the other). Abort API evolved to be used in other scenarios. You can't blame the implementations for that. >=20 > There are reasons to change TCP, and to have it evolve; there are also > reasons to find and declare variations "non-compliant" bugs and fix > them. The distinction should be made with a full understanding of what > TCP is *already* capable of, and the implications of these changes. Agree. -Anantha >=20 > Joe >=20 From ycheng@google.com Wed Feb 8 14:59:50 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46FC811E8097 for ; Wed, 8 Feb 2012 14:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.902 X-Spam-Level: X-Spam-Status: No, score=-102.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOhB-DtneuPV for ; Wed, 8 Feb 2012 14:59:49 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8AC11E808C for ; Wed, 8 Feb 2012 14:59:49 -0800 (PST) Received: by obbwd15 with SMTP id wd15so1705542obb.31 for ; Wed, 08 Feb 2012 14:59:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:from:date:message-id:subject:to:cc:x-system-of-record :content-type:content-transfer-encoding; bh=MDGOL8Dn8338udARUL8DaR4gsm1M9QtEWm6jY795/4w=; b=nAbRQ0+2z+wutplUXzk1OuxLfOPkUxk0Q6kWnLdcBfSpQTdkr2ngpH2Fbwqm7vhXBy XKT41u1Mxy4W9drkStIbkdF7rjyZx+Qhhj7W/J47sv5CFJKZR7VBgVMiWQiCu3UoTn/o ZoXc4u2iBpHct2ytE7FKfut0CwVuP47W26vmg= Received: by 10.182.74.102 with SMTP id s6mr27862272obv.46.1328741988777; Wed, 08 Feb 2012 14:59:48 -0800 (PST) Received: by 10.182.74.102 with SMTP id s6mr27862212obv.46.1328741987278; Wed, 08 Feb 2012 14:59:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.212.37 with HTTP; Wed, 8 Feb 2012 14:59:27 -0800 (PST) From: Yuchung Cheng Date: Wed, 8 Feb 2012 14:59:27 -0800 Message-ID: To: Jim Gettys X-System-Of-Record: true Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "tcpm@ietf.org" , Joe Touch Subject: [tcpm] TCP and applications [was Re: Aid passive estimate of tcp performance] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 22:59:50 -0000 On Wed, Feb 8, 2012 at 11:20 AM, Jim Gettys wrote: > Over the years, I have noted a distinct lack of communications between > those who understand how the bits flow, and how they are used.... =A0For > example, the transient bufferbloat phenomena is something that is pretty > obvious to those who understand TCP, and completely unobvious to most > who do web browsers... > > I believe both groups need to talk to each other, strangely. =A0Sometimes > you may find that the guys who do the applications actually have needs > not being met by standards, that are well worth understanding; and > conversely, the guys who do the apps may find that life is better for > both them and others if they understand the standards. +1 Can't agree more. We need a venue for two-way communications. app dev: TCP sucks because blah blah blah TCP dudes: app sucks because blah blah blah [I am in a company where I have to hear both :( ] Nothing gets done until both parties try to help each other by listening to each other. > > Just go in with an open mind and say: "We observe the browsers/servers > doing the following thing that we believe is much less than optimal, why > are you doing this?" rather than "You are disobeying the rules, fix it", > and I think you'll get a warm welcome. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- Jim > > >> >> Joe >> >> On 2/8/2012 11:03 AM, Jim Gettys wrote: >>> On 02/08/2012 01:56 PM, Joe Touch wrote: >>>> >>>> >>>> On 2/8/2012 10:05 AM, Smith, Donald wrote: >>>>> Just agreeing with Joe, Many applications uses resets instead of a >>>>> FIN handshake to terminate connections to speed things up especially >>>>> browsers. >>>>> >>>>> >>>>> http://pages.cpsc.ucalgary.ca/~carey/papers/2005/TCP-Resets.pdf >>>> >>>> It doesn't just "speed" things; it's reckless and dangerous, esp. >>>> since the parties tossing around these RSTs typically don't maintain >>>> TIME-WAIT before reusing those connection IDs. >>> >>> Joe, browsers have done this forever. >>> >>> If you don't like it, then it's (long past time) to make the case that >>> they should change their behaviour. >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- Jim >>> >>>> >>>> Joe >>>> >>>>>> -----Original Message----- >>>>>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On >>>>>> Behalf Of >>>>>> Joe Touch >>>>>> Sent: Wednesday, February 08, 2012 10:46 AM >>>>>> To: =C1ngel Bartomeu Bonillo >>>>>> Cc: tcpm@ietf.org >>>>>> Subject: Re: [tcpm] Aid passive estimate of tcp performance >>>>>> >>>>>> >>>>>> >>>>>> On 2/8/2012 4:15 AM, =C1ngel Bartomeu Bonillo wrote: >>>>>>> Hello, >>>>>>> >>>>>>> I recently faced the problem of passively estimating the packet los= s >>>>>>> of TCP connection. After a bit of investigating the literature I >>>>>> found >>>>>>> that there are tens of papers addressing this issue but I couldn't >>>>>>> find any perfect solution. Since this is an important issue for >>>>>>> network operators I have been thinking that there would be a very >>>>>> easy >>>>>>> solution by just making the two TCP connection end points to accoun= t >>>>>>> for its sent segments and report it to the other end point in the >>>>>>> FIN >>>>>>> segment. This approach could be used as well for other measurable >>>>>>> parameters along the TCP session without the need for any other >>>>>>> offline method and It would be very helpful for detecting failures >>>>>>> along networks. >>>>>>> >>>>>>> Any comments? >>>>>> >>>>>> Regardless of when you do this - either at the end of a >>>>>> connection, or >>>>>> during a connection - the ONLY information you can provide is >>>>>> "here is >>>>>> a list of segments I have not yet received". >>>>>> >>>>>> However, that list is irrelevant. Those segments might be in the >>>>>> network and may still arrive - after you report, after the connectio= n >>>>>> is over, etc. >>>>>> >>>>>> There is no way to KNOW that a segment is lost vs. late. >>>>>> >>>>>> Even when you retransmit a segment (e.g., because it is basically >>>>>> overdue, either because your side's timer expired or the other side >>>>>> sent either a SACK or ACK indicating a gap), you don't know that the >>>>>> first segment was lost - it could arrive after the timer expires. >>>>>> >>>>>> Even though segments have TTLs, and TTLs are *supposed* to be >>>>>> decremented once every second or once every hop (whichever is >>>>>> greater), >>>>>> there are devices that queue packets for long periods (e.g., when a >>>>>> link is interrupted) and send them on later (even though they should >>>>>> have been dropped). >>>>>> >>>>>> So there is no such information as "lost segments"; the best you kno= w >>>>>> is retransmissions. >>>>>> >>>>>> However, keep in mind that there are lots of TCP connections that ar= e >>>>>> terminated without a FIN (e.g., using a RST - I don't think it's >>>>>> appropriate in many cases, but the method is in widespread use). >>>>>> >>>>>> Joe >>>>>> _______________________________________________ >>>>>> tcpm mailing list >>>>>> tcpm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/tcpm >>>>> >>>>> This communication is the property of CenturyLink and may contain >>>>> confidential or privileged information. Unauthorized use of this >>>>> communication is strictly >>>>> prohibited and may be unlawful. =A0If you have received this >>>>> communication >>>>> in error, please immediately notify the sender by reply e-mail and >>>>> destroy >>>>> all copies of the communication and any attachments. >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From mallman@icir.org Wed Feb 8 19:32:03 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C470B11E80A1 for ; Wed, 8 Feb 2012 19:32:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.419 X-Spam-Level: X-Spam-Status: No, score=-106.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwCgRuv2cWfj for ; Wed, 8 Feb 2012 19:32:03 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id CBB0A11E8098 for ; Wed, 8 Feb 2012 19:31:59 -0800 (PST) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id q193VtOA028679; Wed, 8 Feb 2012 19:31:56 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 05B9971E4BE; Wed, 8 Feb 2012 22:31:56 -0500 (EST) To: Yuchung Cheng From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Back in the Saddle X-URL-0: http://www.icir.org/mallman-files/Document74783.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma15915-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 08 Feb 2012 22:31:56 -0500 Sender: mallman@icir.org Message-Id: <20120209033156.05B9971E4BE@lawyers.icir.org> Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] TCP and applications [was Re: Aid passive estimate of tcp performance] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 03:32:03 -0000 ----------ma15915-1 Content-Type: text/plain Content-Disposition: inline > Can't agree more. We need a venue for two-way communications. > > app dev: TCP sucks because blah blah blah > TCP dudes: app sucks because blah blah blah Wellllll..... that is one reason everyone rearranges all the furniture in a big damn hotel three times a year. But, alas, you can lead a horse to water ... allman ----------ma15915-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk8zPisACgkQWyrrWs4yIs4czQCfc1zaHJ+yQVgyKChCaUuYjgj6 kIQAniPOADl4gI0e+1++a0pxPZ5sYYbo =zDyA -----END PGP SIGNATURE----- ----------ma15915-1-- From abartomeu@swissms.ch Thu Feb 9 00:16:16 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9645F21F85AC for ; Thu, 9 Feb 2012 00:16:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.874 X-Spam-Level: X-Spam-Status: No, score=-2.874 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pRPrC5wsSif for ; Thu, 9 Feb 2012 00:16:15 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id B1FA421F85AA for ; Thu, 9 Feb 2012 00:16:07 -0800 (PST) Received: by eekc41 with SMTP id c41so497828eek.31 for ; Thu, 09 Feb 2012 00:16:06 -0800 (PST) Received: by 10.213.15.209 with SMTP id l17mr66166eba.147.1328775366720; Thu, 09 Feb 2012 00:16:06 -0800 (PST) Received: from abartomeu-imac-c.eng.swissms.ch ([213.172.47.200]) by mx.google.com with ESMTPS id y12sm7051629eeb.11.2012.02.09.00.16.01 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Feb 2012 00:16:05 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?=C1ngel_Bartomeu_Bonillo?= In-Reply-To: <20120209033156.05B9971E4BE@lawyers.icir.org> Date: Thu, 9 Feb 2012 09:15:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0B8CEE4D-A296-4DAA-BD04-5BEF9BD360B4@swissms.ch> References: <20120209033156.05B9971E4BE@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkM3ouZolvPtmNCK8on6VV8CDnlsVjuZvZJJB0uQ0Tg+VQerGlZoT912rtYmVugTOFm4DDw Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] TCP and applications [was Re: Aid passive estimate of tcp performance] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 08:16:16 -0000 Well, the case that I had in mind was calculating the packet loss = passively from the end user. The estimation for packet loss would be the = number of retransmissions minus the number of spurious retransmission. = In the Uplink traffic you know the real number of retransmission and you = can estimate the spurious ones with the info in the DSAck. However in = the downlink it is impossible since you know the spurious but not the = real number of packets sent out by the other peer any approach would = fail in cases like having the remote peer in slow start and being all = the packets dropped. You never know if you do not get packets because = either there are no packets to send or because they were lost. There is obviously no point in changing the TCP just to aid this case = but I thought that maybe some of you would find a more generic usage for = this idea that I considered quite simple and I thought I could be = useful. I see now because of your comments that I was wrong since I = didn't see all this consideration you just showed.=20 Thanks anyways for your interesting comments. El 09/02/2012, a las 04:31, Mark Allman escribi=F3: >=20 >> Can't agree more. We need a venue for two-way communications. >>=20 >> app dev: TCP sucks because blah blah blah >> TCP dudes: app sucks because blah blah blah >=20 > Wellllll..... that is one reason everyone rearranges all the furniture > in a big damn hotel three times a year. But, alas, you can lead a = horse > to water ... >=20 > allman >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From wes@mti-systems.com Thu Feb 9 06:44:20 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F2B21F8726 for ; Thu, 9 Feb 2012 06:44:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXVSH+kInJuw for ; Thu, 9 Feb 2012 06:44:19 -0800 (PST) Received: from omr13.networksolutionsemail.com (omr13.networksolutionsemail.com [205.178.146.63]) by ietfa.amsl.com (Postfix) with ESMTP id 42FCF21F8717 for ; Thu, 9 Feb 2012 06:44:18 -0800 (PST) Received: from cm-omr14 (mail.networksolutionsemail.com [205.178.146.50]) by omr13.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q19EiIUB016769 for ; Thu, 9 Feb 2012 09:44:18 -0500 Authentication-Results: cm-omr14 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [69.81.143.202] ([69.81.143.202:47650] helo=[192.168.1.103]) by cm-omr14 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 16/BE-26895-2CBD33F4; Thu, 09 Feb 2012 09:44:18 -0500 Message-ID: <4F33DBC1.5010409@mti-systems.com> Date: Thu, 09 Feb 2012 09:44:17 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?=C1ngel_Bartomeu_Bonillo?= References: <20120209033156.05B9971E4BE@lawyers.icir.org> <0B8CEE4D-A296-4DAA-BD04-5BEF9BD360B4@swissms.ch> In-Reply-To: <0B8CEE4D-A296-4DAA-BD04-5BEF9BD360B4@swissms.ch> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] TCP and applications [was Re: Aid passive estimate of tcp performance] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 14:44:20 -0000 On 2/9/2012 3:15 AM, Ángel Bartomeu Bonillo wrote: > Well, the case that I had in mind was calculating the packet loss passively from the end user. The estimation for packet loss would be the number of retransmissions minus the number of spurious retransmission. In the Uplink traffic you know the real number of retransmission and you can estimate the spurious ones with the info in the DSAck. However in the downlink it is impossible since you know the spurious but not the real number of packets sent out by the other peer any approach would fail in cases like having the remote peer in slow start and being all the packets dropped. You never know if you do not get packets because either there are no packets to send or because they were lost. > Even from the sender-side where you know about all of the transmissions, you can still only compute an estimate due to sources of error like lost ACKs carrying DSACK information (as one easy example). There is (in my opinion) a good description of some algorithms for different types of connections (DSACK-supported, SACK but no DSACK, and no SACK) and the associated sources of error in: http://www.icir.org/mallman/papers/least-per-dec2003.ps Mark Allman, Wesley Eddy, Shawn Ostermann. Estimating Loss Rates With TCP. ACM Performance Evaluation Review, 31(3), December 2003. -- Wes Eddy MTI Systems From abartomeu@swissms.ch Thu Feb 9 06:59:38 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C770521F8730 for ; Thu, 9 Feb 2012 06:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZDI37l-ulmJ for ; Thu, 9 Feb 2012 06:59:38 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C830321F8731 for ; Thu, 9 Feb 2012 06:59:37 -0800 (PST) Received: by eekc41 with SMTP id c41so627536eek.31 for ; Thu, 09 Feb 2012 06:59:36 -0800 (PST) Received: by 10.213.32.140 with SMTP id c12mr3502417ebd.8.1328799576794; Thu, 09 Feb 2012 06:59:36 -0800 (PST) Received: from abartomeu-imac-c.eng.swissms.ch ([213.172.47.200]) by mx.google.com with ESMTPS id a58sm10485214eeb.8.2012.02.09.06.59.34 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Feb 2012 06:59:36 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?=C1ngel_Bartomeu_Bonillo?= In-Reply-To: <4F33DBC1.5010409@mti-systems.com> Date: Thu, 9 Feb 2012 15:59:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2C5E9279-99C3-4F8B-BAE4-2B035EA7F8AD@swissms.ch> References: <20120209033156.05B9971E4BE@lawyers.icir.org> <0B8CEE4D-A296-4DAA-BD04-5BEF9BD360B4@swissms.ch> <4F33DBC1.5010409@mti-systems.com> To: Wesley Eddy X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQk90dWOlZRRvtXgoHDnnOkUnSy7t7i5npFXe9ylsJ1FJjw6fG2zZiM5n1mXQlCYpc3DCh4m Cc: "tcpm@ietf.org" Subject: Re: [tcpm] TCP and applications [was Re: Aid passive estimate of tcp performance] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 14:59:38 -0000 El 09/02/2012, a las 15:44, Wesley Eddy escribi=F3: > On 2/9/2012 3:15 AM, =C1ngel Bartomeu Bonillo wrote: >> Well, the case that I had in mind was calculating the packet loss = passively from the end user. The estimation for packet loss would be the = number of retransmissions minus the number of spurious retransmission. = In the Uplink traffic you know the real number of retransmission and you = can estimate the spurious ones with the info in the DSAck. However in = the downlink it is impossible since you know the spurious but not the = real number of packets sent out by the other peer any approach would = fail in cases like having the remote peer in slow start and being all = the packets dropped. You never know if you do not get packets because = either there are no packets to send or because they were lost. >>=20 >=20 > Even from the sender-side where you know about all of the > transmissions, you can still only compute an estimate due > to sources of error like lost ACKs carrying DSACK information > (as one easy example). >=20 > There is (in my opinion) a good description of some algorithms > for different types of connections (DSACK-supported, SACK but > no DSACK, and no SACK) and the associated sources of error in: >=20 > http://www.icir.org/mallman/papers/least-per-dec2003.ps > Mark Allman, Wesley Eddy, Shawn Ostermann. > Estimating Loss Rates With TCP. > ACM Performance Evaluation Review, 31(3), December 2003. Yeah Wesley I have already read that and a few others. That's why I am = interested in the downlink. AFAIK the downlink is not covered in any = other paper. Thank you. >=20 > --=20 > Wes Eddy > MTI Systems From rs@netapp.com Tue Feb 14 05:13:46 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8963521F87BA for ; Tue, 14 Feb 2012 05:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNAKdzdpdDN7 for ; Tue, 14 Feb 2012 05:13:46 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1448A21F87AA for ; Tue, 14 Feb 2012 05:13:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.73,416,1325491200"; d="scan'208";a="625246040" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 14 Feb 2012 05:13:30 -0800 Received: from svlrsexc1-prd.hq.netapp.com (svlrsexc1-prd.hq.netapp.com [10.57.115.30]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q1EDDURC024788; Tue, 14 Feb 2012 05:13:30 -0800 (PST) Received: from VMWEXCEHT02-PRD.hq.netapp.com ([10.106.76.240]) by svlrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Feb 2012 05:13:25 -0800 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.211]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0247.003; Tue, 14 Feb 2012 05:13:25 -0800 From: "Scheffenegger, Richard" To: Pasi Sarolahti , "tcpm@ietf.org" Thread-Topic: [tcpm] WGLC for draft-ietf-tcpm-3517bis-01 Thread-Index: AQHM5mHEdud8Gtrf/Ea6Qq2jBK8xV5Y8ZzBg Date: Tue, 14 Feb 2012 13:13:25 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F095E6D@SACEXCMBX02-PRD.hq.netapp.com> References: <263ACA35-149C-4896-8FFE-69CB7E096626@iki.fi> In-Reply-To: <263ACA35-149C-4896-8FFE-69CB7E096626@iki.fi> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Feb 2012 13:13:25.0793 (UTC) FILETIME=[6F6C0910:01CCEB1A] Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-3517bis-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 13:13:46 -0000 I believe the draft is indeed ready for publication.=20 Thanks again to all the authors to pick up my vague suggestion which now=20 ended up as Rescue Retransmission! Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Pasi Sarolahti > Sent: Mittwoch, 08. Februar 2012 14:01 > To: tcpm@ietf.org > Subject: [tcpm] WGLC for draft-ietf-tcpm-3517bis-01 >=20 > Hello, >=20 > The authors of "A Conservative Selective Acknowledgment (SACK)-based > Loss Recovery Algorithm for TCP" (draft-ietf-tcpm-3517bis-01) think the > latest version addresses all comments made on the draft. Therefore, this > mail starts Working Group Last Call for the draft, intended to be publish= ed as > Proposed Standard. The WGLC ends on Friday, February 24, i.e., within a b= it > over two weeks. >=20 > Please read the draft and send any comments to the TCPM mailing list by t= he > above deadline. If you think the draft is ok and ready to be published wi= thout > further changes, indicating that would also be helpful. >=20 > The draft is available at http://tools.ietf.org/html/draft-ietf-tcpm-3517= bis-01 >=20 > - Pasi >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From pasi.sarolahti@iki.fi Fri Feb 17 02:43:32 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE98321F8771 for ; Fri, 17 Feb 2012 02:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.155 X-Spam-Level: X-Spam-Status: No, score=-106.155 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iAhySmbtrTB for ; Fri, 17 Feb 2012 02:43:32 -0800 (PST) Received: from smtp-2.hut.fi (smtp-2.hut.fi [130.233.228.92]) by ietfa.amsl.com (Postfix) with ESMTP id B621D21F86EC for ; Fri, 17 Feb 2012 02:43:31 -0800 (PST) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-2.hut.fi (8.13.6/8.12.10) with ESMTP id q1HAhUZK001124 for ; Fri, 17 Feb 2012 12:43:30 +0200 Received: from smtp-2.hut.fi ([130.233.228.92]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 04470-930 for ; Fri, 17 Feb 2012 12:43:29 +0200 (EET) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-2.hut.fi (8.13.6/8.12.10) with ESMTP id q1HAhKB6001106 for ; Fri, 17 Feb 2012 12:43:20 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 2B9071E1E4 for ; Fri, 17 Feb 2012 12:43:20 +0200 (EET) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id t5kOgJ5iGj30 for ; Fri, 17 Feb 2012 12:43:16 +0200 (EET) Received: from pc108.netlab.hut.fi (pc108.netlab.hut.fi [130.233.154.108]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id 932821E1DA for ; Fri, 17 Feb 2012 12:43:16 +0200 (EET) From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Feb 2012 12:43:18 +0200 Message-Id: To: tcpm@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Subject: [tcpm] Agenda requests for Paris meeting X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 10:43:32 -0000 Hi, We have requested a TCPM meeting slot in Paris. Send tcpm-chairs your = requests for topics to be presented in the TCPM meeting, with the = following information: * Presentation Title and draft name * Speaker * Amount of time requested Please send your requests as early as possible, to help us in agenda = planning. - Pasi From ietfa@btconnect.com Fri Feb 17 08:47:38 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA78E21E8039 for ; Fri, 17 Feb 2012 08:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_50=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivgtckXWrgvc for ; Fri, 17 Feb 2012 08:47:37 -0800 (PST) Received: from mail.btconnect.com (c2bthomr09.btconnect.com [213.123.20.127]) by ietfa.amsl.com (Postfix) with ESMTP id 9E05521E8076 for ; Fri, 17 Feb 2012 08:47:27 -0800 (PST) Received: from host86-163-138-100.range86-163.btcentralplus.com (HELO pc6) ([86.163.138.100]) by c2bthomr09.btconnect.com with SMTP id GJS46919; Fri, 17 Feb 2012 16:47:14 +0000 (GMT) Message-ID: <040b01cced8b$6761c700$4001a8c0@gateway.2wire.net> From: "t.petch" To: =?iso-8859-1?Q?=C1ngel_Bartomeu_Bonillo?= References: <920E9EEF-0BD8-4CB4-B385-149FCBC799E1@swissms.ch><555E24DE-0950-4471-B5B3-4902CF0AA833@mac.com> Date: Fri, 17 Feb 2012 16:46:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4F3E8491.0053, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.2.17.153024:17:7.944, ip=86.163.138.100, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, BODY_SIZE_3000_3999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020C.4F3E8494.00A4,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Cc: tcpm@ietf.org Subject: Re: [tcpm] Aid passive estimate of tcp performance X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 16:47:38 -0000 ----- Original Message ----- From: "Ángel Bartomeu Bonillo" To: "rick jones" Cc: Sent: Wednesday, February 08, 2012 6:52 PM Hi Rick, El 08/02/2012, a las 17:32, rick jones escribió: > > On Feb 8, 2012, at 4:15 AM, Ángel Bartomeu Bonillo wrote: > >> Hello, >> >> I recently faced the problem of passively estimating the packet loss of TCP connection. After a bit of investigating the literature I found that there are tens of papers addressing this issue but I couldn't find any perfect solution. >> Since this is an important issue for network operators I have been thinking that there would be a very easy solution by just making the two TCP connection end points to account for its sent segments and report it to the other end point in the FIN segment. >> This approach could be used as well for other measurable parameters along the TCP session without the need for any other offline method and It would be very helpful for detecting failures along networks. >> >> Any comments? > > If the count is reported in a FIN segment, isn't that rather like closing the barn door after the horses have left? At least as far as doing anything for that connection is concerned. So, already we are talking about operating on timescales larger than connection lifetimes. And what would the side receiving the count-containing FIN do with this information? Sure, now it is known on both ends, but the problem still lies somewhere in the middle (not always, but often). Is it expected that points along the middle will be sniffing this? What would they do in response? What could they (reasonably) do in response with that information just from TCP vs any other transports? > I'm talking about timescales larger than the connection lifetimes. This would be a mechanism so TCP can report how many packets it sent out. If both ends send at the end of the session the number of packets they sent out the other peer and anyone in the middle would be able to estimate de loss in both directions. The idea is to enable TCP so it can report a little but valuable information about its performance once the connection finished. This is not a mechanism so TCP can adapt to losses in the middle of a communication but rather a long term mechanism for network operators and such. Nowadays many of the end user services use TCP and the end to end packet loss is many times impossible to calculate mainly because only the sending node knows the real number of packets sent out. For example in the uplink direction on a mobile network. I think that adding just a couple of bytes (as a TCP option) to the FIN segment would give a priceless information for network operators. Apologies for being late to the party but I think that it is a lovely idea. As has been pointed out, the figures that you would collect are not what you want, but they would be a lot closer than anything available at the moment, and that is engineering. Ditto comments about RST; if there is a positive benefit to shutting down properly and getting these figures, then that could discourage RSTs. Tom Petch > When a sending TCP sends the first FIN with a count at the end of a MB window would it retransmit the FIN, even if the first was received, to include retransmissions in that last window's-worth of data? How long would the receiving TCP wait for this "final tally, really" FIN to arrive after it sent the ACK to SEQfin to then pass-along the count to a higher layer, somehow? The idea much simpler: the peer adds the num of packets sent during the connection as an option in the FIN. There is no need to change TCP behavior. > > I think we are already asking for enough angels to dance on the TCP pin-header. > > rick jones _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From internet-drafts@ietf.org Sat Feb 18 10:48:53 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C35221F84A7; Sat, 18 Feb 2012 10:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lT6nXaTwHqTE; Sat, 18 Feb 2012 10:48:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C5321F85FF; Sat, 18 Feb 2012 10:48:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120218184834.10341.23457.idtracker@ietfa.amsl.com> Date: Sat, 18 Feb 2012 10:48:34 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-fastopen-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 18:48:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions = Working Group of the IETF. Title : TCP Fast Open Author(s) : Yuchung Cheng Jerry Chu Sivasankar Radhakrishnan Arvind Jain Filename : draft-ietf-tcpm-fastopen-00.txt Pages : 21 Date : 2012-02-17 TCP Fast Open (TFO) allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, thus providing a saving of up to one full round trip time (RTT) compared to standard TCP requiring a three-way handshake (3WHS) to complete before data can be exchanged. Terminology A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-fastopen-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-fastopen-00.txt From Michael.Scharf@alcatel-lucent.com Mon Feb 20 02:20:09 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19F221F8715 for ; Mon, 20 Feb 2012 02:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.175 X-Spam-Level: X-Spam-Status: No, score=-6.175 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGeBdRcUzaAm for ; Mon, 20 Feb 2012 02:20:05 -0800 (PST) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id 9D74B21F8710 for ; Mon, 20 Feb 2012 02:20:04 -0800 (PST) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id q1KAK3oj023654 for ; Mon, 20 Feb 2012 11:20:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Feb 2012 11:19:59 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C06C80E67@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCPM rechartering discussion Thread-Index: AczvuTM6ZTA8qLanR6CuFmwrOkRRgA== From: "SCHARF, Michael" To: X-Scanned-By: MIMEDefang 2.69 on 149.204.45.73 Subject: [tcpm] TCPM rechartering discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 10:20:09 -0000 Dear all, The current TCPM charter https://datatracker.ietf.org/wg/tcpm/charter/ includes some outdated text. Most notably, the "Specific Goals" mentioned in the charter are not up to date. Also, the current charter requires IESG approval of every new milestone. Therefore, the chairs think that it would make sense to recharter TCPM in order to clean up the completed goals and to make it easier to manage future milestones. Please find below a first draft for a new charter text. The intention is a minor modification that does not to affect the overall scope of the working group. We would highly appreciate comments or suggestions. Best regards Michael (TCPM co-chair) TCP Maintenance and Minor Extensions (tcpm) ------------------------------------------- Description of Working Group: ***DRAFT*** TCP is currently the Internet's predominant transport protocol.=20 To maintain TCP's utility the IETF has regularly updated both=20 the protocol itself and the congestion control algorithms=20 implemented by the protocol that are crucial for the stability=20 of the Internet. These changes reflect our evolving=20 understanding of transport protocols, congestion control and new=20 needs presented by an ever-changing network. The TCPM WG provides a venue within the IETF to work on these issues. The WG=20 serves several purposes:=20 * The WG mostly focuses on maintenance issues (e.g., bug=20 fixes) and modest changes to the protocol and algorithms=20 that maintain TCP's utility, including incremental enhancements of the congestion control mechanisms. * The WG is a venue for moving current TCP specifications=20 along the standards track (as community energy is available=20 for such efforts).=20 * The focus of the working group are minor extensions to TCP algorithms and mechanisms. In cases where these are directly applicable to other transports (e.g. SCTP or DCCP), the mappings to other transports may be specified alongside that for TCP, but significant additions and changes to other transports are not in scope. TCPM is the working group within the IETF that handles small TCP changes, or minor extensions to TCP algorithms and mechanisms. While fundamental changes to TCP or its congestion control algorithms (e.g., departure from loss-based congestion control) should be brought through TCPM, it is expected that such large changes will be handled by other working groups or require additional reviews, in particular by the IRTF Congestion Control Research Group (ICCRG). TCP's congestion control algorithms are the model followed by=20 alternate transports (e.g., SCTP and (in some cases) DCCP), which are handled for instance by the Transport Area WG (tsvwg). The IETF has recently worked on several documents=20 about algorithms that are specified for multiple protocols=20 (e.g., TCP and SCTP) in the same document. Which WG shepherds=20 such documents will determined on a case-by-case=20 basis. In any case, the TCPM WG will remain in close contact=20 with other relevant WGs working on these protocols to ensure=20 openness and stringent review from all angles.=20 New TCPM milestones that fall within the scope specified within the charter can be added after approval of the working group and the responsible Area Director. From Michael.Scharf@alcatel-lucent.com Mon Feb 20 03:34:53 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4EA621F8769 for ; Mon, 20 Feb 2012 03:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.177 X-Spam-Level: X-Spam-Status: No, score=-6.177 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tR57IUTiLbw9 for ; Mon, 20 Feb 2012 03:34:51 -0800 (PST) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id 18C7F21F8741 for ; Mon, 20 Feb 2012 03:34:50 -0800 (PST) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id q1KBYmiJ001346; Mon, 20 Feb 2012 12:34:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Feb 2012 12:34:45 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C06C80E75@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Minimum nonce length in draft-touch-tcpm-experimental-options Thread-Index: Aczvw6TixopfpLhxSFeITUcMr0+rJA== From: "SCHARF, Michael" To: "Joe Touch" X-Scanned-By: MIMEDefang 2.69 on 149.204.45.73 Cc: tcpm@ietf.org Subject: [tcpm] Minimum nonce length in draft-touch-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 11:34:53 -0000 Joe, The wording on the nonce length in draft-touch-tcpm-experimental-options may be a little bit unclear ("it MAY be as few as 16 bits if desired"). Does that statement intend to say something like "MUST NOT be shorter than 16 bits long"? Or shall even a nonce of length 0 be allowed, provided that there are additional security mechanism such as checksums or digital signatures? In the latter case, existing use of the codepoints without nonce could be compliant to the recommendation, provided that there are other means to detect false positives. As a side note, I guess that the numbers "245 and 255" in the second paragraph are wrong. This should refer to 253 and 254, right? Michael (as individual) From abartomeu@swissms.ch Mon Feb 20 08:31:04 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B21521F8796 for ; Mon, 20 Feb 2012 08:31:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.744 X-Spam-Level: X-Spam-Status: No, score=-2.744 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4SD8ts0N-ln for ; Mon, 20 Feb 2012 08:31:00 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id C0AEF21F867C for ; Mon, 20 Feb 2012 08:30:59 -0800 (PST) Received: by eaal12 with SMTP id l12so2240684eaa.31 for ; Mon, 20 Feb 2012 08:30:58 -0800 (PST) Received-SPF: pass (google.com: domain of abartomeu@swissms.ch designates 10.14.49.144 as permitted sender) client-ip=10.14.49.144; Authentication-Results: mr.google.com; spf=pass (google.com: domain of abartomeu@swissms.ch designates 10.14.49.144 as permitted sender) smtp.mail=abartomeu@swissms.ch Received: from mr.google.com ([10.14.49.144]) by 10.14.49.144 with SMTP id x16mr11163832eeb.25.1329755458975 (num_hops = 1); Mon, 20 Feb 2012 08:30:58 -0800 (PST) Received: by 10.14.49.144 with SMTP id x16mr8895166eeb.25.1329755456986; Mon, 20 Feb 2012 08:30:56 -0800 (PST) Received: from abartomeu-imac-c.eng.swissms.ch ([213.172.47.200]) by mx.google.com with ESMTPS id o49sm79193030eeb.7.2012.02.20.08.30.54 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Feb 2012 08:30:56 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?=C1ngel_Bartomeu_Bonillo?= X-Priority: 3 In-Reply-To: <040b01cced8b$6761c700$4001a8c0@gateway.2wire.net> Date: Mon, 20 Feb 2012 17:30:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <920E9EEF-0BD8-4CB4-B385-149FCBC799E1@swissms.ch><555E24DE-0950-4471-B5B3-4902CF0AA833@mac.com> <040b01cced8b$6761c700$4001a8c0@gateway.2wire.net> To: t.petch X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkEuG3DwqZpmtYjy01czx2+oGMVhn+SrIu04TufbfK3Q3xA7P9LTDbYiddBHnCdxMKw0Kxs Cc: tcpm@ietf.org Subject: Re: [tcpm] Aid passive estimate of tcp performance X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 16:31:04 -0000 Hi Tom. What you say was my original point. However I have been overwhelmed by = the amount of drawbacks pointed out by the other folks.=20 My idea was to enable TCP to give a little report at the end of the = session. This report should be concise and simple. Just accounting for = any interesting parameters that are either difficult or impossible to be = obtained without an explicit procedure. I was thinking about the = estimate of the packet loss but I was hopping that other (more expert = people) would find any other interesting usages.=20 However, as I said, I think there have been too much negative feedback = on this idea so far.=20 What does everyone think? Should we give up with this issue? Thank you all. El 17/02/2012, a las 16:46, t.petch escribi=F3: > ----- Original Message ----- > From: "=C1ngel Bartomeu Bonillo" > To: "rick jones" > Cc: > Sent: Wednesday, February 08, 2012 6:52 PM > Hi Rick, > El 08/02/2012, a las 17:32, rick jones escribi=F3: >=20 >>=20 >> On Feb 8, 2012, at 4:15 AM, =C1ngel Bartomeu Bonillo wrote: >>=20 >>> Hello, >>>=20 >>> I recently faced the problem of passively estimating the packet loss = of TCP > connection. After a bit of investigating the literature I found that = there are > tens of papers addressing this issue but I couldn't find any perfect = solution. >>> Since this is an important issue for network operators I have been = thinking > that there would be a very easy solution by just making the two TCP = connection > end points to account for its sent segments and report it to the other = end point > in the FIN segment. >>> This approach could be used as well for other measurable parameters = along the > TCP session without the need for any other offline method and It would = be very > helpful for detecting failures along networks. >>>=20 >>> Any comments? >>=20 >> If the count is reported in a FIN segment, isn't that rather like = closing the > barn door after the horses have left? At least as far as doing = anything for > that connection is concerned. So, already we are talking about = operating on > timescales larger than connection lifetimes. And what would the side = receiving > the count-containing FIN do with this information? Sure, now it is = known on both > ends, but the problem still lies somewhere in the middle (not always, = but > often). Is it expected that points along the middle will be sniffing = this? > What would they do in response? What could they (reasonably) do in = response > with that information just from TCP vs any other transports? >>=20 >=20 > I'm talking about timescales larger than the connection lifetimes. = This would be > a mechanism so TCP can report how many packets it sent out. If both = ends send at > the end of the session the number of packets they sent out the other = peer and > anyone in the middle would be able to estimate de loss in both = directions. >=20 > The idea is to enable TCP so it can report a little but valuable = information > about its performance once the connection finished. This is not a = mechanism so > TCP can adapt to losses in the middle of a communication but rather a = long term > mechanism for network operators and such. Nowadays many of the end = user services > use TCP and the end to end packet loss is many times impossible to = calculate > mainly because only the sending node knows the real number of packets = sent out. > For example in the uplink direction on a mobile network. > I think that adding just a couple of bytes (as a TCP option) to the = FIN segment > would give a priceless information for network operators. >=20 > > Apologies for being late to the party but I think that it is a lovely = idea. As > has been pointed out, the figures that you would collect are not what = you want, > but they would be a lot closer than anything available at the moment, = and that > is engineering. Ditto comments about RST; if there is a positive = benefit to > shutting down properly and getting these figures, then that could = discourage > RSTs. >=20 > Tom Petch > >=20 >=20 >=20 >=20 >=20 >=20 >> When a sending TCP sends the first FIN with a count at the end of a = MB window > would it retransmit the FIN, even if the first was received, to = include > retransmissions in that last window's-worth of data? How long would = the > receiving TCP wait for this "final tally, really" FIN to arrive after = it sent > the ACK to SEQfin to then pass-along the count to a higher layer, = somehow? >=20 > The idea much simpler: the peer adds the num of packets sent during = the > connection as an option in the FIN. There is no need to change TCP = behavior. >=20 >>=20 >> I think we are already asking for enough angels to dance on the TCP > pin-header. >>=20 >> rick jones >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 >=20 From Michael.Scharf@alcatel-lucent.com Mon Feb 20 09:19:08 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8482E21F8584 for ; Mon, 20 Feb 2012 09:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.028 X-Spam-Level: X-Spam-Status: No, score=-6.028 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhMtpeT7PDvs for ; Mon, 20 Feb 2012 09:19:08 -0800 (PST) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id BACC521F8569 for ; Mon, 20 Feb 2012 09:19:07 -0800 (PST) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id q1KHJ4oK013022; Mon, 20 Feb 2012 18:19:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Feb 2012 18:19:01 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C06C80EC3@SLFSNX.rcs.alcatel-research.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Aid passive estimate of tcp performance Thread-Index: Aczv7Q+w9KW7HHyiRPGKDb9tJbBrLgAArz5A References: <920E9EEF-0BD8-4CB4-B385-149FCBC799E1@swissms.ch><555E24DE-0950-4471-B5B3-4902CF0AA833@mac.com><040b01cced8b$6761c700$4001a8c0@gateway.2wire.net> From: "SCHARF, Michael" To: =?iso-8859-1?Q?=C1ngel_Bartomeu_Bonillo?= X-Scanned-By: MIMEDefang 2.69 on 149.204.45.73 Cc: tcpm@ietf.org Subject: Re: [tcpm] Aid passive estimate of tcp performance X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 17:19:08 -0000 Hi Angel, > What you say was my original point. However I have been=20 > overwhelmed by the amount of drawbacks pointed out by the=20 > other folks.=20 Well, please note that TCP is not a trivial protocol. Even ideas that = appear to be trivial at first sight may require a careful analysis. This = is what the TCPM working group is about. > My idea was to enable TCP to give a little report at the end=20 > of the session. This report should be concise and simple.=20 > Just accounting for any interesting parameters that are=20 > either difficult or impossible to be obtained without an=20 > explicit procedure. I was thinking about the estimate of the=20 > packet loss but I was hopping that other (more expert people)=20 > would find any other interesting usages.=20 > However, as I said, I think there have been too much negative=20 > feedback on this idea so far.=20 >=20 > What does everyone think? My own view is that a gap analysis of the existing solutions would be a = good starting point. For instance, Section 5.10.14 in RFC 5102 apparently mentions a way to = export the total number of dropped packets by IPFIX, on a per-flow basis = (I am not familiar with IPFIX, so sorry if I miss something = fundamental). Potential related work in CONEX has already been mentioned = as well. We probably should better understand if another TCP option = offers a significant benefit compared to that, and in what cases. > Should we give up with this issue? Just to mention something obvious: The other alternative would be to put = together an Internet Draft that addresses the issues already mentioned = on the list. Michael From ananth@cisco.com Mon Feb 20 09:39:31 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89CC421F86B4 for ; Mon, 20 Feb 2012 09:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[AWL=1.700, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jp59Q0tpcHD6 for ; Mon, 20 Feb 2012 09:39:27 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD9A21F8798 for ; Mon, 20 Feb 2012 09:39:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=7791; q=dns/txt; s=iport; t=1329759567; x=1330969167; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Xx+Abm29jsq0T3NGc/wivgJfAUtFAZ27kpTT+3saauA=; b=bPbRwtoLEAT3V+OorrTxptp2ibE80LC8DxgkQODqXVmLf9X+L7oVOPmh KdKNe4p1ViCW1p8uH+Tj/QOEc898T4yscmirCFU0oht6s2qPgRpwbbk9O BEv4Qr0xCT6f67KF+1kxW+JrvURU8wOZP0k4Ffs132LFNJRKNNYNtgtAw A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHSEQk+rRDoI/2dsb2JhbABDsV6BB4FzAQEBBAEBAQ8BHTsDCwwEAgEIEQQBAQEKBgUSAQYBJh8JCAEBBAESCBMHh2egDQGXDwSLfAMJAwEDAwQDCQyDdUYPBAMMCgYDgkdjBIgbM593gTs X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="31441547" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 20 Feb 2012 17:39:27 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1KHdRUA013779; Mon, 20 Feb 2012 17:39:27 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Feb 2012 09:39:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Feb 2012 09:39:25 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580E88E7CB@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Aid passive estimate of tcp performance Thread-Index: Aczv7Q01EaKcMYFKSoGxoDaz7ktf5wABSbCQ References: <920E9EEF-0BD8-4CB4-B385-149FCBC799E1@swissms.ch><555E24DE-0950-4471-B5B3-4902CF0AA833@mac.com><040b01cced8b$6761c700$4001a8c0@gateway.2wire.net> From: "Anantha Ramaiah (ananth)" To: =?iso-8859-1?Q?=C1ngel_Bartomeu_Bonillo?= , "t.petch" X-OriginalArrivalTime: 20 Feb 2012 17:39:27.0166 (UTC) FILETIME=[979EC5E0:01CCEFF6] Cc: tcpm@ietf.org Subject: Re: [tcpm] Aid passive estimate of tcp performance X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 17:39:31 -0000 Angel: This is just my opinion. I wrote something earlier then withdrew it = based on a lot of email churn on this topic. I agree that this is not a bad idea. However to make it work, you do = need some TCP changes like :- - having a TCP option to agree upon this reporting between the = connection end points. - at the end of the TCP connection ( be it RST or FIN) you need some = clear cut ways to exchange the report. This would need some changes to TCP.=20 - Atleast in the RST case, (nothing prevents from the sender to put some = information in the RST data portion) FWIW, RFC 793 says RST segments can = contain data. RST becomes a best effort since RST segments can be lost.=20 - FIN case, you need to account for data in the flight and send the = report only when all the data has been acknowledged. Also questions like :- - do you want to send this report during the end OR anytime during the = lifetime of a connection? - do you want the active closer to send this report OR it could be sent = by a both ends? - There are many existing mechanisms that can be useful to obtain the = similar information which you are looking for, like :- In cases where it is feasible, active performance methods like the one = outlined in RFC 6349 can be used (several programs like TTCP, iPerf = etc., are there and can be useful), SNMP is often used to monitor the = connection characteristics, IPSLA (TWAMP is the equivalent IETF = proposal) is often used by network operators to measure network = characteristics. Poor man's version is to have a socket option which = would make TCP dump the connection block before the TCB gets freed = (which should include everything other than just packet counts), which = is purely local but useful. I just saw an email from Michael suggesting to write an ID, may be that = is a good starting point if you are planning to take this effort = seriously. Atleast the draft should have the use case clearly outlined = and the reasons why the existing mechanisms aren't good enough.=20 Thanks, -Anantha > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf = Of > =C1ngel Bartomeu Bonillo > Sent: Monday, February 20, 2012 8:31 AM > To: t.petch > Cc: tcpm@ietf.org > Subject: Re: [tcpm] Aid passive estimate of tcp performance >=20 > Hi Tom. > What you say was my original point. However I have been overwhelmed by > the amount of drawbacks pointed out by the other folks. > My idea was to enable TCP to give a little report at the end of the > session. This report should be concise and simple. Just accounting for > any interesting parameters that are either difficult or impossible to > be obtained without an explicit procedure. I was thinking about the > estimate of the packet loss but I was hopping that other (more expert > people) would find any other interesting usages. > However, as I said, I think there have been too much negative feedback > on this idea so far. >=20 > What does everyone think? > Should we give up with this issue? >=20 > Thank you all. >=20 > El 17/02/2012, a las 16:46, t.petch escribi=F3: >=20 > > ----- Original Message ----- > > From: "=C1ngel Bartomeu Bonillo" > > To: "rick jones" > > Cc: > > Sent: Wednesday, February 08, 2012 6:52 PM > > Hi Rick, > > El 08/02/2012, a las 17:32, rick jones escribi=F3: > > > >> > >> On Feb 8, 2012, at 4:15 AM, =C1ngel Bartomeu Bonillo wrote: > >> > >>> Hello, > >>> > >>> I recently faced the problem of passively estimating the packet > loss of TCP > > connection. After a bit of investigating the literature I found that > there are > > tens of papers addressing this issue but I couldn't find any perfect > solution. > >>> Since this is an important issue for network operators I have been > thinking > > that there would be a very easy solution by just making the two TCP > connection > > end points to account for its sent segments and report it to the > other end point > > in the FIN segment. > >>> This approach could be used as well for other measurable = parameters > along the > > TCP session without the need for any other offline method and It > would be very > > helpful for detecting failures along networks. > >>> > >>> Any comments? > >> > >> If the count is reported in a FIN segment, isn't that rather like > closing the > > barn door after the horses have left? At least as far as doing > anything for > > that connection is concerned. So, already we are talking about > operating on > > timescales larger than connection lifetimes. And what would the = side > receiving > > the count-containing FIN do with this information? Sure, now it is > known on both > > ends, but the problem still lies somewhere in the middle (not = always, > but > > often). Is it expected that points along the middle will be = sniffing > this? > > What would they do in response? What could they (reasonably) do in > response > > with that information just from TCP vs any other transports? > >> > > > > I'm talking about timescales larger than the connection lifetimes. > This would be > > a mechanism so TCP can report how many packets it sent out. If both > ends send at > > the end of the session the number of packets they sent out the other > peer and > > anyone in the middle would be able to estimate de loss in both > directions. > > > > The idea is to enable TCP so it can report a little but valuable > information > > about its performance once the connection finished. This is not a > mechanism so > > TCP can adapt to losses in the middle of a communication but rather = a > long term > > mechanism for network operators and such. Nowadays many of the end > user services > > use TCP and the end to end packet loss is many times impossible to > calculate > > mainly because only the sending node knows the real number of = packets > sent out. > > For example in the uplink direction on a mobile network. > > I think that adding just a couple of bytes (as a TCP option) to the > FIN segment > > would give a priceless information for network operators. > > > > > > Apologies for being late to the party but I think that it is a = lovely > idea. As > > has been pointed out, the figures that you would collect are not = what > you want, > > but they would be a lot closer than anything available at the = moment, > and that > > is engineering. Ditto comments about RST; if there is a positive > benefit to > > shutting down properly and getting these figures, then that could > discourage > > RSTs. > > > > Tom Petch > > > > > > > > > > > > > > > >> When a sending TCP sends the first FIN with a count at the end of a > MB window > > would it retransmit the FIN, even if the first was received, to > include > > retransmissions in that last window's-worth of data? How long would > the > > receiving TCP wait for this "final tally, really" FIN to arrive = after > it sent > > the ACK to SEQfin to then pass-along the count to a higher layer, > somehow? > > > > The idea much simpler: the peer adds the num of packets sent during > the > > connection as an option in the FIN. There is no need to change TCP > behavior. > > > >> > >> I think we are already asking for enough angels to dance on the TCP > > pin-header. > >> > >> rick jones > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > > > >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From perfgeek@mac.com Mon Feb 20 09:53:35 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E26D21F87CB for ; Mon, 20 Feb 2012 09:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.949 X-Spam-Level: X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=-1.350, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChgoB+ZzRFkl for ; Mon, 20 Feb 2012 09:53:31 -0800 (PST) Received: from asmtpout016.mac.com (asmtpout016.mac.com [17.148.16.91]) by ietfa.amsl.com (Postfix) with ESMTP id 18C1821F87B3 for ; Mon, 20 Feb 2012 09:53:30 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [192.168.1.65] (76-220-56-223.lightspeed.sntcca.sbcglobal.net [76.220.56.223]) by asmtp016.mac.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0LZP0066PDP5QD50@asmtp016.mac.com> for tcpm@ietf.org; Mon, 20 Feb 2012 17:53:30 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7361,1.0.260,0.0.0000 definitions=2012-02-20_03:2012-02-20, 2012-02-20, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1202200179 From: rick jones In-reply-to: <0C53DCFB700D144284A584F54711EC580E88E7CB@xmb-sjc-21c.amer.cisco.com> Date: Mon, 20 Feb 2012 09:53:28 -0800 Message-id: <0C4F7BD7-3E70-4D2E-B301-99CE3F253164@mac.com> References: <920E9EEF-0BD8-4CB4-B385-149FCBC799E1@swissms.ch> <555E24DE-0950-4471-B5B3-4902CF0AA833@mac.com> <040b01cced8b$6761c700$4001a8c0@gateway.2wire.net> <0C53DCFB700D144284A584F54711EC580E88E7CB@xmb-sjc-21c.amer.cisco.com> To: "Anantha Ramaiah (ananth)" X-Mailer: Apple Mail (2.1084) Cc: tcpm@ietf.org, "t.petch" Subject: Re: [tcpm] Aid passive estimate of tcp performance X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 17:53:35 -0000 On Feb 20, 2012, at 9:39 AM, Anantha Ramaiah (ananth) wrote: > - There are many existing mechanisms that can be useful to obtain the similar information which you are looking for, like :- > In cases where it is feasible, active performance methods like the one outlined in RFC 6349 can be used (several programs like TTCP, iPerf etc., are there and can be useful), FWIW, netperf (2.5.0 and later) can, under Linux, report the retransmission statistics from a TCP_INFO getsockopt() and will do so for either end. In this case I have Linux only at the far end, so I run a TCP_MAERTS test and report the "remote_transport_retrans" using the output selectors (*) $ ./netperf -l 20 -H -t TCP_MAERTS -- -O throughput,remote_transport_retrans -s 1M MIGRATED TCP MAERTS TEST from (null) (0.0.0.0) port 0 AF_INET to () port 0 AF_INET : demo Throughput Remote Transport Retransmissions 4.94 13 happy benchmarking, rick jones (*) http://www.netperf.org/svn/netperf2/tags/netperf-2.5.0/doc/netperf.html#Omni-Output-Selection MAERTS is STREAM spelled backwards and is a test where the netserver side sends to the netperf. From alexander.zimmermann@comsys.rwth-aachen.de Mon Feb 20 10:20:15 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A644521F85E1 for ; Mon, 20 Feb 2012 10:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OoFIGxTESDrQ for ; Mon, 20 Feb 2012 10:20:11 -0800 (PST) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by ietfa.amsl.com (Postfix) with ESMTP id 09F9321F85CF for ; Mon, 20 Feb 2012 10:20:11 -0800 (PST) MIME-version: 1.0 Received: from mx-out-1.rwth-aachen.de ([134.130.5.186]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LZP00CI0EXLLL30@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Mon, 20 Feb 2012 19:20:09 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.73,451,1325458800"; d="asc'?scan'208";a="166733355" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by mx-1.rz.rwth-aachen.de with ESMTP; Mon, 20 Feb 2012 19:20:09 +0100 Received: from [192.168.4.12] ([unknown] [213.219.161.252]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LZP000J2EXLWJ00@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Mon, 20 Feb 2012 19:20:09 +0100 (CET) Content-type: multipart/signed; boundary="Apple-Mail=_391323DD-D155-4B6C-9860-F1B582E111F5"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Alexander Zimmermann In-reply-to: <0C4F7BD7-3E70-4D2E-B301-99CE3F253164@mac.com> Date: Mon, 20 Feb 2012 19:20:10 +0100 Message-id: <54DC9A15-A9C9-4F32-81DE-F8A0623FA92C@comsys.rwth-aachen.de> References: <920E9EEF-0BD8-4CB4-B385-149FCBC799E1@swissms.ch> <555E24DE-0950-4471-B5B3-4902CF0AA833@mac.com> <040b01cced8b$6761c700$4001a8c0@gateway.2wire.net> <0C53DCFB700D144284A584F54711EC580E88E7CB@xmb-sjc-21c.amer.cisco.com> <0C4F7BD7-3E70-4D2E-B301-99CE3F253164@mac.com> To: rick jones X-Mailer: Apple Mail (2.1257) Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , "t.petch" Subject: Re: [tcpm] Aid passive estimate of tcp performance X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 18:20:15 -0000 --Apple-Mail=_391323DD-D155-4B6C-9860-F1B582E111F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Am 20.02.2012 um 18:53 schrieb rick jones: >=20 > On Feb 20, 2012, at 9:39 AM, Anantha Ramaiah (ananth) wrote: >> - There are many existing mechanisms that can be useful to obtain the = similar information which you are looking for, like :- >> In cases where it is feasible, active performance methods like the = one outlined in RFC 6349 can be used (several programs like TTCP, iPerf = etc., are there and can be useful), >=20 > FWIW, netperf (2.5.0 and later) can, under Linux, report the = retransmission statistics from a TCP_INFO getsockopt() and will do so = for either end. For the sake of completeness flowgrind (https://launchpad.net/flowgrind) = can do this too :-) See http://www.umic-mesh.net/research/flowgrind/output.html Alex // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // mobile: (49-176) 32820027, fax: (49-241) 80-22222 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // --Apple-Mail=_391323DD-D155-4B6C-9860-F1B582E111F5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iEYEARECAAYFAk9CjtoACgkQdyiq39b9uS4K6ACg67D8EIz+jIt7j71DjdCbdNHr 32wAn0JZRz1Y1qMob+21fVWxgNS6Q7Lk =OfsY -----END PGP SIGNATURE----- --Apple-Mail=_391323DD-D155-4B6C-9860-F1B582E111F5-- From abartomeu@swissms.ch Mon Feb 20 10:20:44 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD5821F85CF for ; Mon, 20 Feb 2012 10:20:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.037 X-Spam-Level: X-Spam-Status: No, score=-3.037 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fy1K-mp64SAc for ; Mon, 20 Feb 2012 10:20:42 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id CF25D21F8619 for ; Mon, 20 Feb 2012 10:20:41 -0800 (PST) Received: by eekc41 with SMTP id c41so2336443eek.31 for ; Mon, 20 Feb 2012 10:20:41 -0800 (PST) Received-SPF: pass (google.com: domain of abartomeu@swissms.ch designates 10.213.114.9 as permitted sender) client-ip=10.213.114.9; Authentication-Results: mr.google.com; spf=pass (google.com: domain of abartomeu@swissms.ch designates 10.213.114.9 as permitted sender) smtp.mail=abartomeu@swissms.ch Received: from mr.google.com ([10.213.114.9]) by 10.213.114.9 with SMTP id c9mr2717405ebq.56.1329762041110 (num_hops = 1); Mon, 20 Feb 2012 10:20:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=dLsERF17F81eQ+t/hk8TwFwBdg6YQPsWEtCW+TeSL3g=; b=R+Y7UaXLhub+fOF275qVMMSbpNa5p4H4ElFHCdb/gIUlSpbz804xFt9SBuO9W8cxFf iEqKx8YZSQ/xSXx+ZJ+yZFwwDcFdIZrQnRajtAmcN0EWDTnbOUqNGnA4g+Rgay6xLOTT dsdEquxTV7+Em1HfhJdr72H7zPGsZVADpVQK0= Received: by 10.213.114.9 with SMTP id c9mr2153630ebq.56.1329762040926; Mon, 20 Feb 2012 10:20:40 -0800 (PST) Received: from abartomeu-imac-c.eng.swissms.ch ([213.172.47.200]) by mx.google.com with ESMTPS id v51sm80226091eef.2.2012.02.20.10.20.38 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Feb 2012 10:20:39 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?=C1ngel_Bartomeu_Bonillo?= In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C06C80EC3@SLFSNX.rcs.alcatel-research.de> Date: Mon, 20 Feb 2012 19:20:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <920E9EEF-0BD8-4CB4-B385-149FCBC799E1@swissms.ch><555E24DE-0950-4471-B5B3-4902CF0AA833@mac.com><040b01cced8b$6761c700$4001a8c0@gateway.2wire.net> <133D9897FB9C5E4E9DF2779DC91E947C06C80EC3@SLFSNX.rcs.alcatel-research.de> To: "SCHARF, Michael" X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkUB5YSavqRoQQ0pLihuHl93Q6IjuN9v6WyydDlwQW2JRflTQIH1C4VH8XllrjGToaiW9R2 Cc: tcpm@ietf.org Subject: Re: [tcpm] Aid passive estimate of tcp performance X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 18:20:44 -0000 Hi Michael. El 20/02/2012, a las 18:19, SCHARF, Michael escribi=F3: > Hi Angel, >=20 >> What you say was my original point. However I have been=20 >> overwhelmed by the amount of drawbacks pointed out by the=20 >> other folks.=20 >=20 > Well, please note that TCP is not a trivial protocol. Even ideas that = appear to be trivial at first sight may require a careful analysis. This = is what the TCPM working group is about. Sure thing :) >=20 >> My idea was to enable TCP to give a little report at the end=20 >> of the session. This report should be concise and simple.=20 >> Just accounting for any interesting parameters that are=20 >> either difficult or impossible to be obtained without an=20 >> explicit procedure. I was thinking about the estimate of the=20 >> packet loss but I was hopping that other (more expert people)=20 >> would find any other interesting usages.=20 >> However, as I said, I think there have been too much negative=20 >> feedback on this idea so far.=20 >>=20 >> What does everyone think? >=20 > My own view is that a gap analysis of the existing solutions would be = a good starting point. I agree here too but, first of all, I would evaluate the the possible = benefits of making TCP have its own report mechanism.=20 Let's imagine there was a group of measurable parameters that are = configurable in the handshake using an option. If both peer support them = and are able to report them (or are configured to do so) they would add = this information in the FIN/RST, or maybe in some other point (I'm not = sure about this). =20 Now here is in my opinion the key questions:=20 - would TCP benefit from the use of this in the long term?=20 - If this report mechanism becomes usual, could it help, for example, to = ease the research on future enhancements or changes to TCP? >=20 > For instance, Section 5.10.14 in RFC 5102 apparently mentions a way to = export the total number of dropped packets by IPFIX, on a per-flow basis = (I am not familiar with IPFIX, so sorry if I miss something = fundamental). Potential related work in CONEX has already been mentioned = as well. We probably should better understand if another TCP option = offers a significant benefit compared to that, and in what cases. >=20 >> Should we give up with this issue? >=20 > Just to mention something obvious: The other alternative would be to = put together an Internet Draft that addresses the issues already = mentioned on the list. Since I'm a newbie here I will rely on the community for this. >=20 > Michael >=20 From perfgeek@mac.com Mon Feb 20 11:26:31 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B55321F87CB for ; Mon, 20 Feb 2012 11:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.774 X-Spam-Level: X-Spam-Status: No, score=-5.774 tagged_above=-999 required=5 tests=[AWL=0.825, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkX1H4ZVDcx7 for ; Mon, 20 Feb 2012 11:26:27 -0800 (PST) Received: from asmtpout012.mac.com (asmtpout012.mac.com [17.148.16.87]) by ietfa.amsl.com (Postfix) with ESMTP id 058A321F87C7 for ; Mon, 20 Feb 2012 11:26:27 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [192.168.1.65] (76-220-56-223.lightspeed.sntcca.sbcglobal.net [76.220.56.223]) by asmtp012.mac.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0LZP00EHTI00T120@asmtp012.mac.com> for tcpm@ietf.org; Mon, 20 Feb 2012 19:26:26 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7361,1.0.260,0.0.0000 definitions=2012-02-20_03:2012-02-20, 2012-02-20, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1202200204 From: rick jones In-reply-to: <54DC9A15-A9C9-4F32-81DE-F8A0623FA92C@comsys.rwth-aachen.de> Date: Mon, 20 Feb 2012 11:26:24 -0800 Message-id: References: <920E9EEF-0BD8-4CB4-B385-149FCBC799E1@swissms.ch> <555E24DE-0950-4471-B5B3-4902CF0AA833@mac.com> <040b01cced8b$6761c700$4001a8c0@gateway.2wire.net> <0C53DCFB700D144284A584F54711EC580E88E7CB@xmb-sjc-21c.amer.cisco.com> <0C4F7BD7-3E70-4D2E-B301-99CE3F253164@mac.com> <54DC9A15-A9C9-4F32-81DE-F8A0623FA92C@comsys.rwth-aachen.de> To: Alexander Zimmermann X-Mailer: Apple Mail (2.1084) Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , "t.petch" Subject: Re: [tcpm] Aid passive estimate of tcp performance X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 19:26:31 -0000 On Feb 20, 2012, at 10:20 AM, Alexander Zimmermann wrote: > > Am 20.02.2012 um 18:53 schrieb rick jones: > >> >> On Feb 20, 2012, at 9:39 AM, Anantha Ramaiah (ananth) wrote: >>> - There are many existing mechanisms that can be useful to obtain the similar information which you are looking for, like :- >>> In cases where it is feasible, active performance methods like the one outlined in RFC 6349 can be used (several programs like TTCP, iPerf etc., are there and can be useful), >> >> FWIW, netperf (2.5.0 and later) can, under Linux, report the retransmission statistics from a TCP_INFO getsockopt() and will do so for either end. > > For the sake of completeness flowgrind (https://launchpad.net/flowgrind) can do this too :-) > See http://www.umic-mesh.net/research/flowgrind/output.html Excellent. Looks like it goes rather farther than netperf in that area - reporting the TCP_INFO on the intervals. Netperf only does it at the end of the test, and then only for retransmissions. rick jones there is no rest for the wicked, yet the virtuous have no pillows From abartomeu@swissms.ch Tue Feb 21 02:05:30 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7CC21F8638 for ; Tue, 21 Feb 2012 02:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.774 X-Spam-Level: X-Spam-Status: No, score=-2.774 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RF6pBxlPnr0G for ; Tue, 21 Feb 2012 02:05:26 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2974721F8633 for ; Tue, 21 Feb 2012 02:05:22 -0800 (PST) Received: by eekc41 with SMTP id c41so2545248eek.31 for ; Tue, 21 Feb 2012 02:05:22 -0800 (PST) Received-SPF: pass (google.com: domain of abartomeu@swissms.ch designates 10.14.29.66 as permitted sender) client-ip=10.14.29.66; Authentication-Results: mr.google.com; spf=pass (google.com: domain of abartomeu@swissms.ch designates 10.14.29.66 as permitted sender) smtp.mail=abartomeu@swissms.ch Received: from mr.google.com ([10.14.29.66]) by 10.14.29.66 with SMTP id h42mr12454468eea.75.1329818722213 (num_hops = 1); Tue, 21 Feb 2012 02:05:22 -0800 (PST) Received: by 10.14.29.66 with SMTP id h42mr9926159eea.75.1329818722040; Tue, 21 Feb 2012 02:05:22 -0800 (PST) Received: from abartomeu-imac-c.eng.swissms.ch ([213.172.47.200]) by mx.google.com with ESMTPS id c16sm88527690eei.1.2012.02.21.02.05.19 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Feb 2012 02:05:21 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?=C1ngel_Bartomeu_Bonillo?= In-Reply-To: <0C53DCFB700D144284A584F54711EC580E88E7CB@xmb-sjc-21c.amer.cisco.com> Date: Tue, 21 Feb 2012 11:05:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8DCAECB1-4794-45DB-830E-1E120943761E@swissms.ch> References: <920E9EEF-0BD8-4CB4-B385-149FCBC799E1@swissms.ch><555E24DE-0950-4471-B5B3-4902CF0AA833@mac.com><040b01cced8b$6761c700$4001a8c0@gateway.2wire.net> <0C53DCFB700D144284A584F54711EC580E88E7CB@xmb-sjc-21c.amer.cisco.com> To: Anantha Ramaiah (ananth) X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQlCaK4Oi+RDQ3bOqFythY3Te3jNg/TeTYIzV8pZxtHOCS5aG1ftZdyxkKWyKpTzDWKRQ+ap Cc: tcpm@ietf.org, "t.petch" Subject: Re: [tcpm] Aid passive estimate of tcp performance X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 10:05:30 -0000 Hi Anantha. El 20/02/2012, a las 18:39, Anantha Ramaiah (ananth) escribi=F3: > Angel: >=20 > This is just my opinion. I wrote something earlier then withdrew it = based on a lot of email churn on this topic. >=20 > I agree that this is not a bad idea. However to make it work, you do = need some TCP changes like :- > - having a TCP option to agree upon this reporting between the = connection end points. Yes. Like with the SACK option. > - at the end of the TCP connection ( be it RST or FIN) you need some = clear cut ways to exchange the report. > This would need some changes to TCP.=20 > - Atleast in the RST case, (nothing prevents from the sender to put = some information in the RST data portion) FWIW, RFC 793 says RST = segments can contain data. RST becomes a best effort since RST segments = can be lost.=20 > - FIN case, you need to account for data in the flight and send the = report only when all the data has been acknowledged. >=20 I think that a approach could be next:=20 Every peer reports the number of data segments sent out in the FIN = segment. Every peer reports the number of data segments received in the ACK to = the FIN segment. As for the RST, AFAIK it does not indicate a normal connection end so I = think we should not consider that case. Also, as Tom pointed out, it = could discourage its use for ending connections. > Also questions like :- > - do you want to send this report during the end OR anytime during the = lifetime of a connection? > - do you want the active closer to send this report OR it could be = sent by a both ends? > - There are many existing mechanisms that can be useful to obtain the = similar information which you are looking for, like :- > In cases where it is feasible, active performance methods like the one = outlined in RFC 6349 can be used (several programs like TTCP, iPerf = etc., are there and can be useful), SNMP is often used to monitor the = connection characteristics, IPSLA (TWAMP is the equivalent IETF = proposal) is often used by network operators to measure network = characteristics. Poor man's version is to have a socket option which = would make TCP dump the connection block before the TCB gets freed = (which should include everything other than just packet counts), which = is purely local but useful. The problem in this tools you mentioned is that they do active tests and = you need to control both ends. If TCP would have it own report mechanism = these tests would be much easier to do in a passive and more wide way. >=20 > I just saw an email from Michael suggesting to write an ID, may be = that is a good starting point if you are planning to take this effort = seriously. Atleast the draft should have the use case clearly outlined = and the reasons why the existing mechanisms aren't good enough.=20 After hearing the community comments I'm not sure that just this would = be worth the effort. Also I'm not sure if Operating System would = implement it by default. If not then it would become another iperf that = you have to configure in both ends. Do you think such a little tool would be worth it? Not just the effort = but the fact of adding complexity to TCP. However as I mentioned in a previous mail I was also thinking in a more = generic and extensible report system in case we agree that it could = benefit aid the monitor of TCP in a more generic way. >=20 > Thanks, > -Anantha >=20 >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf = Of >> =C1ngel Bartomeu Bonillo >> Sent: Monday, February 20, 2012 8:31 AM >> To: t.petch >> Cc: tcpm@ietf.org >> Subject: Re: [tcpm] Aid passive estimate of tcp performance >>=20 >> Hi Tom. >> What you say was my original point. However I have been overwhelmed = by >> the amount of drawbacks pointed out by the other folks. >> My idea was to enable TCP to give a little report at the end of the >> session. This report should be concise and simple. Just accounting = for >> any interesting parameters that are either difficult or impossible to >> be obtained without an explicit procedure. I was thinking about the >> estimate of the packet loss but I was hopping that other (more expert >> people) would find any other interesting usages. >> However, as I said, I think there have been too much negative = feedback >> on this idea so far. >>=20 >> What does everyone think? >> Should we give up with this issue? >>=20 >> Thank you all. >>=20 >> El 17/02/2012, a las 16:46, t.petch escribi=F3: >>=20 >>> ----- Original Message ----- >>> From: "=C1ngel Bartomeu Bonillo" >>> To: "rick jones" >>> Cc: >>> Sent: Wednesday, February 08, 2012 6:52 PM >>> Hi Rick, >>> El 08/02/2012, a las 17:32, rick jones escribi=F3: >>>=20 >>>>=20 >>>> On Feb 8, 2012, at 4:15 AM, =C1ngel Bartomeu Bonillo wrote: >>>>=20 >>>>> Hello, >>>>>=20 >>>>> I recently faced the problem of passively estimating the packet >> loss of TCP >>> connection. After a bit of investigating the literature I found that >> there are >>> tens of papers addressing this issue but I couldn't find any perfect >> solution. >>>>> Since this is an important issue for network operators I have been >> thinking >>> that there would be a very easy solution by just making the two TCP >> connection >>> end points to account for its sent segments and report it to the >> other end point >>> in the FIN segment. >>>>> This approach could be used as well for other measurable = parameters >> along the >>> TCP session without the need for any other offline method and It >> would be very >>> helpful for detecting failures along networks. >>>>>=20 >>>>> Any comments? >>>>=20 >>>> If the count is reported in a FIN segment, isn't that rather like >> closing the >>> barn door after the horses have left? At least as far as doing >> anything for >>> that connection is concerned. So, already we are talking about >> operating on >>> timescales larger than connection lifetimes. And what would the = side >> receiving >>> the count-containing FIN do with this information? Sure, now it is >> known on both >>> ends, but the problem still lies somewhere in the middle (not = always, >> but >>> often). Is it expected that points along the middle will be = sniffing >> this? >>> What would they do in response? What could they (reasonably) do in >> response >>> with that information just from TCP vs any other transports? >>>>=20 >>>=20 >>> I'm talking about timescales larger than the connection lifetimes. >> This would be >>> a mechanism so TCP can report how many packets it sent out. If both >> ends send at >>> the end of the session the number of packets they sent out the other >> peer and >>> anyone in the middle would be able to estimate de loss in both >> directions. >>>=20 >>> The idea is to enable TCP so it can report a little but valuable >> information >>> about its performance once the connection finished. This is not a >> mechanism so >>> TCP can adapt to losses in the middle of a communication but rather = a >> long term >>> mechanism for network operators and such. Nowadays many of the end >> user services >>> use TCP and the end to end packet loss is many times impossible to >> calculate >>> mainly because only the sending node knows the real number of = packets >> sent out. >>> For example in the uplink direction on a mobile network. >>> I think that adding just a couple of bytes (as a TCP option) to the >> FIN segment >>> would give a priceless information for network operators. >>>=20 >>> >>> Apologies for being late to the party but I think that it is a = lovely >> idea. As >>> has been pointed out, the figures that you would collect are not = what >> you want, >>> but they would be a lot closer than anything available at the = moment, >> and that >>> is engineering. Ditto comments about RST; if there is a positive >> benefit to >>> shutting down properly and getting these figures, then that could >> discourage >>> RSTs. >>>=20 >>> Tom Petch >>> >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> When a sending TCP sends the first FIN with a count at the end of a >> MB window >>> would it retransmit the FIN, even if the first was received, to >> include >>> retransmissions in that last window's-worth of data? How long would >> the >>> receiving TCP wait for this "final tally, really" FIN to arrive = after >> it sent >>> the ACK to SEQfin to then pass-along the count to a higher layer, >> somehow? >>>=20 >>> The idea much simpler: the peer adds the num of packets sent during >> the >>> connection as an option in the FIN. There is no need to change TCP >> behavior. >>>=20 >>>>=20 >>>> I think we are already asking for enough angels to dance on the TCP >>> pin-header. >>>>=20 >>>> rick jones >>>=20 >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm From abartomeu@swissms.ch Tue Feb 21 02:25:50 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8EA721F8681 for ; Tue, 21 Feb 2012 02:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.064 X-Spam-Level: X-Spam-Status: No, score=-3.064 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Z6WEEoMA701 for ; Tue, 21 Feb 2012 02:25:46 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id D0E9221F8611 for ; Tue, 21 Feb 2012 02:25:45 -0800 (PST) Received: by eaal12 with SMTP id l12so2494276eaa.31 for ; Tue, 21 Feb 2012 02:25:44 -0800 (PST) Received-SPF: pass (google.com: domain of abartomeu@swissms.ch designates 10.14.99.195 as permitted sender) client-ip=10.14.99.195; Authentication-Results: mr.google.com; spf=pass (google.com: domain of abartomeu@swissms.ch designates 10.14.99.195 as permitted sender) smtp.mail=abartomeu@swissms.ch Received: from mr.google.com ([10.14.99.195]) by 10.14.99.195 with SMTP id x43mr12829421eef.46.1329819944960 (num_hops = 1); Tue, 21 Feb 2012 02:25:44 -0800 (PST) Received: by 10.14.99.195 with SMTP id x43mr10224712eef.46.1329819943349; Tue, 21 Feb 2012 02:25:43 -0800 (PST) Received: from abartomeu-imac-c.eng.swissms.ch ([213.172.47.200]) by mx.google.com with ESMTPS id w60sm88659145eeb.4.2012.02.21.02.25.40 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Feb 2012 02:25:42 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1--674579099 From: =?iso-8859-1?Q?=C1ngel_Bartomeu_Bonillo?= In-Reply-To: <54DC9A15-A9C9-4F32-81DE-F8A0623FA92C@comsys.rwth-aachen.de> Date: Tue, 21 Feb 2012 11:25:39 +0100 Message-Id: <2AAD0BF9-9B46-4A80-A990-A91E001E6E8C@swissms.ch> References: <920E9EEF-0BD8-4CB4-B385-149FCBC799E1@swissms.ch> <555E24DE-0950-4471-B5B3-4902CF0AA833@mac.com> <040b01cced8b$6761c700$4001a8c0@gateway.2wire.net> <0C53DCFB700D144284A584F54711EC580E88E7CB@xmb-sjc-21c.amer.cisco.com> <0C4F7BD7-3E70-4D2E-B301-99CE3F253164@mac.com> <54DC9A15-A9C9-4F32-81DE-F8A0623FA92C@comsys.rwth-aachen.de> To: Alexander Zimmermann X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnvAERGfIJ3MQv41rNmOYXQzUNlL1o1ovxGbTT0+1vgNyuQps/JnBXiiyk7GwBCarnNTvs8 Cc: tcpm@ietf.org Subject: Re: [tcpm] Aid passive estimate of tcp performance X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 10:25:51 -0000 --Apple-Mail-1--674579099 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Interesting tool Alexander. El 20/02/2012, a las 19:20, Alexander Zimmermann escribi=F3: >=20 > Am 20.02.2012 um 18:53 schrieb rick jones: >=20 >>=20 >> On Feb 20, 2012, at 9:39 AM, Anantha Ramaiah (ananth) wrote: >>> - There are many existing mechanisms that can be useful to obtain = the similar information which you are looking for, like :- >>> In cases where it is feasible, active performance methods like the = one outlined in RFC 6349 can be used (several programs like TTCP, iPerf = etc., are there and can be useful), >>=20 >> FWIW, netperf (2.5.0 and later) can, under Linux, report the = retransmission statistics from a TCP_INFO getsockopt() and will do so = for either end. >=20 > For the sake of completeness flowgrind = (https://launchpad.net/flowgrind) can do this too :-) > See http://www.umic-mesh.net/research/flowgrind/output.html >=20 > Alex >=20 > // > // Dipl.-Inform. Alexander Zimmermann > // Department of Computer Science, Informatik 4 > // RWTH Aachen University > // Ahornstr. 55, 52056 Aachen, Germany > // mobile: (49-176) 32820027, fax: (49-241) 80-22222 > // email: zimmermann@cs.rwth-aachen.de > // web: http://www.umic-mesh.net > // >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm Este mensaje contiene informaci=F3n reservada y confidencial destinada = exclusivamente al destinatario. Si usted no es el destinatario no est=E1 = autorizado a copiar, reproducir o distribuir este mensaje ni su = contenido. Si ha recibido este mensaje por error, le rogamos que nos lo = notifique inmediatamente. The information in this e-mail is confidential and may be legally = privileged. It is intended solely for the addressee(s). It may contain = privileged and confidential information. If you are not the intended = recipient, please destroy this message and notify us immediately. Any = disclosure, copying or distribution of this message is prohibited and = may be unlawful. --Apple-Mail-1--674579099 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

Am = 20.02.2012 um 18:53 schrieb rick jones:


On Feb 20, = 2012, at 9:39 AM, Anantha Ramaiah (ananth) = wrote:
- There are many existing mechanisms that can be useful to = obtain the similar information which you are looking for, like = :-
In cases where it is feasible, active performance methods = like the one outlined in RFC 6349 can be used (several programs like = TTCP, iPerf etc.,  are there and can be = useful),

FWIW, netperf = (2.5.0 and later) can, under Linux, report the retransmission statistics = from a TCP_INFO getsockopt() and will do so for either = end.

For the sake of completeness flowgrind (https://launchpad.net/flowgrind) can do this too :-)
See http://ww= w.umic-mesh.net/research/flowgrind/output.html

Alex

//// Dipl.-Inform. Alexander Zimmermann
// Department of Computer = Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, = 52056 Aachen, Germany
// mobile: (49-176) 32820027, fax: (49-241) = 80-22222
// email: zimmermann@cs.rwth-aachen.de<= /a>
// web: http://www.umic-mesh.net
//
_______________________________________________
tcpm mailing = list
tcpm@ietf.org
https://www.ietf.org/ma= ilman/listinfo/tcpm

Este mensaje contiene informaci=F3n = reservada y confidencial destinada exclusivamente al destinatario. Si = usted no es el destinatario no est=E1 autorizado a copiar, reproducir o = distribuir este mensaje ni su contenido. Si ha recibido este mensaje por = error, le rogamos que nos lo notifique = inmediatamente.

The information in this e-mail is confidential and = may be legally privileged. It is intended solely for the addressee(s). = It may contain privileged and confidential information. If you are not = the intended recipient, please destroy this message and notify us = immediately. Any disclosure, copying or distribution of this message is = prohibited and may be unlawful.




= --Apple-Mail-1--674579099-- From ananth@cisco.com Tue Feb 21 08:44:49 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77ABC21F86D0 for ; Tue, 21 Feb 2012 08:44:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.242 X-Spam-Level: X-Spam-Status: No, score=-8.242 tagged_above=-999 required=5 tests=[AWL=1.457, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaVA4nG7flLx for ; Tue, 21 Feb 2012 08:44:45 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3D07C21F86A2 for ; Tue, 21 Feb 2012 08:44:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=6984; q=dns/txt; s=iport; t=1329842685; x=1331052285; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=o927gmYQGRwt8QqVtRrOWx5eVepnJBghBYF/7U3N8oI=; b=MIRczH6KYn2ztp3JdMWX7IkeSDuRugB0AwFx7V+msYOGQRprS5+q0/lg E8iGpIddqOajW9S0F/qAwpnCYgpw0dGyUm8hgAN2sIgapZ1+s/O5w8ARh RmEKljAF7r7Z4LDKkkCAKKItAZmZ5eYMAraizMhPGg1h/PbZeC34zs4Wu w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFACzJQ0+rRDoI/2dsb2JhbABDskaBB4FzAQEBAwEBAQEPAR07AwsMBAIBCBEEAQEBCgYFEgEGASYfCQgBAQQTCBMHh14JoBIBlyQEiWSCDwMJCgQDCQyDdUYPBAMMCgYDgkdjBIgcM593gTs X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="31433172" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 21 Feb 2012 16:44:45 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1LGiifq018703; Tue, 21 Feb 2012 16:44:44 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Feb 2012 08:44:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Feb 2012 08:42:28 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580E913678@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <8DCAECB1-4794-45DB-830E-1E120943761E@swissms.ch> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Aid passive estimate of tcp performance Thread-Index: AczwgFQkXla68ZtYTUmOExbWNY7o3AAMv2Hg References: <920E9EEF-0BD8-4CB4-B385-149FCBC799E1@swissms.ch><555E24DE-0950-4471-B5B3-4902CF0AA833@mac.com><040b01cced8b$6761c700$4001a8c0@gateway.2wire.net> <0C53DCFB700D144284A584F54711EC580E88E7CB@xmb-sjc-21c.amer.cisco.com> <8DCAECB1-4794-45DB-830E-1E120943761E@swissms.ch> From: "Anantha Ramaiah (ananth)" To: =?iso-8859-1?Q?=C1ngel_Bartomeu_Bonillo?= X-OriginalArrivalTime: 21 Feb 2012 16:44:44.0816 (UTC) FILETIME=[1D99A900:01CCF0B8] Cc: tcpm@ietf.org, "t.petch" Subject: Re: [tcpm] Aid passive estimate of tcp performance X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 16:44:49 -0000 >=20 > Do you think such a little tool would be worth it? Not just the effort > but the fact of adding complexity to TCP. >=20 > However as I mentioned in a previous mail I was also thinking in a = more > generic and extensible report system in case we agree that it could > benefit aid the monitor of TCP in a more generic way. RFC 6349 was about TCP performance benchmarking, the same rationale can = be applied to this effort since it is related.. but the key difference = is that this calls for some minor additions to TCP. I agree that it = would be a useful thing if TCPM wants to look into it. OTOH, I would think such an effort could fall into the jurisdiction of = IPPM WG, but if it has TCP changes then it would anyways need to come to = TCPM.=20 -Anantha >=20 >=20 > > > > Thanks, > > -Anantha > > > >> -----Original Message----- > >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On = Behalf > Of > >> =C1ngel Bartomeu Bonillo > >> Sent: Monday, February 20, 2012 8:31 AM > >> To: t.petch > >> Cc: tcpm@ietf.org > >> Subject: Re: [tcpm] Aid passive estimate of tcp performance > >> > >> Hi Tom. > >> What you say was my original point. However I have been overwhelmed > by > >> the amount of drawbacks pointed out by the other folks. > >> My idea was to enable TCP to give a little report at the end of the > >> session. This report should be concise and simple. Just accounting > for > >> any interesting parameters that are either difficult or impossible > to > >> be obtained without an explicit procedure. I was thinking about the > >> estimate of the packet loss but I was hopping that other (more > expert > >> people) would find any other interesting usages. > >> However, as I said, I think there have been too much negative > feedback > >> on this idea so far. > >> > >> What does everyone think? > >> Should we give up with this issue? > >> > >> Thank you all. > >> > >> El 17/02/2012, a las 16:46, t.petch escribi=F3: > >> > >>> ----- Original Message ----- > >>> From: "=C1ngel Bartomeu Bonillo" > >>> To: "rick jones" > >>> Cc: > >>> Sent: Wednesday, February 08, 2012 6:52 PM > >>> Hi Rick, > >>> El 08/02/2012, a las 17:32, rick jones escribi=F3: > >>> > >>>> > >>>> On Feb 8, 2012, at 4:15 AM, =C1ngel Bartomeu Bonillo wrote: > >>>> > >>>>> Hello, > >>>>> > >>>>> I recently faced the problem of passively estimating the packet > >> loss of TCP > >>> connection. After a bit of investigating the literature I found > that > >> there are > >>> tens of papers addressing this issue but I couldn't find any > perfect > >> solution. > >>>>> Since this is an important issue for network operators I have > been > >> thinking > >>> that there would be a very easy solution by just making the two = TCP > >> connection > >>> end points to account for its sent segments and report it to the > >> other end point > >>> in the FIN segment. > >>>>> This approach could be used as well for other measurable > parameters > >> along the > >>> TCP session without the need for any other offline method and It > >> would be very > >>> helpful for detecting failures along networks. > >>>>> > >>>>> Any comments? > >>>> > >>>> If the count is reported in a FIN segment, isn't that rather like > >> closing the > >>> barn door after the horses have left? At least as far as doing > >> anything for > >>> that connection is concerned. So, already we are talking about > >> operating on > >>> timescales larger than connection lifetimes. And what would the > side > >> receiving > >>> the count-containing FIN do with this information? Sure, now it is > >> known on both > >>> ends, but the problem still lies somewhere in the middle (not > always, > >> but > >>> often). Is it expected that points along the middle will be > sniffing > >> this? > >>> What would they do in response? What could they (reasonably) do = in > >> response > >>> with that information just from TCP vs any other transports? > >>>> > >>> > >>> I'm talking about timescales larger than the connection lifetimes. > >> This would be > >>> a mechanism so TCP can report how many packets it sent out. If = both > >> ends send at > >>> the end of the session the number of packets they sent out the > other > >> peer and > >>> anyone in the middle would be able to estimate de loss in both > >> directions. > >>> > >>> The idea is to enable TCP so it can report a little but valuable > >> information > >>> about its performance once the connection finished. This is not a > >> mechanism so > >>> TCP can adapt to losses in the middle of a communication but = rather > a > >> long term > >>> mechanism for network operators and such. Nowadays many of the end > >> user services > >>> use TCP and the end to end packet loss is many times impossible to > >> calculate > >>> mainly because only the sending node knows the real number of > packets > >> sent out. > >>> For example in the uplink direction on a mobile network. > >>> I think that adding just a couple of bytes (as a TCP option) to = the > >> FIN segment > >>> would give a priceless information for network operators. > >>> > >>> > >>> Apologies for being late to the party but I think that it is a > lovely > >> idea. As > >>> has been pointed out, the figures that you would collect are not > what > >> you want, > >>> but they would be a lot closer than anything available at the > moment, > >> and that > >>> is engineering. Ditto comments about RST; if there is a positive > >> benefit to > >>> shutting down properly and getting these figures, then that could > >> discourage > >>> RSTs. > >>> > >>> Tom Petch > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>> When a sending TCP sends the first FIN with a count at the end of > a > >> MB window > >>> would it retransmit the FIN, even if the first was received, to > >> include > >>> retransmissions in that last window's-worth of data? How long > would > >> the > >>> receiving TCP wait for this "final tally, really" FIN to arrive > after > >> it sent > >>> the ACK to SEQfin to then pass-along the count to a higher layer, > >> somehow? > >>> > >>> The idea much simpler: the peer adds the num of packets sent = during > >> the > >>> connection as an option in the FIN. There is no need to change TCP > >> behavior. > >>> > >>>> > >>>> I think we are already asking for enough angels to dance on the > TCP > >>> pin-header. > >>>> > >>>> rick jones > >>> > >>> _______________________________________________ > >>> tcpm mailing list > >>> tcpm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/tcpm > >>> > >>> > >> > >> > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcpm >=20 From internet-drafts@ietf.org Fri Feb 24 14:20:04 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052A721F86E2; Fri, 24 Feb 2012 14:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuTVgdadpcvd; Fri, 24 Feb 2012 14:19:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1EB121F86D7; Fri, 24 Feb 2012 14:19:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120224221955.4514.3901.idtracker@ietfa.amsl.com> Date: Fri, 24 Feb 2012 14:19:55 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-proportional-rate-reduction-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 22:20:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions = Working Group of the IETF. Title : Proportional Rate Reduction for TCP Author(s) : Matt Mathis Nandita Dukkipati Yuchung Cheng Filename : draft-ietf-tcpm-proportional-rate-reduction-01.txt Pages : 16 Date : 2012-02-24 This document describes an experimental algorithm, Proportional Rate Reduction (PPR) to improve the accuracy of the amount of data sent by TCP during loss recovery. Standard Congestion Control requires that TCP and other protocols reduce their congestion window in response to losses. This window reduction naturally occurs in the same round trip as the data retransmissions to repair the losses, and is implemented by choosing not to transmit any data in response to some ACKs arriving from the receiver. Two widely deployed algorithms are used to implement this window reduction: Fast Recovery and Rate Halving. Both algorithms are needlessly fragile under a number of conditions, particularly when there is a burst of losses that such that the number of ACKs returning to the sender is small. Proportional Rate Reduction minimizes these excess window reductions such that at the end of recovery the actual window size will be as close as possible to ssthresh, the window size determined by the congestion control algorithm. It is patterned after Rate Halving, but using the fraction that is appropriate for target window chosen by the congestion control algorithm. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-proportional-rate-reduc= tion-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-proportional-rate-reduct= ion-01.txt From internet-drafts@ietf.org Sun Feb 26 23:43:55 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6933821E8024; Sun, 26 Feb 2012 23:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.987 X-Spam-Level: X-Spam-Status: No, score=-101.987 tagged_above=-999 required=5 tests=[AWL=0.612, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbC03BOpcZjY; Sun, 26 Feb 2012 23:43:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B96C021E8019; Sun, 26 Feb 2012 23:43:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120227074354.5641.18911.idtracker@ietfa.amsl.com> Date: Sun, 26 Feb 2012 23:43:54 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-initcwnd-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 07:43:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions = Working Group of the IETF. Title : Increasing TCP's Initial Window Author(s) : Jerry Chu Nandita Dukkipati Yuchung Cheng Matt Mathis Filename : draft-ietf-tcpm-initcwnd-03.txt Pages : 22 Date : 2012-02-26 This document proposes an increase in the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments. It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large scale experiments showing that the higher initial window improves the overall performance of many web services without risking congestion collapse. The document closes with a discussion of usage and deployment recommended by the IETF TCP Maintenance and Minor Extensions (TCPM) working group. Terminology A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-initcwnd-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-initcwnd-03.txt From lars@netapp.com Mon Feb 27 01:08:32 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B22221F8593 for ; Mon, 27 Feb 2012 01:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.358 X-Spam-Level: X-Spam-Status: No, score=-10.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xd9-zG3aFZkC for ; Mon, 27 Feb 2012 01:08:30 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7F20C21F85A5 for ; Mon, 27 Feb 2012 01:08:30 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.73,490,1325491200"; d="p7s'?scan'208";a="628793858" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 27 Feb 2012 01:08:30 -0800 Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q1R97eUA014499 for ; Mon, 27 Feb 2012 01:08:30 -0800 (PST) Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.92]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0247.003; Mon, 27 Feb 2012 01:07:30 -0800 From: "Eggert, Lars" To: "tcpm@ietf.org" Thread-Topic: draft-williams-overlaypath-ip-tcp-rfc-00.txt Thread-Index: AQHM9S8zv91hMp41AEmyjRMGO2/pjw== Date: Mon, 27 Feb 2012 09:07:15 +0000 Message-ID: <8BB2A0BC-A2AC-4CC9-8BB8-4C890A191C51@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_1EA06320-6279-453F-9332-7D9AA2BAAE1E"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [tcpm] draft-williams-overlaypath-ip-tcp-rfc-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 09:08:32 -0000 --Apple-Mail=_1EA06320-6279-453F-9332-7D9AA2BAAE1E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, from draft-williams-overlaypath-ip-tcp-rfc-00.txt: > 8. IANA Considerations >=20 > The assignment of numbers 26 for IPv4, 11 for IPv6, and 30 for TCP > are provisional pending official IANA approval. The Type values > could change if IANA assigns different numbers. >=20 > It may be important to note that some early implementations of this > specification use TCP option numbers 28 and 29 due to the fact that > these numbers were available at the time of the implementation. > These early implementations will require updates after an official > option number has been assigned. We should instruct IANA to indicate in the options number registry that = options 28 (TCP-UTO) and 29 (TCP-AO) have also been inappropriately used = for other then the assigned TCP extensions. (This is esp. unfortunate for AO! We had the clash on 253/254, and now = we have another one. Sigh.) Lars= --Apple-Mail=_1EA06320-6279-453F-9332-7D9AA2BAAE1E Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDIyNzA5MDcxNVowIwYJKoZIhvcNAQkEMRYEFC4X WIq8EHU8Dq/FwCMgmFP4hfy/MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAExUhRGU fL7EkJRP9q5mB29zZ0ji3kuTmCdRKPdk7M9QL6/+j4UffLjwsiP4qiKKUeyC2zrG9zzEdk6Zp3ja tuABsPOFpR/d6i1g1BNiyV5hnKF2a8u/4cCSGJECJ3lijmNj8R9g4/LUiTfJenvOENhYw/RXrpOT pwOvm8QZ65v1F0J0regJfQsm/jHT4J4r7mFtnpleBKejpgVoq38ww0bV9Pra7mmiJ1kW9hWdCGH6 m+F6tCwkObRDRXuVAJznvSqxhXXh4FNnpw3mfdJmkFIx+lsPIeGrb6IKKJRbwSqNhDpcWPGdhxkM s0Ae2y/RqwYt0uPWk5Em6Ux5tyk9WdkAAAAAAAA= --Apple-Mail=_1EA06320-6279-453F-9332-7D9AA2BAAE1E-- From pasi.sarolahti@iki.fi Mon Feb 27 05:53:39 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCDC921F86FD for ; Mon, 27 Feb 2012 05:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.028 X-Spam-Level: X-Spam-Status: No, score=-106.028 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-5ZUOWOHfTp for ; Mon, 27 Feb 2012 05:53:39 -0800 (PST) Received: from smtp-3.hut.fi (smtp-3.hut.fi [130.233.228.93]) by ietfa.amsl.com (Postfix) with ESMTP id 2430221F8687 for ; Mon, 27 Feb 2012 05:53:38 -0800 (PST) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-3.hut.fi (8.13.6/8.12.10) with ESMTP id q1RDrbUm003245 for ; Mon, 27 Feb 2012 15:53:37 +0200 Received: from smtp-3.hut.fi ([130.233.228.93]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 06008-971 for ; Mon, 27 Feb 2012 15:53:37 +0200 (EET) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-3.hut.fi (8.13.6/8.12.10) with ESMTP id q1RDrSLY003221 for ; Mon, 27 Feb 2012 15:53:28 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 6B5D01E136 for ; Mon, 27 Feb 2012 15:53:28 +0200 (EET) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xT8yxK2NFmtg for ; Mon, 27 Feb 2012 15:53:24 +0200 (EET) Received: from [192.168.1.65] (dsl-hkibrasgw4-fe5cdf00-46.dhcp.inet.fi [80.223.92.46]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id 54DF71E134 for ; Mon, 27 Feb 2012 15:53:24 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Pasi Sarolahti In-Reply-To: <7807_1328706092_4F32722B_7807_3_1_263ACA35-149C-4896-8FFE-69CB7E096626@iki.fi> Date: Mon, 27 Feb 2012 15:53:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <97BCEFD0-530B-4229-9192-B563B8C89A55@iki.fi> References: <7807_1328706092_4F32722B_7807_3_1_263ACA35-149C-4896-8FFE-69CB7E096626@iki.fi> To: tcpm@ietf.org X-Mailer: Apple Mail (2.1257) X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-3517bis-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 13:53:40 -0000 Hi, The working group last call has now ended. During the WGLC there was one = comment from Richard (thanks!), who supported the draft, and no requests = for changes. We will therefore pass the draft forward to ADs for = publication. - Pasi On Feb 8, 2012, at 3:01 PM, Pasi Sarolahti wrote: > Hello, >=20 > The authors of "A Conservative Selective Acknowledgment (SACK)-based = Loss Recovery Algorithm for TCP" (draft-ietf-tcpm-3517bis-01) think the = latest version addresses all comments made on the draft. Therefore, this = mail starts Working Group Last Call for the draft, intended to be = published as Proposed Standard. The WGLC ends on Friday, February 24, = i.e., within a bit over two weeks.=20 >=20 > Please read the draft and send any comments to the TCPM mailing list = by the above deadline. If you think the draft is ok and ready to be = published without further changes, indicating that would also be = helpful. >=20 > The draft is available at = http://tools.ietf.org/html/draft-ietf-tcpm-3517bis-01 >=20 > - Pasi >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From alexander.zimmermann@comsys.rwth-aachen.de Mon Feb 27 06:02:17 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4940521F86DB for ; Mon, 27 Feb 2012 06:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyNfgEQAoEXc for ; Mon, 27 Feb 2012 06:02:16 -0800 (PST) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2F89321F86DC for ; Mon, 27 Feb 2012 06:02:16 -0800 (PST) MIME-version: 1.0 Received: from mx-out-2.rwth-aachen.de ([134.130.5.187]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0M0200FVG1NQGLE0@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Mon, 27 Feb 2012 15:02:14 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.73,490,1325458800"; d="asc'?scan'208";a="79426163" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by mx-2.rz.rwth-aachen.de with ESMTP; Mon, 27 Feb 2012 15:02:15 +0100 Received: from [137.226.12.25] ([unknown] [137.226.12.25]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0M0200GOK1NQDP20@relay-auth-1.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Mon, 27 Feb 2012 15:02:14 +0100 (CET) Content-type: multipart/signed; boundary="Apple-Mail=_9686CAA5-EF1A-4FEF-A8EA-FB38922F592E"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Alexander Zimmermann In-reply-to: <97BCEFD0-530B-4229-9192-B563B8C89A55@iki.fi> Date: Mon, 27 Feb 2012 15:02:16 +0100 Message-id: <6B99F7F1-C5B4-4AFD-87BE-0263012D8BD6@comsys.rwth-aachen.de> References: <7807_1328706092_4F32722B_7807_3_1_263ACA35-149C-4896-8FFE-69CB7E096626@iki.fi> <97BCEFD0-530B-4229-9192-B563B8C89A55@iki.fi> To: Pasi Sarolahti X-Mailer: Apple Mail (2.1257) Cc: tcpm@ietf.org Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-3517bis-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 14:02:17 -0000 --Apple-Mail=_9686CAA5-EF1A-4FEF-A8EA-FB38922F592E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Pasi, I also support the doc. My comments are already incorporated in a = previous version of the draft. Alex Am 27.02.2012 um 14:53 schrieb Pasi Sarolahti: > Hi, >=20 > The working group last call has now ended. During the WGLC there was = one comment from Richard (thanks!), who supported the draft, and no = requests for changes. We will therefore pass the draft forward to ADs = for publication. >=20 > - Pasi >=20 >=20 > On Feb 8, 2012, at 3:01 PM, Pasi Sarolahti wrote: >=20 >> Hello, >>=20 >> The authors of "A Conservative Selective Acknowledgment (SACK)-based = Loss Recovery Algorithm for TCP" (draft-ietf-tcpm-3517bis-01) think the = latest version addresses all comments made on the draft. Therefore, this = mail starts Working Group Last Call for the draft, intended to be = published as Proposed Standard. The WGLC ends on Friday, February 24, = i.e., within a bit over two weeks.=20 >>=20 >> Please read the draft and send any comments to the TCPM mailing list = by the above deadline. If you think the draft is ok and ready to be = published without further changes, indicating that would also be = helpful. >>=20 >> The draft is available at = http://tools.ietf.org/html/draft-ietf-tcpm-3517bis-01 >>=20 >> - Pasi >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@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 // mobile: (49-176) 32820027, fax: (49-241) 80-22222 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // --Apple-Mail=_9686CAA5-EF1A-4FEF-A8EA-FB38922F592E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iEYEARECAAYFAk9LjOkACgkQdyiq39b9uS6OGgCdEjiI3/mSiX6iqMYwO9VrkZBa RPoAoJeebepAcfGJLpPM/gEs0EIKnL4v =C+lo -----END PGP SIGNATURE----- --Apple-Mail=_9686CAA5-EF1A-4FEF-A8EA-FB38922F592E-- From touch@isi.edu Mon Feb 27 09:55:33 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9BA21F87A2 for ; Mon, 27 Feb 2012 09:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.964 X-Spam-Level: X-Spam-Status: No, score=-102.964 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17u8YBuHojvz for ; Mon, 27 Feb 2012 09:55:32 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id CE30E21F879E for ; Mon, 27 Feb 2012 09:55:32 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q1RHt1KW006375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Feb 2012 09:55:01 -0800 (PST) Message-ID: <4F4BC375.4010500@isi.edu> Date: Mon, 27 Feb 2012 09:55:01 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: "Eggert, Lars" References: <8BB2A0BC-A2AC-4CC9-8BB8-4C890A191C51@netapp.com> In-Reply-To: <8BB2A0BC-A2AC-4CC9-8BB8-4C890A191C51@netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-williams-overlaypath-ip-tcp-rfc-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 17:55:33 -0000 Agreed. It's not an issue for AO, though - so long as 29 is interpreted as AO for compliant implementations, the keying should end up just dumping anyone else's segments that use 29 as "malformed" or incorrectly keyed. Joe On 2/27/2012 1:07 AM, Eggert, Lars wrote: > Hi, > > from draft-williams-overlaypath-ip-tcp-rfc-00.txt: > >> 8. IANA Considerations >> >> The assignment of numbers 26 for IPv4, 11 for IPv6, and 30 for TCP >> are provisional pending official IANA approval. The Type values >> could change if IANA assigns different numbers. >> >> It may be important to note that some early implementations of this >> specification use TCP option numbers 28 and 29 due to the fact that >> these numbers were available at the time of the implementation. >> These early implementations will require updates after an official >> option number has been assigned. > > We should instruct IANA to indicate in the options number registry that options 28 (TCP-UTO) and 29 (TCP-AO) have also been inappropriately used for other then the assigned TCP extensions. > > (This is esp. unfortunate for AO! We had the clash on 253/254, and now we have another one. Sigh.) > > Lars > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nishida@sfc.wide.ad.jp Tue Feb 28 12:14:56 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E0621E805B for ; Tue, 28 Feb 2012 12:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.474 X-Spam-Level: X-Spam-Status: No, score=-98.474 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaelEEhAId+y for ; Tue, 28 Feb 2012 12:14:56 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 3C44921E8051 for ; Tue, 28 Feb 2012 12:14:56 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 8C9BD2780B8 for ; Wed, 29 Feb 2012 05:14:52 +0900 (JST) Received: by eeke51 with SMTP id e51so1412104eek.31 for ; Tue, 28 Feb 2012 12:14:50 -0800 (PST) Received-SPF: pass (google.com: domain of nishida@sfc.wide.ad.jp designates 10.112.25.40 as permitted sender) client-ip=10.112.25.40; Authentication-Results: mr.google.com; spf=pass (google.com: domain of nishida@sfc.wide.ad.jp designates 10.112.25.40 as permitted sender) smtp.mail=nishida@sfc.wide.ad.jp Received: from mr.google.com ([10.112.25.40]) by 10.112.25.40 with SMTP id z8mr2402920lbf.11.1330460090078 (num_hops = 1); Tue, 28 Feb 2012 12:14:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.25.40 with SMTP id z8mr1963593lbf.11.1330460090061; Tue, 28 Feb 2012 12:14:50 -0800 (PST) Received: by 10.112.94.43 with HTTP; Tue, 28 Feb 2012 12:14:50 -0800 (PST) In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C06C80E75@SLFSNX.rcs.alcatel-research.de> References: <133D9897FB9C5E4E9DF2779DC91E947C06C80E75@SLFSNX.rcs.alcatel-research.de> Date: Tue, 28 Feb 2012 12:14:50 -0800 Message-ID: From: Yoshifumi Nishida To: "SCHARF, Michael" Content-Type: text/plain; charset=ISO-8859-1 Cc: tcpm@ietf.org, Joe Touch Subject: Re: [tcpm] Minimum nonce length in draft-touch-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 20:14:56 -0000 Hi, On Mon, Feb 20, 2012 at 3:34 AM, SCHARF, Michael wrote: > Joe, > > The wording on the nonce length in draft-touch-tcpm-experimental-options > may be a little bit unclear ("it MAY be as few as 16 bits if desired"). > > Does that statement intend to say something like "MUST NOT be shorter > than 16 bits long"? Or shall even a nonce of length 0 be allowed, > provided that there are additional security mechanism such as checksums > or digital signatures? In the latter case, existing use of the > codepoints without nonce could be compliant to the recommendation, > provided that there are other means to detect false positives. I don't have strong opinion on this yet, but I personally think we don't have to mention minimum length specifically in the draft. However, I might prefer to put a little bit more stress in this regards, like, o It's implementor's responsibility to find good balance between the overhead of magic number and the overhead to handle false positive. o the draft doesn't guarantee anything even if an implementor chooses longer magic number Thanks, -- Yoshifumi Nishida From pasi.sarolahti@iki.fi Wed Feb 29 12:08:34 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDB321E808A for ; Wed, 29 Feb 2012 12:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.291 X-Spam-Level: X-Spam-Status: No, score=-106.291 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oTY08WmNPab for ; Wed, 29 Feb 2012 12:08:33 -0800 (PST) Received: from smtp-1.hut.fi (smtp-1.hut.fi [130.233.228.91]) by ietfa.amsl.com (Postfix) with ESMTP id 39A6621E8087 for ; Wed, 29 Feb 2012 12:08:33 -0800 (PST) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id q1TK8Su7025087; Wed, 29 Feb 2012 22:08:28 +0200 Received: from smtp-1.hut.fi ([130.233.228.91]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 17069-1477; Wed, 29 Feb 2012 22:08:27 +0200 (EET) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id q1TK8NSU025083; Wed, 29 Feb 2012 22:08:23 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 5F78C1E136; Wed, 29 Feb 2012 22:08:23 +0200 (EET) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id b7tbzru0rBip; Wed, 29 Feb 2012 22:08:19 +0200 (EET) Received: from [192.168.1.65] (dsl-hkibrasgw4-fe5cdf00-46.dhcp.inet.fi [80.223.92.46]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id 9444E1E0B7; Wed, 29 Feb 2012 22:08:19 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Pasi Sarolahti In-Reply-To: <11225_1330460112_4F4D35D0_11225_4274_1_CAO249ycxh75VETJ6jYScpw-ChCi9As6x6x35RnXHKWY1TVEkYw@mail.gmail.com> Date: Wed, 29 Feb 2012 22:08:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7CC5FA62-2223-4003-BE21-F9E2F6120D96@iki.fi> References: <133D9897FB9C5E4E9DF2779DC91E947C06C80E75@SLFSNX.rcs.alcatel-research.de> <11225_1330460112_4F4D35D0_11225_4274_1_CAO249ycxh75VETJ6jYScpw-ChCi9As6x6x35RnXHKWY1TVEkYw@mail.gmail.com> To: Yoshifumi Nishida X-Mailer: Apple Mail (2.1257) X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Cc: tcpm@ietf.org, Joe Touch Subject: Re: [tcpm] Minimum nonce length in draft-touch-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 20:08:34 -0000 On Feb 28, 2012, at 10:14 PM, Yoshifumi Nishida wrote: >> Does that statement intend to say something like "MUST NOT be shorter >> than 16 bits long"? Or shall even a nonce of length 0 be allowed, >> provided that there are additional security mechanism such as = checksums >> or digital signatures? In the latter case, existing use of the >> codepoints without nonce could be compliant to the recommendation, >> provided that there are other means to detect false positives. >=20 > I don't have strong opinion on this yet, but I personally think we > don't have to mention minimum length specifically in the draft. > However, I might prefer to put a little bit more stress in this = regards, like, > o It's implementor's responsibility to find good balance between > the overhead of magic number and the overhead to handle false > positive. > o the draft doesn't guarantee anything even if an implementor > chooses longer magic number I agree. Given the scarcity of TCP option space, you do not want to use = any more space for the magic number than necessary. Maybe one possible = option could be to use a 32-bit magic number in the SYN handshake, to = declare that for the rest of that connection option types 253 and 254 = are used without magic number for feature X (or perhaps with a shorter = magic number, to allow simultaneous experimental features). This could = be useful when the option space is expected to get tight. - Pasi From Michael.Scharf@alcatel-lucent.com Wed Feb 29 12:29:41 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41CF721F8603 for ; Wed, 29 Feb 2012 12:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.173 X-Spam-Level: X-Spam-Status: No, score=-6.173 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRpGnJtS8JO7 for ; Wed, 29 Feb 2012 12:29:40 -0800 (PST) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id 831B021F85E0 for ; Wed, 29 Feb 2012 12:29:39 -0800 (PST) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id q1TKTXoZ020561; Wed, 29 Feb 2012 21:29:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Feb 2012 21:29:09 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C06E03465@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <7CC5FA62-2223-4003-BE21-F9E2F6120D96@iki.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Minimum nonce length in draft-touch-tcpm-experimental-options Thread-Index: Acz3He5lqq7N463XSXK9vd9IxFFkBQAAfDSg References: <133D9897FB9C5E4E9DF2779DC91E947C06C80E75@SLFSNX.rcs.alcatel-research.de> <11225_1330460112_4F4D35D0_11225_4274_1_CAO249ycxh75VETJ6jYScpw-ChCi9As6x6x35RnXHKWY1TVEkYw@mail.gmail.com> <7CC5FA62-2223-4003-BE21-F9E2F6120D96@iki.fi> From: "SCHARF, Michael" To: "Pasi Sarolahti" , "Yoshifumi Nishida" X-Scanned-By: MIMEDefang 2.69 on 149.204.45.73 Cc: tcpm@ietf.org, Joe Touch Subject: Re: [tcpm] Minimum nonce length in draft-touch-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 20:29:41 -0000 > >> Does that statement intend to say something like "MUST NOT=20 > be shorter=20 > >> than 16 bits long"? Or shall even a nonce of length 0 be allowed,=20 > >> provided that there are additional security mechanism such as=20 > >> checksums or digital signatures? In the latter case,=20 > existing use of=20 > >> the codepoints without nonce could be compliant to the=20 > >> recommendation, provided that there are other means to=20 > detect false positives. > >=20 > > I don't have strong opinion on this yet, but I personally think we=20 > > don't have to mention minimum length specifically in the draft. > > However, I might prefer to put a little bit more stress in=20 > this regards, like, > > o It's implementor's responsibility to find good balance=20 > between the=20 > > overhead of magic number and the overhead to handle false positive. > > o the draft doesn't guarantee anything even if an implementor=20 > > chooses longer magic number >=20 > I agree. Given the scarcity of TCP option space, you do not=20 > want to use any more space for the magic number than=20 > necessary. Maybe one possible option could be to use a 32-bit=20 > magic number in the SYN handshake, to declare that for the=20 > rest of that connection option types 253 and 254 are used=20 > without magic number for feature X (or perhaps with a shorter=20 > magic number, to allow simultaneous experimental features).=20 > This could be useful when the option space is expected to get tight. Option space is particularly scarce in SYNs. Afterwards one could try to piggyback a long option to an empty ACK instead. Thus, this only helps if a rather long option must indeed be present in a data segment, right? Michael From touch@isi.edu Wed Feb 29 13:15:36 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E0121F87B7 for ; Wed, 29 Feb 2012 13:15:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.959 X-Spam-Level: X-Spam-Status: No, score=-102.959 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8I-Y65veP2A8 for ; Wed, 29 Feb 2012 13:15:35 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 89F0E21F87B3 for ; Wed, 29 Feb 2012 13:15:35 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q1TLF67k007880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Feb 2012 13:15:06 -0800 (PST) Message-ID: <4F4E955A.9040405@isi.edu> Date: Wed, 29 Feb 2012 13:15:06 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "SCHARF, Michael" References: <133D9897FB9C5E4E9DF2779DC91E947C06C80E75@SLFSNX.rcs.alcatel-research.de> <11225_1330460112_4F4D35D0_11225_4274_1_CAO249ycxh75VETJ6jYScpw-ChCi9As6x6x35RnXHKWY1TVEkYw@mail.gmail.com> <7CC5FA62-2223-4003-BE21-F9E2F6120D96@iki.fi> <133D9897FB9C5E4E9DF2779DC91E947C06E03465@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C06E03465@SLFSNX.rcs.alcatel-research.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Minimum nonce length in draft-touch-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 21:15:36 -0000 On 2/29/2012 12:29 PM, SCHARF, Michael wrote: >>>> Does that statement intend to say something like "MUST NOT >> be shorter >>>> than 16 bits long"? Or shall even a nonce of length 0 be allowed, >>>> provided that there are additional security mechanism such as >>>> checksums or digital signatures? In the latter case, >> existing use of >>>> the codepoints without nonce could be compliant to the >>>> recommendation, provided that there are other means to >> detect false positives. >>> >>> I don't have strong opinion on this yet, but I personally think we >>> don't have to mention minimum length specifically in the draft. >>> However, I might prefer to put a little bit more stress in >> this regards, like, >>> o It's implementor's responsibility to find good balance >> between the >>> overhead of magic number and the overhead to handle false positive. >>> o the draft doesn't guarantee anything even if an implementor >>> chooses longer magic number >> >> I agree. Given the scarcity of TCP option space, you do not >> want to use any more space for the magic number than >> necessary. Maybe one possible option could be to use a 32-bit >> magic number in the SYN handshake, to declare that for the >> rest of that connection option types 253 and 254 are used >> without magic number for feature X (or perhaps with a shorter >> magic number, to allow simultaneous experimental features). >> This could be useful when the option space is expected to get tight. > > Option space is particularly scarce in SYNs. Afterwards one could try to > piggyback a long option to an empty ACK instead. Thus, this only helps > if a rather long option must indeed be present in a data segment, right? > > Michael There could be multiple instances of option 253 or 254, and the only way to know they're distinct is the magic number. Otherwise, any shortcut you use could conflict with someone else's. So there's no shortcut here; as you note, this isn't helping the more critical location (SYNs) anyway. Joe From mcmanus@ducksong.com Wed Feb 29 15:02:13 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3F121F8631 for ; Wed, 29 Feb 2012 15:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBTlXbnZpKMQ for ; Wed, 29 Feb 2012 15:02:12 -0800 (PST) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by ietfa.amsl.com (Postfix) with ESMTP id 80E9F21F8630 for ; Wed, 29 Feb 2012 15:02:12 -0800 (PST) Received: by linode.ducksong.com (Postfix, from userid 1000) id 1F0B8101B5; Wed, 29 Feb 2012 18:02:25 -0500 (EST) Received: from [192.168.16.226] (cpe-74-78-161-41.twcny.res.rr.com [74.78.161.41]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 9CF82101B6 for ; Wed, 29 Feb 2012 18:02:15 -0500 (EST) From: Patrick McManus To: "tcpm@ietf.org" In-Reply-To: <20120209033156.05B9971E4BE@lawyers.icir.org> References: <20120209033156.05B9971E4BE@lawyers.icir.org> Content-Type: text/plain; charset="UTF-8" Date: Wed, 29 Feb 2012 18:01:51 -0500 Message-ID: <1330556511.2182.373.camel@ds9> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] TCP and applications [was Re: Aid passive estimate of tcp performance] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 23:02:13 -0000 On Wed, 2012-02-08 at 22:31 -0500, Mark Allman wrote: > > Can't agree more. We need a venue for two-way communications. > > > > app dev: TCP sucks because blah blah blah > > TCP dudes: app sucks because blah blah blah > > Wellllll..... that is one reason everyone rearranges all the furniture > in a big damn hotel three times a year. But, alas, you can lead a horse > to water ... [Apologies for appending to an old thread. I read tcpm in batches every few weeks.] Hi all. I develop network gunk for firefox - if you think there is something we could be doing to make the web more capable, more open, and more awesome please reach out to me. A few of you have worked on some topic with me in the past, and I like to think we're both better for it. I'm a reasonable guy who loves to talk about these interactions and what is realistic to do about them. My counterparts at other browsers, at least the ones I know, are good people too - all trying to make a better Internet while balancing many needs and constraints. So that's something concrete for you - a person to engage. I'll be in Paris too. BTW - I'm not trying to just throw this over the wall and say "call me if you need me", I think tcpm is part of my community and try and keep up and contribute. My community is just a big world (from HTML5 to ethernet), so stuff slips through and the needs may not necessarily align. Congenially, Patrick aka pmcmanus@mozilla.com