Re: [tcpm] poll for adoption of long connectivity disruptions draft

Pasi Sarolahti <pasi.sarolahti@iki.fi> Fri, 11 September 2009 07:11 UTC

Return-Path: <pasi.sarolahti@iki.fi>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BBF83A68D6 for <tcpm@core3.amsl.com>; Fri, 11 Sep 2009 00:11:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbKi-SVa6brj for <tcpm@core3.amsl.com>; Fri, 11 Sep 2009 00:11:27 -0700 (PDT)
Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 4B2CA3A67A7 for <tcpm@ietf.org>; Fri, 11 Sep 2009 00:11:27 -0700 (PDT)
Received: from [192.168.1.66] (adsl-99-169-83-39.dsl.pltn13.sbcglobal.net [99.169.83.39]) by argo.otaverkko.fi (Postfix) with ESMTP id 2DEBE25ED11; Fri, 11 Sep 2009 10:12:01 +0300 (EEST)
Message-Id: <E17BCE32-E1CA-44A6-80F8-2ABFA2C7A11A@iki.fi>
From: Pasi Sarolahti <pasi.sarolahti@iki.fi>
To: Alexander Zimmermann <alexander.zimmermann@nets.rwth-aachen.de>
In-Reply-To: <5D7CC3AE-684A-4E25-9325-318700E30B5F@nets.rwth-aachen.de>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 11 Sep 2009 00:11:58 -0700
References: <C304DB494AC0C04C87C6A6E2FF5603DB479B8A30CD@NDJSSCC01.ndc.nasa.gov> <EBDBFEBB-F697-49A4-A665-DC06F3916CB6@iki.fi> <5D7CC3AE-684A-4E25-9325-318700E30B5F@nets.rwth-aachen.de>
X-Mailer: Apple Mail (2.936)
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpm] poll for adoption of long connectivity disruptions draft
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Sep 2009 07:11:28 -0000

On Sep 9, 2009, at 6:42 AM, Alexander Zimmermann wrote:

>> * The title would benefit from some tweaking. Maybe its just a matter
>> of changing "Make" => "Making"
>
> Ok, we will change the title to "Making TCP more Robust to Long
> Connectivity
> Disruptions". I'm also fine with changing it to something completely
> different,
> are there any suggestions?

No. I think "Making TCP..." is just fine.

>>
>> * Section 4.2, algorithm: this is really a nit, but might want to
>> clarify in step (5) that if ICMP DU contains non-TCP header it should
>> be ignored, without affecting the algorithm (right?)
>
> In our algorithm we assume that the ICMP error message is passed
> up from the IP layer, for the corresponding connection.
> (See RFC 1122 Section 4.2.3.9 ). Ack, we will make this more clear.
> However, I think the fact that the ICMP message already got
> demultiplexed implies that the ICMP DU contains a TCP header,  
> otherwise
> we would "not see" this ICMP DU at this layer.

You are right, but I guess details might depend on implementation. And  
there might be possibilities for further optimization with non-TCP  
generated ICMPs, as per Joe's earlier mail.

>> * It would be interesting to have an accompanying technical report on
>> some (even preliminary) results on the performance improvements using
>> the algorithm. It would also be interesting to have some  
>> understanding
>> how often ICMP Destination unreachables actually arrive in case of a
>> real connectivity disruption in real world.
>
> Depends on what you mean with "real world" we have already presented
> some measurements with Linux routers, see the slides from the last
> IETF meetings. And the ICMP DU arrive surprisingly reliable.
> However, we did not test juniper or cisco yet...

Yep, the graphs in the meeting slides are nice. As an optional further  
step (if someone had the time) they could be wrapped with some  
explanatory text into a paper format to be used as a reference for  
people trying to assess the benefits.

Regarding "real world", I had something like today's 3G & WiFi  
networks in mind.

- Pasi