Skip to main content

The Eifel Response Algorithm for TCP
RFC 4015

Yes

(Jon Peterson)

No Objection

(Alex Zinin)
(Bert Wijnen)
(Bill Fenner)
(David Kessens)
(Margaret Cullen)
(Scott Hollenbeck)
(Steven Bellovin)

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

(Allison Mankin; former steering group member) (was No Objection) Yes

Yes (2004-05-27)
Perhaps add Mark Allman with you to the reviewers (in the writeup), since his review in the 
WG was so significant?

(Jon Peterson; former steering group member) Yes

Yes ()

                            

(Alex Zinin; former steering group member) No Objection

No Objection ()

                            

(Bert Wijnen; former steering group member) No Objection

No Objection ()

                            

(Bill Fenner; former steering group member) No Objection

No Objection ()

                            

(David Kessens; former steering group member) No Objection

No Objection ()

                            

(Harald Alvestrand; former steering group member) No Objection

No Objection (2004-05-27)
I'm sure this is a beautiful algorithm.
But after reading the RFC, I still have no knowledge on whether or not I should be interested in adding this to my TCP implementation.
- Always?
- Only when I am in an environment where non-congestion loss is common?
- Only if I like having more code in my TCP?
- Other criteria?
This is not worth braking the progress of the document for. But I miss it.

(Margaret Cullen; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection (2004-05-26)
  In the security considerations, we learn that the Eifel
  response algorithm SHOULD only be run together with detection
  algorithms that are known to be safe against such "ACK spoofing
  attacks."  Are there other characteristics of detection algorithms
  that ought to be considered?  I would like to see the section 1
  list the characteristics of an "appropriate detection algorithm."

(Scott Hollenbeck; former steering group member) No Objection

No Objection ()

                            

(Steven Bellovin; former steering group member) No Objection

No Objection ()

                            

(Ted Hardie; former steering group member) No Objection

No Objection (2004-05-24)
In Section 2., the draft says:

   If the Eifel response algorithm is implemented at the TCP sender, it
   MUST be implemented together with a detection algorithm that is
   specified in an RFC.

Is there any expectation of specific RFC categories?

(Thomas Narten; former steering group member) (was Discuss, No Objection) No Objection

No Objection (2004-05-27)
>    The Eifel response algorithm relies on a detection algorithm such as
>    the Eifel detection algorithm defined in [RFC3522]. That document
>    discusses the relevant background and motivation that also applies to
>    this document. Hence, the reader is expected to be familiar with
>    [RFC3522]. Note that alternative response algorithms have been

seems like a normative reference to 3522 (experimental). This text
itself seems to argue that the text is normative (i.e, by saying
"reader is expected to be familiar with"). Does this need to be
normative?

>       (DET)   This is a placeholder for a detection algorithm that must
>               be executed at this point. In case [RFC3522] is used as
>               the detection algorithm, steps (1) - (6) of that algorithm
>               go here.

What does this step do, in terms of what _this_ spec needs to know?
Does it produce a results that says "spurius retransmit detected,
execute step 7"? (that is kind of what I would think, since the
response would presumbaly only be executed when needed...) It would be
good to make this more clear.