Subject: RE: [NSIS] Reliable Transport for NTLP

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 21 Jul 2003 11:30:47 +0200

John,

|I will 
|outline a scenario. Two end hosts, A & B, need to setup 
|some signaling between them.  If TCP is used as a transport,
|it is not a simple 3 way handshake that is needed. If A & B 
|are x NTLP hops away, they will need x TCP connections,
|which, depending upon implementation, will result a 3 way handshake 
|between x+1 nodes, which is a significant problem.

"Reliable transport" for signaling applications is an issue whith
ample operational and implementation experience. Hence I'd suggest 
that we stick to the "lessons learned" paradigm instead
of constructing abstract scenarios. I've e.g. refered to BGP and LDP 
as signaling protocols making use of TCP. 
I'd ask you to point out issues with TCP transport based on past
experience. I'd appreciate if you could  

- provide reference to any signaling protocol which wasn't deployed in 
  backbone networks due to TCP transport.

- provide reference to a TCP based backbone signaling protocol which 
  will result in an NSIS signaling failure due to TCP transport.  

When answering, please keep in mind that I'm not asking to have NTLP 
reliable transport as the only allowed mode of operation. 

Regards, Rüdiger

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Scott W Brim <[email-masked]>
Date: Mon, 21 Jul 2003 13:13:49 +0200

> reliable transport as the only allowed mode of operation.

A casual lurker speaks up ...  I think the questions are extreme -- can
you provide an example of a protocol which will fail because it does
*not* run over TCP?  Bad protocols don't get far enough for these
questions to be asked.  Thus I consider them rhetorical.  However, if
you want to consider advantages/disadvantages of TCP, consider CR-LDP
versus RSVP-TE.  CR-LDP used a TCP session.  RSVP-TE used its own
reliability mechanisms and did not ask for reliability in its lower
layer.

TCP is designed for stream reliability, not for transaction reliability.
RSVP-TE was able to tune its own timers for its own needs, instead of
using those optimized for the general case of an average application.
It had control over whether, in a retransmission, the same message was
retried, or a new, more up-to-date message was attempted instead.  It
was able to provide more control plane predictability because messages
did not necessarily have to wait for previous messages to be
acknowledged.  When connectivity was lost and thousands of updates
needed to be sent, it could choose whether to serialize them all at the
transport layer (as LDP did with a single TCP connection) or send
some/many in parallel (serializing at the link layer).

People did not reject CR-LDP because it ran on TCP.  However, the fact
that it did was not seen as an advantage.

..swb

---

From: Scott W Brim <[email-masked]>
Date: Mon, 21 Jul 2003 12:18:31 +0200

..swb