On Jun 1, 2005, at 12:24 PM, Alex Tweedly wrote:
But compliance with "current standards" or with named standards (e.g.
UDP, TCP) changes over time.
Does this mean that new standards can and do change the meaning of the
term TCP? I didn't realize that.
I try to be hip but I'm just an old
Dar Scott wrote:
On Jun 1, 2005, at 9:23 AM, Alex Tweedly wrote:
rfc1122 is a full IETF standard, and so the requirements it places on
host implementations of TCP are part or the official definition of TCP
...
A TCP MUST implement this algorithm.
That is an interesting interpre
On Jun 1, 2005, at 9:23 AM, Alex Tweedly wrote:
rfc1122 is a full IETF standard, and so the requirements it places on
host implementations of TCP are part or the official definition of TCP
...
A TCP MUST implement this algorithm.
That is an interesting interpretation.
I read that l
MisterX wrote:
actually, there's lots more than just that...
TTLs (time to life), frame sizes, packet fragmentation, packet resends,
routing, firewall configs (yes!), proxys (cache problems?), etc...
Hey - you missed packet schedulers (Packeteer, etc.), VPN frame
overhead, ATM cell tax, VJ
Dar Scott wrote:
slow start undoubtedly is part of TCP proper;
Huh? It is not in rfc 793.
That means that it was not part of the original TCP standard.
I guess it's the usage of that word "proper" :-)
1122 is an IETF standard, and so anything it says is a requirement for
host TCP implemen
gt; From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Dar Scott
> Sent: Wednesday, June 01, 2005 15:15
> To: How to use Revolution
> Subject: Re: Broadband Optimizer for Revolution?
>
> Since I'm contributing to clutter on this list, I should say
> t
Since I'm contributing to clutter on this list, I should say that I've
realized that "transmit window" is a parameter in sender TCP flow
control used in some implementations and is implied in implementation
standards.
Dar
___
use-revolution mailing
On Jun 1, 2005, at 4:06 AM, Alex Tweedly wrote:
"transmit window" came into common usage sometime around the early 90s
- to refer to the sender's view of the congestion window. An
application trying to figure out if it is near to congestion (and
perhaps vary the info it is sending accordingly
Dar Scott wrote:
I couldn't find any reference to "transmit window" or "slow start" in
rfc 793. I don't see how it's part of TCP, proper.
"transmit window" came into common usage sometime around the early 90s -
to refer to the sender's view of the congestion window. An application
tryin
Alex-
Yes - this is quite true. Ignore my previous ramblings about the
sliding windows.
--
-Mark Wieder
[EMAIL PROTECTED]
___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution
On May 31, 2005, at 5:20 PM, Alex Tweedly wrote:
Well, I have had my caffeine, so I have no excuse, but I don't know
what transmit window is.
The TCP window is controlled by the receiver.
Not entirely. The "Window" field in the TCP header is indeed the
receiver's definition of the number of
On May 31, 2005, at 3:53 PM, Mark Wieder wrote:
DS> (To me it seems strange to call the MTU a transmit window.)
Here's my understanding of this - I'm sure someone will correct me if
I'm too far off - there's a maximum transmit window size and a maximum
receive window size. You can crank your r
Andre Garzia wrote:
Dar,
Sometimes I wonder why standards exists...
to keep standards writers in a job :-)
doing a simple googling on this topic I grooked that at least *BSD and
Windows2000 got settings for TCP Windows for receiving and for sending
data, I guess this must just be different
Mark Wieder wrote:
Dar-
Tuesday, May 31, 2005, 12:28:30 PM, you wrote:
DS> Well, I have had my caffeine, so I have no excuse, but I don't know
DS> what transmit window is.
Maximum Transmission Unit (MTU):
Wait ! Stop right there !
Oops - too late - there are already more emails in this
Mark Wieder wrote:
Alex-
Tuesday, May 31, 2005, 10:41:12 AM, you wrote:
I'd also think twice about increasing the size of the TCP transmit
window in any case. The receive window should be fine, but to my
caffeine-deprived brain this morning I think increasing the TCP
transmit window without a
Dar Scott wrote:
On May 31, 2005, at 12:43 PM, Mark Wieder wrote:
I'd also think twice about increasing the size of the TCP transmit
window in any case. The receive window should be fine, but to my
caffeine-deprived brain this morning I think increasing the TCP
transmit window without a corre
Dar-
Tuesday, May 31, 2005, 2:34:59 PM, you wrote:
DS> I don't think that a large MTU would hurt the receive window.
No, but...
DS> Perhaps Andre is right in that these mean buffer sizes for transmit.
DS> (To me it seems strange to call the MTU a transmit window.)
Here's my understanding of th
On May 31, 2005, at 2:52 PM, Mark Wieder wrote:
DS> Well, I have had my caffeine, so I have no excuse, but I don't know
DS> what transmit window is.
Maximum Transmission Unit (MTU):
Ah. That I know. I imagine that if I was paying attention I would
have known that's what you were talking a
On May 31, 2005, at 1:41 PM, Andre Garzia wrote:
I guess this must just be different buffer sizes ain't so?
I think that is a good guess for one, probably the send.
Dar
--
**
DSC (Dar Scott Consulting & Dar's Lab)
http://www.swcp.com/dsc/
Dar-
Tuesday, May 31, 2005, 12:28:30 PM, you wrote:
DS> Well, I have had my caffeine, so I have no excuse, but I don't know
DS> what transmit window is.
Maximum Transmission Unit (MTU):
http://www.dslreports.com/faq/7801
http://www.erg.abdn.ac.uk/users/gorry/course/inet-pages/mtu.html
http://se
On May 31, 2005, at 4:28 PM, Dar Scott wrote:
Am I too focused on the TCP standard and am missing the real world
implementations?
Dar,
Sometimes I wonder why standards exists...
doing a simple googling on this topic I grooked that at least *BSD and
Windows2000 got settings for TCP Window
On May 31, 2005, at 12:43 PM, Mark Wieder wrote:
I'd also think twice about increasing the size of the TCP transmit
window in any case. The receive window should be fine, but to my
caffeine-deprived brain this morning I think increasing the TCP
transmit window without a corresponding increase i
Alex-
Tuesday, May 31, 2005, 10:41:12 AM, you wrote:
I'd also think twice about increasing the size of the TCP transmit
window in any case. The receive window should be fine, but to my
caffeine-deprived brain this morning I think increasing the TCP
transmit window without a corresponding increase
[EMAIL PROTECTED] wrote:
Can anyone tell me if there's a way that I could replicate the Mac OS X
"Broadband Optimizer" app, that's found at this link:
http://www.enigmarelle.com/broadbandoptimizer.py
It's an app the increases the size of the TCP/IP packets of Mac OS X.
Actually (according
On May 27, 2005, at 12:06 PM, [EMAIL PROTECTED] wrote:
Can anyone tell me if there's a way that I could replicate the Mac OS X
"Broadband Optimizer" app, that's found at this link:
http://www.enigmarelle.com/broadbandoptimizer.py
It's an app the increases the size of the TCP/IP packets of Mac
25 matches
Mail list logo
