Subject: Reminder: 2.5g3g wg last call ends Friday

From: [email-masked]
Date: Wed, 18 Jul 2001 10:37:13 -0400

Just a reminder that we are in last call for draft-ietf-pilc-2.5g3g-03.txt.
A list hum would be helpful to the chairs. Is this document complete?
stable? accurate? 

--aaron

> draft-ietf-pilc-2.5g3g-03.txt is pretty stable and, in the 
> opinion of the wg
> chair, is ready for wg last call. Please send comments to the 
> authors and/or
> the pilc mail list before July 20th.
> 
> The current rev of the draft is available from 
> http://www.ietf.org/internet-drafts/draft-ietf-pilc-2.5g3g-03.txt.
>

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Wed, 18 Jul 2001 23:49:12 +0200

I just had a quick read of the document.
See below.

Gruesse, Carsten

1)

> RLC preserves order of packet delivery 

appears to be a remnant of what should be a longer sentence.

2)

What *is* the BDP?
Delay can be very high for 2.5G (1.5 to 4 s).

3)

Is this draft arguing for connection splitting?

4)

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

Who is this recommendation aimed at?
(TCP already complies.)
"Designers" of what, anyway?

5)

For 3.1.5, add a comment that overzealous firewalling of ICMP traffic
may impede path MTU discovery and therefore is to be avoided.

6)

There is a spurious M in 3.1.8

7)

>  Ricochet
>  acts like, feels like, and works like a high-speed wired network
>  connection. 

Wrong language mode for IETF.
(Oh, and high-speed wired is gigabit Ethernet these days.)

s/is place/is placed/

Now what exactly is the point of this section 3.2.3?
I can't see any information that discusses profiling.

8)

>  If you use the transport gateway as mentioned in Section 3.1.2, note
>  that it introduces several issues which impact security, which
>  includes the conflict with IPsec. 

Right -- see my comment 3 above.

>  For example, WAP protocol stack is considering to deploy TLS [31]
>  because of its gateway architecture. 

Now, TLS is *not* impeded by connection splitting below it, so I'm not
sure I see the point here.

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 19 Jul 2001 15:09:44 +0100 (BST)

> Wrong language mode for IETF.

Well, that's an understatement.

http://www.ietf.org/internet-drafts/draft-ietf-pilc-2.5g3g-03.txt

|   Metricom, Inc. is a high-speed wireless data company

...that filed for US Chapter 11 bankruptcy last week.

These rah-rah-rah capsule descriptions of WAP, i-mode and Ricochet are
pointless, less than what you'd find in many trade rags, and would be
out of place in any RFC.

As far as I can see, the draft has no clear purpose; best-practice TCP
implementations are described far better and more clearly elsewhere,
and I'm not even going to attempt to begin to list individual nits or
doubts.

I'm sorry, but this draft is ready for last call in much the same way
that a lamb is ready for the slaughter; be merciful, be brief, and
kill it to put it out of its misery.

Eleven named authors and not one can write clear RFC-quality English
or run a spelling or grammar checker?

L.

so much for that 'winning friends' thing. someone has to say this.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: "Hiroshi INAMURA" <[email-masked]>
Date: Thu, 26 Jul 2001 22:57:19 +0900

L. Wood wrote;
> pointless, less than what you'd find in many trade rags, and would be

Mark Allman wrote;
> An RFC is no place for advertisements, which is precisely what these
> sections of the document are.  I raised this issue the last time I
> read this document and was told that these were supposed to a sort
> of "applicability statement".  I did not respond as I wanted to wait
> and see if the document was altered at all.  But, I still feel the
> same way.  These sections are essentially marketing.  If you want to
> list the technologies that the document is applicable for just put a
> very simple list in section 2 and be done with it.  In my opinion
> these sections **really** need to be removed.

First of all, the section 3.2 'Applications' will be deleted. Some pointers
for showing applicability, we are adding several lines to section 1 '
introduction'. We will post the updated paragrph soon.

Hiroshi

---

From: "Hiroshi INAMURA" <[email-masked]>
Date: Tue, 31 Jul 2001 03:50:59 +0900

Jo Touch wrote:
> TCP needs large windows. 3G has large BDP. Let the other
> shoe drop - tell us what the BDP _IS_. Also, TCP with support for
> large windows is already recommended.

As an example, I have tested what the appropriate receive window sizes for
WCDMA in the last weekend. If following paragraph is interesting to you, I
will consider put this into the document.

---

Measuring TCP throughputs for various TCP receive window sizes in real 3G
networks can reveal a typical BDP for 3G wireless networks. In FOMA
implementation of W-CDMA, for example, 48-64KB TCP receive window size
showed good performance. Under a condition of fairly crowded cells, the TCP
throughput was 241-264Kbps for 48-64KB TCP receive window size, as compared
to 99Kbps-171Kbps for 8KB-32KB. This number has taken as of this writing
using Windows2000 as a receiver and transferring an 866 KB file over HTTP.
MTU was set to 1500Bytes. Both the client and the server implemented SACK.

---

Hiroshi

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 31 Jul 2001 10:25:26 +0100 (BST)

> will consider put this into the document.

For this to be meaningful, you need to state where the endpoints of
the path were. Is this solely across the wireless link? Across the
3G provider network? Across all that and a cloud?

A single HTTP/1.1 session starting from scratch, or with pipeline
already open? Honestly, hard numbers can raise more questions than
they answer...

L.

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 31 Jul 2001 10:42:01 +0100 (BST)

Hiroshi, 

I think this may not be quite sufficent, it is hard 
to build a picture of what is going on from this, 
and I'm not therefore yet reached a point where
I think one can form a clear opinion on whether the things
you say make sense.

Have you got some TCP sequence number v. time plots
(e.g. using tcpdump) which you could put on a web page so
that the WG  can see how TCP is behaving in this case. Since
this is going to be advice to people designing all
sorts of IP services over 2.4 and 3G, I wonder
if there is any information which covers the
BDPs of a range of such services?

Gorry