Subject: [tcpm] new rev of rto-consider posted

From: Mark Allman <[email-masked]>
Date: Tue, 01 Dec 2015 22:53:27 -0500

I posted rev -03 of the rto-consider I-D.  It addresses two basic
bits of feedback I received about the last version:

  - It tries to better state the goals and non-goals in the intro.

  - I re-framed things in terms of "latency" and "feedback time"
    instead of RTT, which is mis-leading.  There is a sketch of why
    RTT is mis-leading and we prefer feedback time.  (E.g., because
    we want to retransmit based on the expected time to get an ACK.
    That may have some non-network latency in it and so using the
    term "RTT" can be confusing.)

You can snag draft-allman-tcpm-rto-consider-03.txt from the usual
places or from: 

    http://www.icir.org/mallman/pubs/All15a/

Faber said WGLC.  I am not sure if a WG chair emeritus can call for
that, but what the hell ... vote early and vote often. :-)

allman

---

From: Jonathan Looney <[email-masked]>
Date: Tue, 8 Dec 2015 12:09:37 +0000

>    http://www.icir.org/mallman/pubs/All15a/

Hi Mark,

I'm fairly new to paying attention to the working group's mailing list, so
I've been fairly silent as I watch the WG work. However, I did want to
comment on your proposal.

I am supportive of your proposal. It summarizes principles of handling
retransmission timeouts which are of general applicability even beyond
TCP. For that reason alone, I think it would be a useful document for the
wider community to have for their consideration. (Beyond that, it always
helpful to have a quick reference of the big picture when we begin to
debate changes to the details.)

I hope the WG will consider adopting the I-D.

Jonathan

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Fri, 11 Dec 2015 13:54:21 +0000

Hi all,

Given the feedback on the list, the chairs are willing to run a TCPM adoption call.

However, we observe that the document is not specific to TCP and also mentions other transport protocols such as SCTP. This means that the document could also be in scope of TSVWG.

Thus, prior to starting a formal adoption call in TCPM, we would be interested in feedback if TCPM is indeed the best fit. For instance, assuming a successful WG adoption in TCPM, one option would be to last call the document also in TSVWG. Any thoughts from the community?

We do not believe that the document is ready for WGLC if adopted in TCPM. First, we believe the document should be reviewed in particular from persons working on non-TCP protocols, in order to avoid a TCP bias. Second, Rule (3) in Section 2 may require further discussion, as the wording could conflict with an upper bound of the RTO, which is e.g. allowed by RFC 6298.

Thanks

Michael

-----Original Message-----
From: tcpm [mailto:[email-masked]] On Behalf Of Mark Allman
Sent: Wednesday, December 02, 2015 4:53 AM
To: [email-masked]
Subject: [tcpm] new rev of rto-consider posted

I posted rev -03 of the rto-consider I-D.  It addresses two basic bits of feedback I received about the last version:

You can snag draft-allman-tcpm-rto-consider-03.txt from the usual places or from: 

Faber said WGLC.  I am not sure if a WG chair emeritus can call for that, but what the hell ... vote early and vote often. :-)

allman

---

From: Mark Allman <[email-masked]>
Date: Fri, 11 Dec 2015 09:11:07 -0500

> However, we observe that the document is not specific to TCP and
> also mentions other transport protocols such as SCTP. This means
> that the document could also be in scope of TSVWG. 

This makes sense.  Perhaps some AD advice here?

> Second, Rule (3) in Section 2 may require
> further discussion, as the wording could conflict with an upper
> bound of the RTO, which is e.g. allowed by RFC 6298. 

Good catch.  You're right that there should be a statement in this
rule that backoff can be terminated at some point, a la 6298.

allman