Re: [tcpm] Review: draft-ietf-tcpm-early-rexmt-01

Joe Touch <touch@ISI.EDU> Wed, 23 September 2009 15:11 UTC

Return-Path: <touch@ISI.EDU>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A5FB43A6967 for <>; Wed, 23 Sep 2009 08:11:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fNOqR6WoG4QO for <>; Wed, 23 Sep 2009 08:11:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B7E5C3A68AA for <>; Wed, 23 Sep 2009 08:11:35 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id n8NFBCx9012187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 Sep 2009 08:11:18 -0700 (PDT)
Message-ID: <>
Date: Wed, 23 Sep 2009 08:11:12 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20090812)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: n8NFBCx9012187
X-ISI-4-69-MailScanner: Found to be clean
Subject: Re: [tcpm] Review: draft-ietf-tcpm-early-rexmt-01
X-Mailman-Version: 2.1.9
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, 23 Sep 2009 15:11:36 -0000

Hash: SHA1

Mark Allman wrote:
> Joe-
> Thanks for the followup.  I am taking most of this as "Joe would have
> done it differently" and not as show-stoppers.  Please yell if this is
> not the case.

Just suggestions on clarifications that might be useful. No
show-stoppers. I think most of these can be addressed with brief bits of

see below...

> But, in particular,
>>> There is no "FR_thresh" sort of variable defined in RFC5681.  So, while
>>> I understand sort of what you are saying I think this ...
>>>     When the above two conditions hold and a TCP connection does not
>>>     support SACK the duplicate ACK threshold used to trigger a
>>>     retransmission MUST be reduced to:
>>> is clear about how one goes about using the threshold.  (This is an
>>> example ... there are other places with the same text.)
>> It's simpler than that - you have a variable called ER_thresh. You don't
>> define it. You explain what values to set it to, but you never use it to
>> do anything.
>> I.e., you have an undefined variable that you set, but don't declare and
>> never use.
> a *program* we didn't write. :-)

Well, you wrote the lines that *set* the variable ;-))

> I think it is clear from the text what is going on here.  I.e., that
> "the duplicate ACK threshold used to trigger a retransmission MUST be
> reduced to: ER_thresh" is perfectly clear.

OK, so I missed this. It might be useful to make it more clear, e.g.,

	dupack_thresh = ER_thresh

(or whatever the dupack threshold variable name is)

> (ER_thresh is used in the text and so removing it as spurious is not the
> simple answer.)

I don't want to remove it. I just want to be more clear about using it.

>> Nagle is on by default. Your example should be very clear about the
>> fact that you expect the default to be overridden, or should include
>> Nagle IMO.
>> I don't think you need many different cases, but if this works much
>> better with Nagle off, then the doc needs a bit of explanation on
>> this.
> It's not a question or working better or worse with Nagle on or off.
> The examples are *illustrations* (advertised as such) of how a trivial
> estimation of the number of outstanding segments based on the number of
> bytes outstanding can be wrong (in both directions).  It is not meant to
> be any deeper than that.  It does not need to be complicated by
> extraneous details.

Can you just state that, i.e., "Nagle is off to simplify the example"?

>>>> Other considerations: seems like you're making TCP send more
>>>> segments into the net when data is being lost, vs. the existing
>>>> mechanisms. If that's the case, and if loss is due to buffer
>>>> overload, are you making things potentially worse? If not, please
>>>> explain.
>>> I don't understand this point.  Is it relative to ER or [Bal98]?
>> Relative to not doing ER.
> In that case I think you're wrong.  In the case of actual loss that loss
> is going to be repaired with a retransmit.  We send that retransmit at a
> different point than the existing mechanism (which would wait for the
> RTO to resend the exact same packet).  So, we are not sending more
> segments into the network.

I'm just suggesting it would be useful to include that answer. I didn't
know what it was, just that it wasn't addressed.

> I suppose that one could argue that by sending the segment sooner than
> the RTO we are perhaps not giving the congestion as much of a chance to
> clear from the router buffers.  But, that's a pretty thin argument given
> that fast retransmit does roughly the same thing and the network has not
> melted down because of it.  I'd rather just leave this as part of the
> experiment that would need to be done to put this on the standards track"

OK to also say "and this is expected to be confirmed by experiments".

> In the case of reordering (no actual loss; not the case you bring up
> above) then, yes, ER does inject more segments than necessary into the
> network.  That is shown in the appendix.  Also, that doesn't worry me as
> much because we are not sending those extra segments into obviously
> congested networks.

I'm not particularly worried, just asking that the issue be addressed  -
even briefly.

Version: GnuPG v1.4.9 (MingW32)