Re: [tcpm] poll for adoption of long connectivity disruptions draft
Pasi Sarolahti <pasi.sarolahti@iki.fi> Tue, 08 September 2009 19:53 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 67C5228C2E7 for <tcpm@core3.amsl.com>; Tue, 8 Sep 2009 12:53:11 -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 wqU27Z05QXm5 for <tcpm@core3.amsl.com>; Tue, 8 Sep 2009 12:53:10 -0700 (PDT)
Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 217B828C1AB for <tcpm@ietf.org>; Tue, 8 Sep 2009 12:53:09 -0700 (PDT)
Received: from wifi140.icsi.berkeley.edu (wifi140.icsi.berkeley.edu [192.150.187.140]) by argo.otaverkko.fi (Postfix) with ESMTP id CFF2A25ED10; Tue, 8 Sep 2009 22:53:38 +0300 (EEST)
Message-Id: <EBDBFEBB-F697-49A4-A665-DC06F3916CB6@iki.fi>
From: Pasi Sarolahti <pasi.sarolahti@iki.fi>
To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov>
In-Reply-To: <C304DB494AC0C04C87C6A6E2FF5603DB479B8A30CD@NDJSSCC01.ndc.nasa.gov>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Tue, 08 Sep 2009 12:53:36 -0700
References: <C304DB494AC0C04C87C6A6E2FF5603DB479B8A30CD@NDJSSCC01.ndc.nasa.gov>
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: Tue, 08 Sep 2009 19:53:11 -0000
Hi, I just read the LCD draft. Technically it looks good, and I think it would be ok for the TCPM start working on this as a WG item for Experimental RFC. Generally, I wonder if some kind of holistic overview of the documented TCP enhancements would be in place at some point. In the recent years quite a few of these have been introduced, that each help in a specific problem in some communication environments, but might not be so important for others. It might be useful to check that there are no unwanted interactions between the different schemes, or whether from the documents it is clear to the implementors how to implement RFCs A + B + C in a coherent manner with minimal additional implementation complexity. Then, some high-level comments on LCD draft: * The title would benefit from some tweaking. Maybe its just a matter of changing "Make" => "Making" * It might we worth noting in Section 3 when discussing ICMP message content that it assumes that the IP payload is not encrypted by IPsec. Probably other forms of tunneling might cause problems for ICMP, too. * 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?) * 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. * Section 4.3, second paragraph says that with this algorithm "it has been proved that the retransmission was not lost due to congestion". This is a little questionable claim. I believe the algorithm is safe enough in congestion control aspects, but I'm not convinced that successful termination of the algorithm proves there is no congestion. So some rewording might be in place here. * Section 4.4: "TCP sender MAY use the following algorithm...." -- I believe something is missing here. There is no algorithm in this 3- line section. * You might consider if you just want to normatively refer directly RFC 1323 instead of the 1323bis draft. Is there something that has changed in 1323bis that is relevant for this document? (sometimes normative references to work-in-progress drafts have caused additional delays in the RFC ed queue, although I don't think that is much of a risk here) I will send some additional detailed nits directly to the authors. - Pasi On Sep 1, 2009, at 12:27 PM, Eddy, Wesley M. (GRC-MS00)[Verizon] wrote: > Hello, the authors of the "Long Connectivity Disruptions" draft: > http://www.ietf.org/internet-drafts/draft-zimmermann-tcp-lcd-02.txt > have given a couple presentations to the WG now and asked if it > could be considered as an item for the WG for Experimental. If > I'm not mistaken, there has been some positive feedback on the > most recent incarnation, though not a lot, and not really any > negative feedback that I could see. > > As chairs, David and I are asking the WG to voice whether we should: > > A) adopt this as a WG item for Experimental > B) NOT adopt this as a WG item > C) wait to decide (not ready) > > Please let us know what you think. > > --------------------------- > Wes Eddy > Network & Systems Architect > Verizon FNS / NASA GRC > Office: (216) 433-6682 > --------------------------- > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm
- [tcpm] poll for adoption of long connectivity dis… Eddy, Wesley M. (GRC-MS00)[Verizon]
- Re: [tcpm] poll for adoption of long connectivity… Pasi Sarolahti
- Re: [tcpm] poll for adoption of long connectivity… Joe Touch
- Re: [tcpm] poll for adoption of long connectivity… Joe Touch
- Re: [tcpm] poll for adoption of long connectivity… Alexander Zimmermann
- Re: [tcpm] poll for adoption of long connectivity… Alexander Zimmermann
- Re: [tcpm] poll for adoption of long connectivity… Joe Touch
- Re: [tcpm] poll for adoption of long connectivity… Pasi Sarolahti
- Re: [tcpm] poll for adoption of long connectivity… Alexander Zimmermann
- Re: [tcpm] poll for adoption of long connectivity… Joe Touch
- Re: [tcpm] poll for adoption of long connectivity… Eddy, Wesley M. (GRC-MS00)[Verizon]