Subject: RE: [NSIS] Reliable Transport for NTLP

From: Attila Báder (ET/ETH)<[email-masked]>
Date: Wed, 23 Jul 2003 11:38:46 +0200

Hi Robert and All,

I also think the question is very fundamental. Since NSIS addresses wider range of applications, most probably there will be NSLPs which like to use retransmission-like reliability, while other concepts intend to support reliability like RSVP does. Certainly both have advantages and disadvantages and it depends on the applications.

In my view this latter is closer to the original concept of soft states and using RSVP as a base. Our stateless concept for example needs the simplest transport as possible and it may be reasonable for other NSLPs as well. I am afraid that if retransmission is a common service of NTLP, even if it is optional to use, it introduces unnecessary implementation complexity.

The question can be put in another way as well: Should NTLP have optional features that can be invoked by different NSLPs, or NTLP should be a protocol supporting common basic features and optional feature are only in NSLP? I do not remember if we had a consensus regarding this question.

Best regards,  Attila

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Hancock, Robert
> Sent: Tuesday, July 22, 2003 12:26 PM
> To: 'Scott W Brim'; [email-masked]
> Subject: RE: [NSIS] Reliable Transport for NTLP
> 
> 
> Scott,
> 
> You raise some interesting points, but I'm not sure which direction 
> the argument leads in.
> 
> It seems clear that the argument is not about whether reliability
> is needed for signalling messages - indeed, as you point out, both
> CR-LDP/RSVP-TE provided this, just in different ways. What's at issue
> is how to provide it (when it is needed), which is itself 2 questions
> in this working group context:
> a) whether to provide it as a common service (in the lower layer NSIS
> protocol), or whether to build it separately into each signalling 
> application that wants it
> b) whether to do a customised NSIS design, or whether to re-use an
> existing transport protocol.
> 
> The open question which is the biggest barrier to progress at the 
> moment is actually (a), because it hinders us from splitting 
> up design work
> between NTLP and NSLP.
> 
> My personal view is that there are strong arguments for providing 
> reliability as a (shared but optional) lower layer service, 
> because e.g.
> *) retransmission behaviour has to be sensitive to network layer load
> (congestion avoidance), which I see as a general lower layer function;
> *) retransmission has to distinguish somehow between congestive loss
> and loss caused by next-peer change, which is also a lower 
> layer function;
> *) in a multi-signalling-application environment there are gains from
> sharing the state required for reliability between applications;
> ...and so on.
> 
> And I also think that different signalling applications
> will not have wildly different reliability requirements, so a common
> service makes sense. I suspect that SCTP (including partial
> reliability extensions) or something home-made on top of DCCP would be
> a better match to those requirements than TCP, but that's a later
> question (and you could still also do something completely home-made, 
> like 2961 did).
> 
> So far as the MPLS experience is concerned, there is one aspect of the
> environment which makes me wary of taking it too directly. 
> AFAIK, RSVP-TE
> requires next-IP-hop routers to be RSVP-TE aware; in other 
> words, reliability,
> congestion control, etc. etc. have to be provided over a single L2 hop
> (whose characteristics you know pretty well). That's a much 
> much simpler
> environment than the NSIS one, where many of the likely 
> scenarios involve
> large numbers of NSIS-unaware intermediate nodes. The design 
> approach that 
> "When connectivity was lost and thousands of updates needed 
> to be sent,
> [RSVP-TE] could choose ... to send some/many in parallel" starts
> to sound dangerous here.
> 
> cheers,
> 
> r.
> 
> 
> > -----Original Message-----
> > From: Scott W Brim [mailto:[email-masked]]
> > Sent: Monday, July 21, 2003 12:14
> > To: [email-masked]
> > Subject: Re: [NSIS] Reliable Transport for NTLP
> > 
> > 
> > On Mon, Jul 21, 2003 11:30:47AM +0200, Geib, Ruediger 
> allegedly wrote:
> > > "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.
> > 
> > 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
> > 
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> > 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 23 Jul 2003 13:25:07 -0400

At least from our implementation experience with a vaguely related 
protocol, the additional complexity of such choice is very modest (a few 
tens of lines of code and an additional table).

As I've said in an earlier message, I'd like to challenge advocates of 
only offering only end-to-end reliability to address even the simple 
issue of what RTT estimate to pick if nodes perform anything but trivial 
forwarding. NSIS nodes are not just dumb packet routers with microsecond 
latency...