Subject: draft-ietf-pilc-error-07.txt - some fixes requested by IESG

From: Allison Mankin <[email-masked]>
Date: Fri, 18 May 2001 13:54:51 -0400

ERROR authors and PILC chairs,

The IESG completed a discussion of ERROR yesterday and overall
would like it to advance, but we need two issues resolved. 
With the working group involved in resolving the issues, there
is very little chance that further last-calling will be needed.

Allison

Issues with draft-ietf-pilc-error-07.txt

1.
-----------
As the To: list heard last week, there was an oversight about 
updating the discussion of RFC 3042 (which, by the way, has been
implemented and exercised significantly in Linux recently).
The easiest course is to leave the recommendation about it in
Future Work (Section 4.0) with a text update.  The IESG accepted
this approach, i.e. replacing Section 4.0 first paragraph with:

   "Limited Transmit" [RFC3042] has been specified as an optimization
   extending Fast Retransmit/Fast Recovery for TCP connections with
   small congestion windows that won't generate three duplicate
   acknowledgements. This specification is deemed safe, and it also provides
   benefits for TCP connections with larger congestion windows when
   losses occur at or near the right edge of the window. Implementors
   should evaluate this standards track specification for TCP in
   loss environments.

2.
-----------
The Security Considerations section is very terse.  It is a good
comment as far as it goes, but it should say explicitly that
the fact recommended methods coexist with end-to-end IPSec use is
in contrast to PEP-based methods, which do not.  In addition, are
there additional insights about the security considerations of the
specs that ERROR recommends that either time or the special
conditions of highly errored links should cause you to add?  Please
consider and enhance this section.  

A new resource to help with enhancing your Security Considerations
is draft-rescorla-sec-cons-03.txt.  The IAB has worked with the
authors and hopes to issue this as an IAB-endorsed recommendation in
the near future.  IESG would like to see folks use it and also we
welcome you to review and comment on it to IAB and ourselves.

Allison

---

From: Mark Allman <[email-masked]>
Date: Thu, 24 May 2001 11:17:44 -0400

> Doesn't the text mean that if the loss is at the right edge, the
> next recourse is an RTO and rxt, because the left edge sourcing is
> stopped because the window is full?

I don't think so.  But, I am confused by what "the window" means at
this point.  Congestion or advertised?

An example...  Say we send segment 1-8 and segment 8 is lost (the
right edge).  Now suppose we get ACKs for packets 2, 4, 6 and 7 (as
would be reasonable with delayed ACKs and no ACK loss).  The ACK for
segment 2 would clock out packets 9 and 10 (assuming we're in
congestion avoidance here).  The remaining ACKs clock out packets
11-15.  When these data segments arrive at the receiver they all
trigger duplicate ACKs that cover everything through segment 7.  In
the case of limited transmit we would clock out segments 16 and 17
on the first two dup ACKs.  But, in either case we are going to end
up getting the required three dup ACKs to trigger fast retransmit --
*unless* there is lots more data/ACK loss such that 3 dup ACKs will
not arrive.

So, I do not believe the position of the loss within the window has
much bearing on the effectiveness of limited transmit.  Rather, the
size of the cwnd and the amount of loss are the keys, I think.

If you mean that we lose something at the left edge of the
advertised window limited transmit doesn't buy you anything either,
because the algorithm still can't violate the receiver's advertised
window.

Does this make sense?

allman

---
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/