I gave the above draft a re-read, to tray and identify what
I didn't think was clear, and came up with the following
queries / comments. Hope these prove helpful in preparing the
next rev. of the draft... or stimulate some discussion...
In section 2.2 para 6, the ID speaks of "error-free" packet
service. This term is probably wrong. Perhaps what is meant, I guess
is that the packets have a negligible probability of undetected
error (failure of the link CRC), and a low level
of loss (non-delivery) - since any ARQ protocol which isn't
"perfect" must allow some probability loss.
Perhaps it is also worth commenting on the packet ordering?
In section 3.1.1 para 1
You speak about "link efficiency", which seems to be a strange use
of the concept. The link utilisation is the sum of all the bits
sent by all the sessions sharing the link divided by the bit rate
(informal definition). But, I wonder whether the draft is actually
looking at the TCP throughput. This paragraph probably needs to
be rethought to reflect the fact that most links support many
TCP sessions, and from the TCP session perspective, it's the
overall path round trip time that matters, not the link's
delay - granted the wireless link delay **may often** dominate.
In section 3.1.1 para 5
To improve the performance over any link with appreciable delay,
a larger initial cwnd is desirable.... true, but not sure a
cwnd of 2 fully compensates for delayed ACKs...
In section 3.1.3 para 1
There seems to be a mix-up between frame (link layer PDU size)
and network layer PDU. The conclusions drawn suggest that
transparent link fragmentation is not done - I think you
need to be clear about whether this is or isn't used - or
perhaps describe both cases. With link fragmentation,
a larger MTU does not increase error rate. In fact a
smaller one does, since more IP/TCP header bytes are sent
per TCP payload data byte.
In section 3.1.3 para 1
The term "MUST" support SACK seems strange. Failure to do
so does not result in loss of reliability, or any problem,
apart from potential impact on performance. Indeed,
since the option has to be agreed by both sender and
receiver, a 2.5G/3G system MUST be capable of operating
without SACK if the remote system is incapable of
supporting SACK. Perhaps "MUST" should be "SHOULD"?
The same may apply to the current "MUST" in the window
scaling recommendation...
Gorry
------------------------------
http://www.erg.abdn.ac.uk/users/gorry
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:26 EST