In message <[EMAIL PROTECTED]>, Keith Moore typed:
>>I don't agree that abundant IPv6 addresses remove the need for something
>>akin to a port number. They might remove the need for transport-level
>>multiplexing, but only if any host could allocate a sufficiently large
>>subnet, and it's
> I think it would be very difficult to replace TCP. However, a new
That's true. But I don't think it's harder than replacing IPv4 with IPv6.
> transport protocol that worked better than TCP in very high bandwidth /
> low delay conditions might be very attractive for hosts and applications
> th
> General Question:
> - How to migrate?
> I have been using the "QWERTY" keyboard all the time.
> I am aware that it is not the best, but I am stuck.
So a set of APIs must be defined. They should be downward-compatible with basic socket
APIs supporting TCP.
Because ATP is optimzed for IPv6, a
At 22:46 06/02/2001 -0500, Keith Moore wrote:
>p.s. Personally I'm interested in a transport protocol for the other end
>of the spectrum - something which has the order-preserving, duplicate
>suppressing, and clean open and close properties of TCP but which can
>exchange small amounts of data in o
General Question:
- How to migrate?
I have been using the "QWERTY" keyboard all the time.
I am aware that it is not the best, but I am stuck.
Jun'an Gao wrote:
> 4. Each time the client end initiates a new connection it
>will allocate a new IPv6 address. The allocation may
>be don
--> stanislav shalunov writes:
>Larry Foore <[EMAIL PROTECTED]> writes:
>
>> How often would a single TCP session have allocated to itself an
>> entire gigabit link?
>
>At SC2000 there was an application (non-interlaced HDTV) using
>1.5Gbps.
Sure, but it wasn't using TCP...
Colin
I think it would be very difficult to replace TCP. However, a new
transport protocol that worked better than TCP in very high bandwidth /
low delay conditions might be very attractive for hosts and applications
that were able to take advantage of it.
I don't agree that abundant IPv6 addresses r
Jun'an Gao wrote:
>>> it is probably better to do traffic shaping at the service provider
network edge, for some reason of accouting, congestion control, or required
by service-level-agreement
Or possibly at the carrier or access network edge. Carrier networks are not
necessarily owned by the s
>> 6. Doing traffic shaping at the network edge is better than on the host node for
> The host *is* the edge of the network.
I'm sorry to have not mentioned that I consider the host nodes, or the end nodes, are
not network edge but instead something attached on the network edge. I consider the
Well, I believe I have read rfc1323:-) I think I should give a short comparison
between ATP and the enhancements of TCP (The enhancements include ECN.). I'll make the
comparison(it may take me quite a few days for I 'm not a fluent English writer:-( )
after I have fully translated and posted th
>> 6. Doing traffic shaping at the network edge is better than on the host node for
> The host *is* the edge of the network.
I'm sorry to have not mentioned that I consider the host nodes, or the end nodes, are
not edges but instead something attaching on network edges. I consider the very last
>> 6. Doing traffic shaping at the network edge is better than on the host node for
> The host *is* the edge of the network.
I'm sorry to have not mentioned that I consider the host nodes, or the end nodes, are
not edges but instead something attaching on network edges. I consider the very last
> i hope you know about RFC1323 ftp://ftp.isi.edu/in-notes/rfc1323.txt
Well, I believe I have read rfc1323. I think I should give a short comparison between
ATP and the enhancements of TCP (The enhancements include ECN.). I'll make the
comparison(it may take me quite a few days for I 'm not a fl
Larry Foore <[EMAIL PROTECTED]> writes:
> How often would a single TCP session have allocated to itself an
> entire gigabit link?
At SC2000 there was an application (non-interlaced HDTV) using
1.5Gbps.
A web search brings up this:
http://ssadler.phy.bnl.gov/adler/sc2k/sc2kpg3.html
> This messa
Larry Foore wrote:
> Is this really a problem? How often would a single TCP session have
> allocated to itself an entire gigabit link? I'm not aware of any end
> systems or apps that generate data at this rate (especially for any
extended
> length of time), much less accept it. Maybe I'm lookin
>1. There are two annoying incompetence of TCP. One is that TCP does not
> distinguish packet loss caused by network transmission error from that
> caused by network congestion. The congestion control and avoidance
mechanism
> makes TCP drop its transmit window upon detecting a packet loss,
> One could argue that it's a responsibility of wireless
> link-layer protocols to ensure that random loss is rare (say,
> by employing an ECC).
For slow links, maybe. But TCP's congestion avoidance algorithm does
make the assumption that 90%+ of the losses are caused by congestion,
not link er
[EMAIL PROTECTED] (Jun'an Gao) writes:
> There are two annoying incompetence of TCP. One is that TCP does
> not distinguish packet loss caused by network transmission error
> from that caused by network congestion.
But ECN seems to address this issue, and it can work for UDP as well
as TCP.
>
Jun'an Gao wrote:
> 6. Doing traffic shaping at the network edge is better than on the host node for
The host *is* the edge of the network.
--
/=\
|John Stracke| http://www.ecal.com |My opinions are my own. |
|Chief Scientis
On Tue, 06 Feb 2001 22:30:06 CST, [EMAIL PROTECTED] (Jun'an Gao) said:
> 1. There are two annoying incompetence of TCP. One is that TCP does not
>distinguish packet loss caused by network transmission error from that
>caused by network congestion. The congestion control and avoidance mech
Motivations
1. There are two annoying incompetence of TCP. One is that TCP does not
distinguish packet loss caused by network transmission error from that
caused by network congestion. The congestion control and avoidance mechanism
makes TCP drop its transmit window upon detecting a pac
21 matches
Mail list logo
