Re: comments on draft-ietf-tcpsat-stand-mech-04.txt
Vern Paxson <vern@ee.lbl.gov> Sat, 20 June 1998 06:20 UTC
Message-Id: <199806200620.XAA03717@daffy.ee.lbl.gov>
To: Eric Travis <travis@clark.net>
Cc: tcp-over-satellite@achtung.sp.trw.com
Subject: Re: comments on draft-ietf-tcpsat-stand-mech-04.txt
In-Reply-To: Your message of Thu, 18 Jun 1998 13:49:46 EDT.
Date: Fri, 19 Jun 1998 23:20:44 -0700
From: Vern Paxson <vern@ee.lbl.gov>
Sender: owner-tcp-over-satellite@achtung.sp.trw.com
Precedence: bulk
Status: RO
Content-Length: 2659
Lines: 61
> [Aaron wrote:] > I don't think that because it is only good in some > satellite scenarios that it now becomes a research issue. Acking every packet isn't only good for satellite scenarios, it helps performance in general. > 1) Is it legal with respect to RFC 793 (and 1122, and...)? > ... > (1) - yes, but discouraged in spirit by RFC-1122's *should* > clauses regarding delayed acks. Depends on how you interpret the fact that there's no minimum value required for the delay timer. (But I will admit that interpreting zero as being just fine is a tad squirrely. :-) > 2) Are we violating fairness/Are we sure that it won't > degrade performance for other connections on shared paths? > ... > (2) - Is it OK for some connections to be more aggressive than > others? If so, how does a client *know* that it traversing > a long delay path instead of a terrestrial path? Where is > the proof that this is a safe thing to allow for general use? I should've been more clear - we don't just do this for satellite paths, we allow it for TCPs in general. > Finally, since "byte-counting" is the moral equivalent of acking > every packet No, it has a major difference. With byte counting, the window advances in bursts, and gets *burstier* when there's loss along the return path. (Byte counting is also clearly not consistent with existing RFCs. Note also that when most researchers do TCP simulations, they simulate ack-every-packet; it's already a de facto element of that part of the research community.) > I wasn't in Munich (although my slides were) and get feedback > telling me that both these possibilities met with some fairly > hostile response. That was the last time the subject was broached > in this forum - have things changed? What has changed for me was Van Jacobson strongly arguing for ack-every-packet. I'm not fully convinced that it's sufficiently conservative (and a win), but am fairly convinced. So I wanted to float it by the list as part of my comments to see what others think. I'm also asking the Transport directorate for their views, to see what sort of consensus we have. > If the satellite subnetworks were guaranteed to be separated > from the Internet backbone (say, via a proxy or splitting gateway), Again, I'm not viewing ack-every in that context. Finally: I don't have my heart set on this! But am quite interested in exploring it as a standard mechanism, as it strikes me as (1) significantly improving performance, especially for high latency paths, (2) being basically already legal, (3) having the support of some eminent congestion control researchers. Vern
- comments on draft-ietf-tcpsat-stand-mech-04.txt Vern Paxson
- RE: comments on draft-ietf-tcpsat-stand-mech-04.t… Spencer Dawkins
- Re: comments on draft-ietf-tcpsat-stand-mech-04.t… Daniel R. Glover
- Re: comments on draft-ietf-tcpsat-stand-mech-04.t… Mark Allman
- RE: comments on draft-ietf-tcpsat-stand-mech-04.t… Falk, Aaron
- Re: comments on draft-ietf-tcpsat-stand-mech-04.t… Eric Travis
- Re: comments on draft-ietf-tcpsat-stand-mech-04.t… Ian McEachern
- RE: comments on draft-ietf-tcpsat-stand-mech-04.t… Eric Travis
- RE: comments on draft-ietf-tcpsat-stand-mech-04.t… Eric Travis
- Re: comments on draft-ietf-tcpsat-stand-mech-04.t… Peter Warren
- RE: comments on draft-ietf-tcpsat-stand-mech-04.t… Spencer Dawkins
- RE: comments on draft-ietf-tcpsat-stand-mech-04.t… Eric Travis
- RE: comments on draft-ietf-tcpsat-stand-mech-04.t… Spencer Dawkins
- Re: comments on draft-ietf-tcpsat-stand-mech-04.t… Jacob Heitz
- Re: comments on draft-ietf-tcpsat-stand-mech-04.t… Peter Warren
- Re: comments on draft-ietf-tcpsat-stand-mech-04.t… Vern Paxson
- Re: comments on draft-ietf-tcpsat-stand-mech-04.t… Vern Paxson
- Re: comments on draft-ietf-tcpsat-stand-mech-04.t… Mark Allman
- Re: comments on draft-ietf-tcpsat-stand-mech-04.t… Vern Paxson