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

From: Vernon Schryver <[email-masked]>
Date: Tue, 6 Nov 2001 10:17:47 -0700 (MST)

> From: Lloyd Wood <[email-masked]>
> To: Reiner Ludwig <[email-masked]>
> Cc: PILC mailing list <[email-masked]>

> ...
> > > > Implementing active queue management is attractive for a number of
> > > > reasons as outlined in RFC2309 [15]. One important benefit for
> > > > 2.5G/3G networks, is that it minimizes the amount of potentially
> > > > stale data that may be queued in the network ("clicking from page to
> > > > page" before the download of the previous page is complete).
> > >
> > >This seems to confuse e.g. web proxy caching with active queue
> > >management;
> > 
> > I don't think so. I suggest you look for some papers that discuss the 
> ...

It's not worth getting excited about this text, because elsewhere it
says that it assumes 2.5G/3G networks have 3 second packet latencies.
3 second packet latencies imply application delays far above the 30 year
old measurements on the upper bound for keystroke latencies of 5 seconds.
Even if you subscribe to the WAP lunacy of imagining that all existing
Internet services will change to accomodate telephones so that somehow
they won't need at least 4 round trips, you have intolerable delays.
"Clicking" is not typing, but it is close enough to see that no interactive
service that involves 3 second RTT's has a hope of surviving in the
marketplace.  You can see this for yourself by modifying a system to
delay packets by 3 seconds and then trying to use it.

There may be a very few specialized, non-interactive services that
people might want to use with a wireless telephone, but they will be
specially implemented and either don't need to use TCP/IP or can use
persistent TCP connections and have absolutely nothing to do with any
version of HTTP, web caching, or any other more or less open standard.

On the other hand, if the text does intend to say that 3 seconds
latencies are typical of 2.5G/3G networks, it needs to be changed.

Vernon Schryver    [email-masked]

---

From: "Andei Gurtov" <[email-masked]>
Date: Tue, 6 Nov 2001 20:04:07 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf
> Of Vernon Schryver
> Sent: 6. marraskuuta 2001 19:18
> To: [email-masked]
> Subject: Re: draft-ietf-pilc-2.5g3g-04.txt

> latencies are typical of 2.5G/3G networks, it needs to be changed.

I sent a long list of comments for the previous draft version but it has
been left unreplied :-(

Large delay is a big problem for 2.5G/3G. For GPRS (2.5g) the minimum RTT is
about 700 ms. I think Reiner meant that 3 sec delay can result from large
queuing delay at the bottleneck buffer filled by an on-going TCP connection.

It is very much hoped that 3G network will implement some differentiation
among flows, so it's possible to have say 500 ms RTT for interactive traffic
(web browsing) and 5 s for bulk data.

Andrei

---

From: Reiner Ludwig <[email-masked]>
Date: Wed, 07 Nov 2001 10:50:05 +0100

At 18:17 06.11.2001, Vernon Schryver wrote:
>latencies are typical of 2.5G/3G networks,

You're right. That was *not* my intention. I meant that with ~10 Kb/s you 
have a large packet transmission delay to start with, and if you also have 
a certain number of packets queued in front of that link you might get 
close to 3 sec easily. Clearly this depends on the MTU ...

>it needs to be changed.

It seems so. I'll go over the text again. But really I didn't intend to 
reiterate stuff we have in the "Advice for Subnetwork Designers" ID. So, 
I'm hesitating to write about MTU sizes and related issues.

///Reiner

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 7 Nov 2001 08:57:59 -0700 (MST)

> From: Reiner Ludwig <[email-masked]>

> I'm hesitating to write about MTU sizes and related issues.

In that case, two thoughts occur to me.

It does not matter why the RTT is 3 seconds.  People simply will
not use interactive devices or services in ways that involve delays
above 5 seconds, and that is what you get with TCP and RTTs above
3 seconds.  Whether the delays are designed into radios or come
from congestion of modest speed links does not matter.

Second, there is an easy, ad hoc QoS kludge in the radios that might
solve your initial timeout problem.  Move IP packets carrying TCP
segments with the SYN bit set toward the front of the queue to ensure
that they are not delayed more than 2.5 seconds.  This is a less klunky
version of the QoS kludge of moving all small packets in front of long
packets that I shipped in some commercial SLIP and later PPP code some
years ago.  It worked fine to give interactive applications such as
telnet good service despite concurrent bulk transfers over 9600 bit/sec
modems without anyone ever complaining.

By the way, it wouldn't hurt to mention that contrary to the WAP nonsense,
10,000 bit/sec does not sound like a particularly low rate to knowledgeable
people.  Not so long ago entire multi-$100M commercial outfits were
connected with 9600 bit/sec links.  Not until yuo get below 1200 or at
least 2400 bit/sec can you talk about a TCP/IP link being slow.

---

From: Kamesh Medepalli <[email-masked]>
Date: Wed, 07 Nov 2001 18:04:53 -0500

Reiner et al:

 A few comments on your ID:

 1. Seems like this and the RFC3155 [end-to-end perf with errors] have a lot
    in common - hence a number of the recommendations overlap.
 2. About assuming that Delayed ACKs are widely deployed: Is it really clear
    that delayed ACKs need to implemented for TCP over wireless? Also, it 
    would help to have a clear definition of delayed ACKs and explicitly 
    mention whether you are referring to d=2 or d>2 etc.
 3. Asymmetry is a very big issue in Wireless - Raw bandwidth ratios of about
    4 exist in GPRS/EGPRS, cdma2000 and UMTS. I could not find any mention
    of it nor were any references. This is where a lot of stuff could be
    used/discussed among the Asymmetry and your drafts. 
 4. Asymmetry draft does not recommend (modified) delayed ACKs but yours 
    does. Again, it would be very helpful if this part can be appropriately
    expanded.
 
 A few editorial type comments:
 1. Page 4, para 3, SDU introduced for first time but not defined.
 2. On Page 4, Para 5, "For TCP traffic..". Sounds like RLC does some sort
    of snooping into higher layer headers, which is not the case. Perhaps
    reword it to suggest "for reliable transfer.."
 3. A period missing at the end of the same para.
 4. Para 6, "The RRC can give the max..", needs rewording for correct
    grammar.
 5. Page 9, para 2, "avoiding transmission of stale data....safes", 
    safes should be replaced by saves.

Kamesh

---

From: "Juan Rendon" <[email-masked]>
Date: Thu, 8 Nov 2001 11:06:12 +0100

> queuing delay at the bottleneck buffer filled by an on-going TCP
connection.

I would add that besides the large delays found in a 2.5G network like GPRS,
another problem are the highly variable delays found in this system. In a
packet switching system like GPRS the delays in the radio path are also
highly dependent on the number of users present at any time in the radio
channel. One way to solve that situation could be a scheduling method (a
congestion manager??) in the GPRS radio interface, but it would only
guarantee a limited number of users a fixed delay.

Juan Rendon

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 08 Nov 2001 14:42:45 +0000

Some comments on delayed ACKs....

Gorry

Kamesh Medepalli wrote:
>     that delayed ACKs need to implemented for TCP over wireless? 

The current TCP standard [RFC1122] says do this on an end host. It
doesn't say 
that you can choose not to do it (it is a MUST), if you happen to have a
reason 
why not. An interesting question is how would an end host know to use a different
delayed ACK policy when using a path including a specific type of link 
(e.g. 2.5G)?

>     Also, it

This seems a good idea, if you need to talk about d>2 (or you could point
to the asymm draft, section 5.1, and save saying things twice?)

http://www.ietf.org/internet-drafts/draft-ietf-pilc-asym-06.txt

>     used/discussed among the Asymmetry and your drafts.

A raw bandwidth ratio of 4 is actually a very small level of
asymmetry... BUT,
what really matters is the asymmetry in capacity seen by an end host, which
may be much more...

>     does. Again, it would be very helpful if this part can be appropriately

<<Snip>>

---

From: Kamesh Medepalli <[email-masked]>
Date: Thu, 08 Nov 2001 10:27:01 -0500

Gorry/Mark:

 Thanks. Some comments inline..

Gorry Fairhurst wrote:
> why not. 

   The same old arguments against delayed ACKs like increased RTT, reducing 
   the groth of cwnd etc. Although, a larger initial window (=2) would null 
   out the initial effect of d=2. The increased RTT in combination with
   bursty increase of cwnd may work against using uplink sparingly. Add
   to it the variability of data rates in wireless. Are there any 
   good experimental results that can demonstrate "clear" benefit?

> An interesting question is how would an end host know to use a different

   Absolutely. One could argue (in an ideal world) that the web servers
   would support 2 distinct host functionalities (one for wireless and
   the other for wireline). Reality of that happening is very small.
   This brings me to the bigger point: Any modifications should be made at
   the receiver - it is easier for a smart mobile to be running TCP optimized
   for wireless..as opposed to doing wireless specific things either at the 
   host or some intermediary point.

> http://www.ietf.org/internet-drafts/draft-ietf-pilc-asym-06.txt

 Yes, it could be as simple as that.

> what really matters is the asymmetry in capacity seen by an end host, which

A caution: raw ratio of 4 is towards the "ideal" case. A lot depends on the
algorithms used for rate allocation - which is vendor specific. Lucent may
do something different than others. I can easily see a cdma2000 mobile 
requesting no more than 9.6Kb/s for sending HTTP requests, TCP ACKs etc while 
it could be receiving 153.6Kb/s on the downlink. A raw ratio of 16. The
normalized bandwidth ratio can easily exceed 1 even with MSS=1500B [assuming
avg MSS on uplink of about 200B (ACKs + GET requests)].

So the ID should address it by making recommendations for the k>1 case:
like scheduling uplink traffic etc. Or simply extract the ones that you
are most comfortable with from the asym draft.

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 8 Nov 2001 16:52:51 +0000 (GMT)

On Wed, 7 Nov 2001, Vernon Schryver wrote:

> that they are not delayed more than 2.5 seconds. 

doesn't help the IPSec crowd.

does help the syn-flood attack script kiddies.

doesn't help a saturated webserver that doesn't want to open or deal
with new connections, but does want to service the ones it already
has.

doesn't do parallel UDP real-time streaming any good at all.

L.

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

---

From: "Hiroshi INAMURA" <[email-masked]>
Date: Tue, 20 Nov 2001 15:29:34 +0900

>     safes should be replaced by saves.

Thanks, these points are incorporated into the new rev.

Hiroshi Inamura