* well-known, but some RFCs such as those on OSPF may be much
* more vivid if written in XML. There have been quite a few
Vivid? We are talking about deeply complex technical documents
here, not MTV. What do you mean, "vivid"?
Maybe, we can display, say, an example of routing
Assumption:
Total Comprehensiveness of RFCs
= SIGMA { interest on RFC#i of reader#j
* familiarity on the presentation format of RFC#i of reader#j
}
for i = 1 to number of RFCs, j = 1 to number of readers.
Argument:
Some RFCs can be well-written in simple ASCII and become
Yet maybe we can safely assume that most of the people who are
interested in the Internet are, or will be in a short time, familiar
with XML documents.
where do you get that idea?
Absolutely not from IETF maillist.
And there're so many internet sites other than www.ietf.org.
Repeat after me:
Everybody can display ASCII. Until everybody can display XML, we won't
be using XML for the canonical form for RFCs. This is *different* than
what Marshall Rose did in RFC2629 - note that that document is itself
*flat ascii* describing how to write XML and *then convert
you should probably redirect this conversation to
the end2end-interest list:
[EMAIL PROTECTED]
the entire IETF list is probably the wrong place for substantive technical
discussion of this type.
I agree.
I've subscribed to [EMAIL PROTECTED] by visiting
My bottom line thoughts after having scanned thread is
have you looked at SCTP? We have just finished almost
2 years of work and it solves some if not all of your
issues...
Before I posted the long (and maybe annoying~_~) essays about ATP
I've reviewed a few of the articles about the
ATP Header Format
The IPv6 packet whose payload contains an ATP packet must conform to latest IPv6
specification, currently RFC 2460. ATP suggest that the traffic class field should
renamed to 'flags'. The leftmost bit could be RTP(real time payload), the rightmost be
ECN(Explicit Congestion
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 hub, or the access router
which the end nodes connected to as the 'network
if you are proposing that the IETF should investigate ATP, have you
submitted the proposal as an internet-draft?
No.
If not, why not?
I myself have some unsureness on ATP.
1. There're too many contraints in the tranditional TCP/IPv4 internet environment. So
ATP is going to be optimized for
It is very hard to read your valuable contributions because you aren't
sending pre-formatted text, rather one line per paragraph.
I'm very sorry! I'll resend part 2 after I pre-format it.
I have a question:
If the traffic class field in the IPv6 header was changed, as suggested, to
a set of flags, then how would a full gammit of differentiated services be
indicated? In other words, if there is only one flag indicating type of
service, then different levels of, for example,
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
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
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
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
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
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, and
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
that
19 matches
Mail list logo
