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

[Gorry Fairhurst <[e-mail]>]

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

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

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