Subject: Re: [tcpm] draft-ietf-tcpm-1323bis-14.txt

From: Pasi Sarolahti <[email-masked]>
Date: Sun, 21 Jul 2013 23:39:38 +0300

Lots of mails have been exchanged on this since the WGLC, but here is an attempt to shortly summarize the main points:

* Mark Allman made a thorough set of comments during the WGLC. My understanding is that these comments are now addressed. Some paragraphs have changed quite a bit as a result, so it would be good if people can check if the current text looks good.

* After the WGLC there was an update on the text regarding handling of segments without timestamp option after they have been successfully negotiated (MUST drop in ver-14), and a follow-up discussion about possible interactions with middleboxes. In a recent mail Richard proposes changing this to SHOULD. This change is not yet visible in the I-D repository.

If I'm forgetting something important, please remind me (and the list).

I think in the meeting we should go through the main recent changes, and check if people are ok with the current wordings. Additional comments on the list are much appreciated.

- Pasi

On Jul 16, 2013, at 2:03 PM, "Scheffenegger, Richard" <[email-masked]> wrote:

> Hi,
> 
> I would like to take this opportunity to stir up the recent discussions (from April/May timeframe) again.
> 
> There have been some comments past the posting of this version on the list, which I wasn't able to fully qualify how they would impact this latest text.
> 
> I would like to encourage the participants in these discussions to review the latest version, and point out if they cannot agree with any of the wording.
> 
> 
> 
> There will probably be a slot at the upcoming IETF to try to find out what the consensus is on this document, too...
> 
> Best regards,
> 
> Richard Scheffenegger
> 
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> Sent: Donnerstag, 23. Mai 2013 16:10
>> To: Bob Braden; Scheffenegger, Richard; Robert T. Braden; David Borman;
>> Van Jacobson
>> Subject: New Version Notification for draft-ietf-tcpm-1323bis-14.txt
>> 
>> 
>> A new version of I-D, draft-ietf-tcpm-1323bis-14.txt has been successfully
>> submitted by David Borman and posted to the IETF repository.
>> 
>> Filename:	 draft-ietf-tcpm-1323bis
>> Revision:	 14
>> Title:		 TCP Extensions for High Performance
>> Creation date:	 2013-05-23
>> Group:		 tcpm
>> Number of pages: 46
>> URL:             http://www.ietf.org/internet-drafts/draft-ietf-tcpm-
>> 1323bis-14.txt
>> Status:          http://datatracker.ietf.org/doc/draft-ietf-tcpm-1323bis
>> Htmlized:        http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-14
>> Diff:            http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-1323bis-
>> 14
>> 
>> Abstract:
>>   This document specifies a set of TCP extensions to improve
>>   performance over paths with a large bandwidth * delay product and to
>>   provide reliable operation over very high-speed paths.  It defines
>>   TCP options for scaled windows and timestamps.  The timestamps are
>>   used for two distinct mechanisms, RTTM (Round Trip Time Measurement)
>>   and PAWS (Protection Against Wrapped Sequences).
>> 
>>   This document updates and obsoletes RFC 1323.
>> 
>> 
>> 
>> 
>> The IETF Secretariat
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 29 Jul 2013 13:12:21 +0200

I only reviewed section 3 and it looks good to me.

Some minor suggestions on wordings.
1.    RTTM Rule: A TSecr value received in a segment MAY be used to update
              the averaged RTT measurement only if the segment advances
              the left edge of the send window, i.e.  SND.UNA is
              increased.
s/segment/ACK

2. "An <ACK> for an out-of-order segment
        SHOULD therefore contain the timestamp from the most recent
        segment that advanced the window."
s/advanced the window/advanced RCV.NXT

FWIW Linux recently changed to only use TS for RTTM if normal timings
aren't available. It now also measure RTT on new SACK for better RTO
during loss recovery
http://patchwork.ozlabs.org/patch/260836/
http://patchwork.ozlabs.org/patch/260838/
http://patchwork.ozlabs.org/patch/260837/