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

[Kamesh Medepalli <[e-mail]>]

Gorry/Mark:

 Thanks. Some comments inline..

Gorry Fairhurst wrote:
> 
> Some comments on delayed ACKs....
> 
> Gorry
> 
> Kamesh Medepalli wrote:
> >
> > 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?
> 
> 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. 

   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
> delayed ACK policy when using a path including a specific type of link
> (e.g. 2.5G)?

   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.

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

 Yes, it could be as simple as that.

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

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