Do you really think that yet another transport protocol can be
designed built and deployed in the world wide Internet any quicker?
Even considering a move to IPv6?
Well, I think it may require quite a few years to migrate to IPv6. So maybe
there's time to prepare a transport protocol.
It will require a good 2 years or so to get the specification done,
then you have bikeoffs (with respects to pillsbury :->) and of
course you must rally support so that it gets developed so you
have enough bikes to race :)
[ Well, I'm managing to rally support somewhere:-) ]
I don't see how you can propose a new protocol and get it out
any quicker than you will see SCTP deployed...
Mmm...
As far as I can perceive I think SCTP is by now the optimum in the IPv4
internetworking environment. But it was contrained by the incumbent
Internet. For example it didn't assume adequately deployment of ECN
But I have to admit again that no way may prevent SCTP from exploiting ECN.
[I noted that SCTP has for example reserved 'chunk ID' for 'Explicit Congestion
Notification Echo' and 'Congestion Window Reduced'.]
As SCTP has to overcome TCP in the IPv4 internetworking environment
(well, this argument seems just an assumption) I don't think it will be widely
deployed in the incumbent Internet.
If the 'Interface with Upper Layer' were to provide downward comptibility
with TCP (where ATP is intent to), SCTP might be definitely quicker.
I think XTP is low efficient. SCTP is a functional superset of TCP,
RTP+UDP and RTSP+UDP in the unicast scenario.
Yes, SCTP shares a lot in common with TCP but there are some
striking differences.
I agree.
No, the problem was that we could not mandate SCTP to use ECN because
ECN was an Experimental RFC. Has such we had to stand on our head
to get it in and not have a normative reference. I think you
will find that in the BIS we will require an SCTP implementation
to have ECN.
Even at that you can NOT solely rely on ECN since it is NOT fully
deployed into the Inter-net. You must keep the packet loss is a
signal of congestion.
Even if ECN were magically deployed everywhere tommorrow, you still
have a problem. What happens when a router gets a BURST of traffic
that exceeds its buffers. It MUST DROP packets if it runs out
of buffer space. A lost packet needs to be intrepreted as a congestion
event.
ATP bets on wide deployment of ECN in the next generation Internet. I uphold
ECN so strongly that I believe it should be mandatory in the IPv6
internetworking
environment. And I can't object to the opinion that the bet might fail.
If it is a burst of traffic cause a router drop packets, maybe it is better not
to
feedback the congestion, for quite likely the congestion will disappear after
the
burst, before the feedback makes the sender lowers its trasmit rate. The router
may choose to randomly set the ECN flag on only a small set of packets. And
the receiver may choose to ignore burst ECN signals. It is not prohibitively
difficult
to detect the burstiness.
I think there may be other ways of detecting a corrupted
packet that may be employed... HACK TCP and similar items.. but there
still needs to be more research ...
I think it implies that we all agree that it is important to differentiate
packet loss
due to congestion from that due to link layer error.
We discussed this in sigtran... question? How do you know (from the
receiver side) that you are missing a packet?
You setup a connection with me.
Send me something.
I respond.
You send somthing else, to make an additional request, one I
am unaware you are going to make. How do
I know to ask you for a retransmission when that packet is lost?
Send me something(with a packet sequence number N).
I respond.
You send something else, unfortunately it is lost.
I (the receiver) timeout. I send (and may resend) you NAK:
"Hi! I haven't got your message for quite a long time(since I got previous
packet sequence number N). What's the matter?"
[ In ATP it's more alike this:
"Hi! I haven't got your message with sequence number N+1 for quite a long
time.
Is it lost?"
And it may act as the keep-alive signal as well.]
...
I mean, no, the receiver alone never know whether a packet is lost or not.
But the cooperation between the receiver and the sender may.
But why the receiver timeout instead of the sender? The upper layer application
congestion.
In ATP the receiver may detect the upper layer application congestion (in a
common multi-thread host system) and deliberately deny a packet it has received
but not accepted yet. By sending back a explicit congestion feedback and a
negative acknowledgement the receiver makes the sender both slow down and
retransmit the unaccepted packet as soon as possible. The sender waits the
round trip time. It is expected to be faster than letting the sender timeout.
4. SCTP supports multi-streams in a single connection.
I cannot perceive the necessity clearly.
Look at head of line blocking. This will explain the
item you are missing. A telephone example works best
but it can also be applied to HTTP or many other apps.
I have a connection carrying control information on
20 phone calls, Setup, teardown, addtional info etc.
Now The first packet (a setup on call 1) is lost. But
setup for call 2, 3 and 4 (in subsequent packets) are
received at the server. The TCP connection will hold
these packets awaiting the retransmission of call 1's packet.
In SCTP you would use seperate streams for each of the
calls (or some subset) and thus call 2,3 and 4 would
not be held up.
HTTP has a similar problem when downloading jpeg's and
other pieces.
I see.
Regards,
Gao.