Skip to main content

Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP)
draft-ietf-tcpm-early-rexmt-04

Yes

(Lars Eggert)
(Magnus Westerlund)

No Objection

(Cullen Jennings)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)

Note: This ballot was opened for revision 04 and is now closed.

Lars Eggert Former IESG member
Yes
Yes () Unknown

                            
Magnus Westerlund Former IESG member
Yes
Yes () Unknown

                            
Adrian Farrel Former IESG member
(was Discuss, No Objection) No Objection
No Objection (2010-01-12) Unknown
I have reluctantly cleared my Discuss on this document as this sort of issue should not hold up publication. The Discuss position achieved the objective of causing discussion within the IESG and with one of the document authors, and I am now informed that the authors will not make any change to the document.

It seems to me unfortunate that the author is unwilling to include a simple statement that would make the purpose of the document more clear with respect to its Experimental status and with respect the working group's intentions for the protocol work in the future. This would also help the implementer decide between the various choices in the document.
Cullen Jennings Former IESG member
No Objection
No Objection () Unknown

                            
Dan Romascanu Former IESG member
No Objection
No Objection (2009-12-17) Unknown
I agree with Adrian's DISCUSS and Ralph's COMMENT about the need to better define the conditions of the experiment, criteria to assess results, and operational impact of deployment in the Internet.
Ralph Droms Former IESG member
(was Discuss, No Objection) No Objection
No Objection (2010-01-12) Unknown
I have cleared my Discuss.  The conversation with the authors has clarified that this specification is intended for experimentation without being "used in operational settings" (Mark Allman).  While I would have been happier with a brief note to this effect in the document itself, I'm not willing to hold up its publication over the issue.
Robert Sparks Former IESG member
No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Tim Polk Former IESG member
No Objection
No Objection (2009-12-17) Unknown
(1)

In sections 2.1 and 2.2 the text for evaluating the conditions is imprecise.  I suggest
the following edits to cover the case where one of (a) or (b) does not hold:

In 2.1

OLD
    When conditions (2.a) and (2.b) do not hold, the transport MUST NOT
    use Early Retransmit, but rather prefer the standard mechanisms,
    including Fast Retransmit and Limited Transmit.
NEW
    If either (or both) condition (2.a) or (2.b) does not hold, the transport MUST NOT
    use Early Retransmit, but rather prefer the standard mechanisms,
    including Fast Retransmit and Limited Transmit.

(There is almost certainly better wording, but hopefully this clarifies this issue.)

A similar fix is need in 2.2.

(2)

Intuitively, I understand that this algorithm should result in retransmission of outstanding
segments.  However, I could not actually find this statement anywhere.  The main audience
probably doesn't need its hand held here, but for the rest of us a clear statement would be
nice.