> I don't see the case for recommending time stamps with a large
> window either. The need for time stamps over very low
> latency paths, or/and with very high transmission SPEED is
> well understood. (See also earlier mail from Mark Allman on this).
Okay, I will retract the recommendation of timestamp.
> P.S. As I mentioned in the WG meeting, it may be worth clarifying the
> use of the words "Name Server" - which in your document seems more
This will be fixed soon. Ricochet description is under revising.
> 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.
How about following incorporating your wordings.
In general, the L2 ARQ and FEC can provide a
packet service
with a negligible probability of undetected error (failure of the link
CRC),
and a low level of loss (non-delivery) for the upper layer traffic, i.e.
IP. The SDU (IP
packet) is fragmented into PDUs for transmission. The retransmission
by L2 ARQ introduces latency and jitter to the SDU flow, that
results in relatively large BDP (Bandwidth-Delay Product) of the
2.5G/3G networks.
> Perhaps it is also worth commenting on the packet ordering?
RLC uses "status report" type acknowledgments. It does not use
ack-clocking as in TCP, but rather the poll bit in the header
explicitly solicits the peer for a status report containing the
sequence number that the peer acknowledged. The use of the poll bit
is controlled by timers and by the size of available buffer space in
RLC. Also, when the peer detects a gap between sequence numbers in
received frames, it can issue a status report invoke retransmission.
RLC preserves order of packet delivery.
> 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
Revising as follows;
To achieve the maximum performance in TCP,
the advertised receive window size needs to be equal to or greater
than the BDP (Bandwidth Delay Product) of the end-to-end path.
> 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.
Revising as follows;
One of the link layer parameters is MTU (Maximum Transfer Unit). In
TCP, the slow start mechanism tries to find an adequate rate for the
link layer. The larger MTU allows TCP to grow the congestion window
faster [11] , because the window is counted in unit of segments.
In the link with error, smaller link PDU size is better in terms
of the chance of successful transmission. With layer two ARQ and
transparent link layer fragmentation, the
network layer can enjoy larger MTU even in a relatively high BER (Bit
Error Rate),
condition. Without these features in the link, smaller MTU is better. TCP
over 2.5G/3G SHOULD allow
freedom for designers to choose MTU from a small value (such as
576B) to a large value (up to 1500B).
> In section 3.1.5 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"?
Okay.
The selective acknowledgment option (SACK) [8] is effective when
multiple TCP segments are lost in a single TCP window [13] . In
particular, if the link has a large BDP and a certain amount of
packet loss rate, the ratio of multiple segment losses grows high.
In such cases, SACK performs better than traditional and Reno TCP
[9]. TCP over 2.5G/3G SHOULD support SACK.
Hiroshi
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:26 EST