Fw: comments on draft-ietf-pilc-2.5g3g-03

["Aaron Falk" <[e-mail]>]

----- Original Message -----
From: "Andei Gurtov" <[e-mail]>
To: <[e-mail]>
Sent: Monday, August 20, 2001 2:09 AM
Subject: Fw: comments on draft-ietf-pilc-2.5g3g-03


> Hi Aaron,
>
> I sent this mail to the PILC list as we agreed, but it didn't seem to make
> it through.
>
> rgds,
> Andrei
>
> ----- Original Message -----
> From: "Andrei Gurtov" <[e-mail]>
> To: <[e-mail]>
> Sent: Thursday, August 16, 2001 11:43 AM
> Subject: comments on draft-ietf-pilc-2.5g3g-03
>
>
> > Dear All,
> >
> > Aaron suggested sending more feedback on draft-ietf-pilc-2.5g3g-03, so
> > please consider my comments.
> >
> > The first impression is that the draft indeed recommends using the
> > "latest TCP", I agree with Mark about this. I think there isn't any TCP
> > features discussed in this draft that would be unsuitable for general
> > deployment in the Internet.
> >
> > The second thing, is that the draft considers 2.5g and 3g systems
> > together, when in fact they may have quite different link properties. I
> > believe 2.5g falls very much under LTN document, while 3g might be
> > something closer to a satellite link. Due to this there is some
> > confusion in recommending for example limited Xmit and windows scaling
> > in the same document.  Limited Xmit can be useful for 2.5g when windows
> > are small but probably would not make much difference for 3g which has
> > big windows and can recover from occasional losses without it. On the
> > other hand
> > window scaling which could (theoretically) be useful for 3g is not at
> > all needed for 2.5g.
> >
> > Thus, I believe it will be useful to treat 2.5g and 3g separately in the
> > draft.
> > At least in European cell systems 2.5g (GPRS) is in fact more
> > problematic for TCP than 2g (GSM data) since GPRS is packet-switched
> > while GSM has a reserved circuit for the connection. Even from the data
> > rate point of view uplink GPRS (which is one-timeslot same as the basic
> > GSM) is in fact slower than the
> > GSM data service due to required packet protocol overhead. Our
> > performance evaluation experience (see
> > www.cs.helsinki.fi/u/gurtov/papers) is that GPRS has rather huge RTT
> > pikes due to handovers, high error loss rate, and frequent blackouts.
> >
> > >From the practical experiments  it seems that major TCP implementations
> > Linux, Windows, FreeBSD have bugs that cause performance problems in
> > 2.5g/3g. While it may sound too trivial, one recommendation could be
> > simply to double check your TCP implementation and avoid such kind of
> > 'optimizations' like disabling fast retransmit for short TCP connections
> > (see TBIT paper in Sigcomm'01)
> >
> > I suggest also a couple of additions to the Section 2 - Link
> > characteristics.
> >
> > -cell systems seems to have inherent asymmetry in the data rates (about
> > 1 uplink to 3-4 downlink) for example due to battery power limitations
> > which is probably not too much to worry about TCP ACK stream, but still
> > could have some performance effect?
> >
> > -packet cell systems may have a large radio resource allocation delay
> > ranging from tens to hundreds of milliseconds. This may leads to e.g.
> > twice the normal RTT  for the initial SYN&data exchange for a TCP
> > connection until the pipe gets full.
> > For example, even if GPRS claims to have 'always on' capability, a
> > link-level radio timeslot allocation needs to be done every time after a
> > user has been idle for a short time, e.g. half a second. This may be a
> > strong argument in favor of larger initial  window size to be able to
> > fill the pipe (and thus to decrease the RTT) quicker.
> >
> > I would be happy to hear from our (more successful :-) colleagues if
> > behavior of 2.5g or 3g in Japan is different from described above.
> >
> > Andrei
> >
> >
>