Subject: Re: Re draft-ietf-pilc-2.5g3g-00.txt...

From: Dr G Fairhurst <[email-masked]>
Date: Mon, 09 Apr 2001 13:09:50 +0100

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).

However, I suggest at moderate rates, there appears to be little 
advantage. I wonder if it may be wise to either include text describing
the reasoning behind this recommendation, or that you rethink what
you with to recommend?

You identified "larger initial cwnd" (>4) as a potential solution in
section 4 (Open Issues).  Although you say this is based on experimental
data, I would encourage you to look at the conditions under which 
the recommendation is true - in general such recommendations need to be
very carefully expressed, especially when the network may in the future
provide connectivity for large numbers of down-stream users...

Gorry Fairhurst

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
concerned with subnetwork hardware address resolution, than the usual
use for DNS to IP resolution.

Hiroshi INAMURA wrote:
> 
> Hi,
> 
> The header compression  is not recommended in the draft. We will address the
> issue in the "Open issue" section in conjunction with new achievements like
> ROHC.
> 
> For the use of timestamp option with window sizew less than 64KB, there is
> no recommendation. We will reflect your comment in the next draft.
> 
> Hiroshi Inamura
> 
> ----- Original Message -----
> From: "borderlt" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>;
> <[email-masked]>; <[email-masked]>;
> <[email-masked]>; <[email-masked]>; <[email-masked]>;
> <[email-masked]>; <[email-masked]>;
> <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, March 19, 2001 1:45 PM
> Subject: Re draft-ietf-pilc-2.5g3g-00.txt...
> 
> >
> >     Is header compression used?  (I am guessing not or it would have been
> > mentioned.)
> >
> >     The document recommends the use of Timestamps when a window of greater
> > than 64 KB is used.  What about when the window is less than 64 KB?  Are
> > Timestamps recommended for this case?  The answer should probably be
> > explicitly stated.  (Or, if there is no recommendation, this should be
> > explicitly stated.)  The thought was triggered by the previous question,
> i.e.
> > (my understanding is that Timestamps interfere with the ability to use
> header
> > compression.)  (But, I think ROHC is looking to do something abou this.)
> >
> >
> > John
> >

-- 
------------------------------
http://www.erg.abdn.ac.uk/users/gorry

---

From: Dr G Fairhurst <[email-masked]>
Date: Thu, 12 Apr 2001 16:45:23 +0100

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

---

From: "Hiroshi INAMURA" <[email-masked]>
Date: Fri, 27 Apr 2001 23:08:37 +0900

> well understood. (See also earlier mail from Mark Allman on this).

Okay, I will retract the recommendation of timestamp.

> use of the words "Name Server" - which in your document seems more

This will be fixed soon. Ricochet description is under revising.

> "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.

> 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.

> 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

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

---

From: Dr G Fairhurst <[email-masked]>
Date: Mon, 30 Apr 2001 14:38:12 +0100

Seems like you have responded to most of the issues raised in
my last email with very full answers - hope it was helpful.

Two small clarifications:

Hiroshi INAMURA wrote:
<<<snip>>>

> . The retransmission

I wondered what you exactly meant by large bandwidth delay
product.  I couldn't find any typical numbers within the
ID - so I wondered just how large this was expected to
be per IP flow?

The window-scaling (lfn) extensions only help if the channel bit rate
allocated to a flow is high enough, and the flow persists for long
enougth (in terms of segments sent) to establish a large cwnd. Having
worked with satellite people - I always worry about saying the BDP
is large...... How large? larger than gigabit WAN links?

<<snip>>>

>    packet loss rate, the ratio of multiple segment losses grows high.

Seems a very fair statement.

>    [9]. TCP over 2.5G/3G SHOULD support SACK.

I wonder if you would like to extend this to comment on 
New RENO?
RENO and SACK? 
NEW RENO and SACK ?