Subject: draft-ietf-pilc-error-02 - Suggested Ammendments

From: Dr G Fairhurst <[email-masked]>
Date: Fri, 26 Nov 1999 15:13:54 +0100

http://www.ietf.org/internet-drafts/draft-ietf-pilc-error-02.txt

I have just read the above draft, and have the following comments
(if some of these have already been covered, please ignore them).

Section 2.2 Fast Retransmit and Fast Recovery [RFC2581]
========================================

End of para 1:

"Missing segments are detected by the receiver by segments arriving with

out-of-order sequence numbers."

I don't quite agree; I rather thought the receiver had little knowledge
of what
was missing
or may be delayed, and usually (except with "SNACK") makes no decisions
about
this.
I wonder if it would be wiser to say something along the lines of:

"The receiver does not normally detect missing segments, however it does

 send an acknowledgement for each received segment (irrespective of
order).
 When the SACK option is used, for this feedback, the sender is able to
imply
 loss of segments by the lack of an acknowledgement for the missing
sequence
numbers."

Start of para 2:

" TCPs SHOULD immediately send an acknowledgement when data when is
   received out-of-order, sending the next expected sequence number
   with no delay, so that the sender can retransmit the required data
   and the receiver can resume delivery of data to the receiving
   application."

See above, I don't see it as a job of a TCP receiver to ***tell** the
sender
what
to do.  The sender is merely informed and makes it own decision based on

the local information. The word "so", is perhaps a little strong? Should

it be "allowing" ?

Point 3:

     " 3. Often small socket buffers are recommended with high
      error-rate links in order to prevent the RTO from inflating."

As far as I know, this is a recommendation to people configuring stacks
and not usually an automatic process or one signalled by an
application.  Perhaps the documents should be clearer about who
does this tuning. Or am I wrong?

2.3 Selective Acknowledgements [RFC2018]
===============================

Para 2:

When we wrote ref [SF98] we included data for various error
environments.

It became clear to us that:

(a) The SACK feedback provides congestion information by signalling
explicit
leaving of packets from the network, and therefore available capacity
over
the link with errors (using the usual conservative rules to grow cwnd).

(b) The SACK feedback provides implicit  loss indication following a
previous
retransmission.  This implicit information may be extracted from viewing

the time of order of the exchange of retransmitted DATA segments
and the announcement of SACK information for each data segment.
I can explain more - but the key point for links with errors is that
this
provides a safe way to detect loss of a retransmission, and to recover
it ***without*** reliance on the RTO - and therefore without invoking a
full slow-start event.

2.4 Delayed Duplicate Acknowledgements [MV97, VMPM99]
=========================================

Some people (including us) believe a great deal of performance
improvement
is possible, simply by redesigning the link ARQ to match the needs of
TCP.

Therefore I would suggest there are two approaches within the remit of
the
group: (1) Modify TCP to allow link ARQ to operate, (2) Modify link ARQ
to mitigate the interactions with TCP.

2.5.1 Why we need Explicit Corruption Notification
====================================

Help? Does the C in  ECN mean Congestion or Corruption????
Is it wise to have two orthogonal issues with the same 3 letter
abbreviation?

I also fear your recommendation at the end of the ECN  isn't perhaps
careful
enough about the implications of different network topology?

Best wishes,

Gorry Fairhurst.

--

Gorry Fairhurst
University of Aberdeen, Scotland, UK
http://www.erg.abdn.ac.uk/users/gorry