RE: comments on draft-ietf-tcpsat-stand-mech-04.txt

[Eric Travis <[e-mail]>]

> I've been thinking in terms of increased initial congestion window
> proposals, so what I trying to say was "if the recommended initial cnwd is 2
> (or 3, or 4), we can ACK-per-packet in this window without doing
> ACK-per-packet in all situations". Sorry for not providing this context in
> my previous post.

OK - I'm a bit dense, I understand what you were getting at now; This
makes me want to hack my stack this weekend to do this - I can't decide
whether or not this would result in a vile (larger than 3 or 4 segment) 
burst or not. I'm thinking that it wouldn't, but I need to see to believe
;o)
 
> I wasn't counting on the receiver knowing what initial cnwd the sender is
> using. I was just thinking that any increases in recommended initial cnwd
> could be used as a conservative approximation of how much additional ACKing
> we can do without causing problems.

Yep - I'm curious now to see how this would effect behavior (at least on
a single connection); If it rains this weekend, I can forgo the yard work
grass and mangle the code... I'm worried about aggregation effects - but I
am with a plain increase with i-cwnd without a different ack strategy. 

 
> At the very least, we could ACK the FIRST packet!

Absolutely - though if the i-cwnd >= 2, we already avoid the initial
delayed ack.

Regards,

Eric