Re: [tcpm] some questions related to PAWS

Joe Touch <touch@isi.edu> Mon, 03 June 2013 17:37 UTC

Return-Path: <touch@isi.edu>
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 F288521F8B07 for <tcpm@ietfa.amsl.com>; Mon, 3 Jun 2013 10:37:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 BU1k95WRqq6f for <tcpm@ietfa.amsl.com>; Mon, 3 Jun 2013 10:36:55 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3C08021F8E37 for <tcpm@ietf.org>; Mon, 3 Jun 2013 10:30:32 -0700 (PDT)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r53HTp6J023238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Jun 2013 10:29:51 -0700 (PDT)
Message-ID: <51ACD28A.4000507@isi.edu>
Date: Mon, 03 Jun 2013 10:29:46 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
References: <CAO249yfdHnz0vd2rBQXpQ4RJqo2R09r0X7_-b03fkMC_csV=Yw@mail.gmail.com>
In-Reply-To: <CAO249yfdHnz0vd2rBQXpQ4RJqo2R09r0X7_-b03fkMC_csV=Yw@mail.gmail.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" <tcpm@ietf.org>
Subject: Re: [tcpm] some questions related to PAWS
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 03 Jun 2013 17:37:10 -0000

On 6/2/2013 7:02 AM, Yoshifumi Nishida wrote:
> Hi,
> I start wondering the following points on PAWS.
> Please let me know if I miss something.
>
> 1: Do we always need PAWS check?
>      If TCP uses enough length of MSL and it hasn't sent 2**32 data
> yet,  I personally don't see strong reason to drop the packet without
> TS-opt.
>
>     Also,  when TCP has sent more than 2**32 data and if it has good
> knowledge that more than MSL time has passed since a packet with the
> seqno has sent, do we really need to perform PAWS check?

The trouble is that we don't have a way to say "use TSopt to measure 
RTT" vs. "use TSopt for PAWS".

Right now, AFAICT it means "use TSopt for PAWS and to measure RTT".

However, sending more than 4GB isn't as absurd or exceptional as it used 
to be, and lots of devices do lots of things with TCP packets that keep 
them around a while. It'd be nice if "MSL" was relevant here, but 
without TSopt, AFAICT MSL isn't involved except voluntarily at the 
source; if a source wants to send more than 4GB in 2 minutes (a transfer 
rate over 267Mbps, which is easy even on a laptop), then it can, will, 
and *does*.

> 2: Do we always need to enable both RTTM and PAWS when TS is negotiated?
>      I'm wondering there might be cases where sender only wants RTTM or PAWS.
>     Since the sender's choice doesn't affect the receiver's logic,
> implementing a simple parameter at the sender might be enough for
> this. Or, does it cause serious problems?

I'm not sure how to do that (see above).

> 3: Action for ACK without TS-opt
>      I'm guessing we don't need to send an ACK for the last in-sequence
> segment when a packet without TS-opt is ACK. But, I think the draft is
> not very clear on this point.

It should be more clear; IMO, all segments in a TSopt-negotiated session 
without TSopt should be silently ignored, but that's me ;-)

Joe