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

From: Allison Mankin <[email-masked]>
Date: Sun, 03 Jun 2001 01:41:37 -0400

Mark,

Belated return to discussion affecting the Error draft.

I find your example convincing.  So could you suggest a
fix to the text in Error about Limited Transmit that makes it more
accurate?  Here's what is in the text now, that you found concern
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. 

In the words of my co-AD, Send Text :)  Thanks.

Allison

> Date:    Thu, 24 May 2001 11:17:44 EDT
> Subject: Re: draft-ietf-pilc-error-07.txt - some fixes requested by IESG 
> From:    Mark Allman <[email-masked]>
> To:      [email-masked]
> Cc:      gabriel montenegro <[email-masked]>, Markku Kojo <[email-masked]>,
> 	 [email-masked], [email-masked], [email-masked],
> 	 [email-masked]
> Reply-To: [email-masked]
> --------
> 
> 
> > 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/
>

---

From: Mark Allman <[email-masked]>
Date: Wed, 06 Jun 2001 09:41:09 -0400

>    track specification for TCP in loss environments. 

I think this will probably work:

  "Limited Transmit" [RFC3042] has been specified as an optimization
  extending Fast Retransmit/Fast Recovery for TCP connections with
  small congestion windows that will not trigger three duplicate
  acknowledgements. This specification is deemed safe, and it also
  provides benefits for TCP connections that experience a large amount
  of packet (data or ACK) loss.  Implementors should evaluate this
  standards track specification for TCP in loss environments.

allman

---