Subject: [tcpm] confirm adoption of 2988bis document

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Thu, 16 Sep 2010 22:21:47 -0500

David and I want to confirm that the working group has consensus to take the 2988bis document as a working group item:
http://tools.ietf.org/html/draft-paxson-tcpm-rfc2988bis-00

Based on past mailing list and meeting discussion, we think there is sufficient interest and little or no resistance to this.  Please let us know in the next 2 weeks if anyone disagrees with bringing this in as a working group item, prior to October 1.

Two related questions that have come up around this draft (but not within it), which can be discussed without impacting the adoption decision are:

- whether to fold draft-ychen-tcpm-rtosynrtt-00 into this document
- whether to fold reduction of the minRTO into this document

There has been some discussion on both questions in the past, but it doesn't seem to have had critical mass or clearly converged.

---

From: Mark Allman <[email-masked]>
Date: Wed, 22 Sep 2010 16:17:21 -0400

Well, I think it ought to be adopted.  But, you knew that! :)

BTW, we should soon (for some definition of soon) have some new
measurement results that are broader than the Google data currently in
the draft.  We'll roll that into an appendix and issue a new I-D.

> Two related questions that have come up around this draft (but not
> within it), which can be discussed without impacting the adoption
> decision are: 
> 
> There has been some discussion on both questions in the past, but it
> doesn't seem to have had critical mass or clearly converged. 

I think these questions are moot.  I'll take them out of order:

  - minRTO: We haven't seen any sensible proposal to change this with
    any sort of evidence about the pros and cons.  So, I personally
    would like to (a) see a concrete proposal before we worried about
    this in any way and (b) in no way hold up the modest (and I think
    agreed upon) changes in this document while thinking about a new
    min.

  - Given that the minRTO is 1sec and we're reducing the initRTO to 1sec
    then the rtosynrtt draft becomes a no-op.  I.e., it doesn't much
    matter if you take an RTT sample during the handshake or not because
    regardless you end up at the same place.  Further, 2988 and 2988bis
    both *permit* an RTT sample to be taken during the 3WHS (and do not
    comment on whether it should or should not be done).  So, it isn't
    even clear to me what it means to "fold in" this document.  (The
    prohibition on taking a sample during the 3WHS comes from the larger
    initial window documents, which argue that is a special case and
    that is why the sample is prohibited.  My view is if we want to
    change this special case then we do it there and not here.)

allman

---

From: Yuchung Cheng <[email-masked]>
Date: Wed, 22 Sep 2010 14:01:30 -0700

I agree Mark's points on MinRTO and RTO seeding. Until min RTO decreases,
the RTO seeding offers marginal latency benefit and I am fine dropping the
I-D.

On Wed, Sep 22, 2010 at 1:17 PM, Mark Allman <[email-masked]> wrote:

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>
>

---

From: Alexander Zimmermann <[email-masked]>
Date: Thu, 23 Sep 2010 09:34:26 +0200

I think Mark gave us a good summary of the discussion
of the last few month. So , I agree with his points.

Alex

>    change this special case then we do it there and not here.)

//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: (49-241) 80-22222
// email: [email-masked]
// web: http://www.umic-mesh.net
//