Subject: RE: [NSIS] Reliable Transport for NTLP

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 14 Jul 2003 18:56:43 +0100

john,

i don't think there is anyone arguing at the moment that *all* 
signalling should be sent reliably.

so, i'm assuming the question on the table is:

a) should the NTLP provide only a single-shot message delivery
attempt (you-the-NSLP don't get any feedback on whether it worked, 
if you-the-NSLP want an acknowledgement you must get it from
your peer NSLP)

OR

b) should the NTLP also provide a service which allows an NSLP to
say "get this particular message to my peer or tell me if you
can't"

I can imagine doing a cost/benefit analysis of having (a) only
vs. having (b) as well. I can't imagine doing a _proof_ (since there
is no standard of proof to apply), but at least having a clear
question would be a start.

cheers,

robert h.

PS Incidentally, if we drop all reliability from the NTLP, drop 
bundling from the NTLP (as Melinda suggested), and drop refresh
reduction from the NTLP (as I believe it's a signalling
application function), would we still claim as a WG that we 
are using 2205+2961 as a starting point?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, July 14, 2003 18:50
> To: [email-masked]
> Subject: [NSIS] Reliable Transport for NTLP
> 
> 
> Hi All,
> 
> At today's meeting, Melinda pointed out that in her opinion, 
> reliable transport
> is not required for NTLP.  Rüdiger seemed to indicate that 
> there is not a
> significant cost to NTLP.  Unfortunately, there has been no 
> working group
> consensus that NTLP will be using reliable transport.  Also, 
> I feel that
> Rüdiger behavior was inappropriate for a professional 
> meeting.  I should have
> asked Rüdiger to display more professional courtesy at the mic.
> 
> However, my point is that the WG has not come to agreement that NTLP
> should use reliable transport.  In fact, there is a significant cost,
> in my opinion, in terms of setup time & latency.  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.  In 
> addition, needing
> to setup TCP connections during fast mobility can also be a problem.
> 
> My point is that I do not see the requirement for reliable transport
> in NTLP.  If there are parties interested in using reliable transport,
> the burden of proof is with them.  
> 
> Please note, that Henning has proposed that there may be some 
> advantageous
> of using a partially reliable transport mechanism, however, I think
> he has planned on providing more details to the list of how this could
> be achieved, as it was not completely specified in his draft.
> 
> John
> 
> _______________________________________________
> 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: [email-masked]
Date: Mon, 14 Jul 2003 22:30:37 +0200

Hi,

I would like to second Henning's opinion here, especially for core
networks. It seems that there would be parts of the network where peering
relations are stable enough for the cost of the overhead to be amortized
over many flows. I believe this would make it a worthwhile addition to the
protocol.

Sven

Henning Schulzrinne <[email-masked]>@ietf.org on 14/07/2003 20:33:12

Sent by:    [email-masked]

To:    [email-masked]
cc:    [email-masked]
Subject:    Re: [NSIS] Reliable Transport for NTLP

> in my opinion, in terms of setup time & latency.  I will outline a
scenario.
> Two end hosts, A & B, need to setup some signaling between them.  If TCP
> needed. If A & B are x NTLP hops away, they will need x TCP connections,
> between x+1 nodes, which is a significant problem.  In addition, needing

John, this is simply not true and has not been true in all of these
discussions. There has always been the assumption that connections are,
on average, already established since the number of peers in most cases
is bounded. There is no need to start from scratch for every session.

> the burden of proof is with them.

I'm not sure what the threshold of "proof" is. I thought we had
extensive, but inconclusive, discussions on how to address
fragmentation, flow control and congestion control in NTLP.

advantageous
> be achieved, as it was not completely specified in his draft.

Without trying to write a draft on the fly, here's the simple outline.
I really need a whiteboard here. There are three choices:

1) one message, no reliability: just forward and have NSLP or e2e
retransmission; subject to security issues such as DOS attacks, but
quick and low overhead.

2) one message pair per hop: adds reliability, but no delay. Doesn't
address DOS issues completely.

3) one message pair per hop + reliable protocol for large messages: adds
reliability; adds delay for large signaling message. Addresses DOS
issues better and.

---

From: [email-masked]
Date: Tue, 15 Jul 2003 12:03:54 +0300

Roland,

> Ok, to close these non-technical issue, maybe it is helpful for
> participants to read and follow RFC 3184/BCP 54 from time to time
> again. 
> http://www.ietf.org/rfc/rfc3184.txt

Thanks for posting this, this is a good thing to read.

John

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 15 Jul 2003 10:51:49 +0100

john,

> 
> My current working assumption is that NTLP works in a lightweight
> datagram mode with the possibility of a reliable model,  for example,
> provided by TCP / SCTP / etc.

for the avoidance of doubt, since you mention including the ability 
to use tcp/sctp:

does this mean that design approaches which include explicit peer-peer
connections for message forwarding, with the peer discovered by 
separate explicit discovery messages, are in scope for the working
group as possible solutions?

[i ask, since such approaches have been objected to in the past on
architectural grounds, but I can see no other way to re-use protocols
such as TCP.]

robert h.

---

From: [email-masked]
Date: Tue, 15 Jul 2003 17:19:06 +0300

Hi Robert,

> group as possible solutions?

I don't object on principle, but I have concerns if we can do this cleanly 
or not, therefore I am looking forward to seeing how we can do this 
cleanly.

John

---

From: "karagiannis" <[email-masked]>
Date: Thu, 17 Jul 2003 07:33:22 +0000

Hi Henning 

Regarding the reliability issues, I think that the Melinda`s proposal 
which was stated during the NSIS meeting of Monday, was right.
In order to make a decission on if per-hop realibility of some 
NTLP messages is needed, a motivation of its use is needed. 

Please note that in environments where performance in terms of delay 
is important, per-hop reliability (due to its complexity) is of less
importance.

Best Regards,
Georgios

Dr. ir. Georgios Karagiannis
Group: Design and Analysis of Communication Systems (DACS)
University of Twente
The Netherlands

---

From: [email-masked]
Date: Thu, 17 Jul 2003 11:49:04 +0300

Hi Marcus,

> > This sounds more & more like operational issues with the protocols or 
> > issues how the protocol can be run over specific layer-2s or in 
> > special deployments.  I think, but I could be wrong, that these
> > belong best outside of the protocol document, but in an operational
> > doc, deployment doc, applicability statement, bcp-type document,
> > for example.
> 
> Sure they partly are. But some of the knobs might be turned using the 
> NTLP protocol, thats where we need decisions.

Yes, the devil is in the details, so maybe we need to take this as a
case-by-case basis during the protocol design.

> > The end-user is requesting services authorized for the service and is 
> > in the best position to know what is his expectations for  the service.
> > I have an allergic reaction to the suggestion that the network better
> > understands my wants / my needs as an enduser than I do.  However,
> > I could be mis-interpretying your comments.
> 
> So do you want to specify as a user whether we should use reliable NTLP 
> or not?

Well, there may be an operational mode that the TCP setup time may be an
issue; fast mobility may be one of them.  We could hypothesize about
these, perhaps these are issues that the NSLPs should consider as they
start their work and make recommendations to the NTLP authors.

John

---

From: "karagiannis" <[email-masked]>
Date: Thu, 17 Jul 2003 09:29:17 +0000

Hi John

>start their work and make recommendations to the NTLP authors.

I agree! 

Best regards,
Georgios

---

From: [email-masked]
Date: Thu, 17 Jul 2003 20:30:34 +0300

Hi Marcus,

> > I definitely agree that NTLP-over-foo/NTLP-in-bar-environments
> > information should be in separate documents. But, if the
> > NTLP base specification lacks the necessary capabilities,
> > such documents would be hard to write.
> 
> Basically the question I have is who makes the decisions on 
> what mode of 
> operation the NTLP is running on, and what are the criterions.
> 
> > John, Marcus - have I just violently agreed with both
> > of you, or is there a real issue here?
> 
> As far as I understood John he is not willing to let the 
> network decide on that.

That may be too strongly stated.  I think the endpoints should
decide in the cases that matter.  I don't want to apply a blanket
statement untill I see the proposals.

John

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 21 Jul 2003 15:50:28 +0200

Scott,

valid statement. I'd like to point out to
draft-pan-nsis-rsvp-transport-00.txt. It says:

---begin quote---------

2.4. RSVP-TE vs. Signaling Protocol for Real-Time Applications

   RSVP-TE works in an environment that is different from what the
   original RSVP has been designed for: in MPLS networks, the RSVP
   sessions that are used to support Label-Switched-Paths (LSP's) do not
   change frequently.....[snip]

   On the other hand, in many of the new applications where a signaling
   protocol is required, the user session duration can be relatively
   short. The dynamics of adding/dropping user sessions could introduce
   a large number of "triggered" messages in the network. This can
   clearly introduce a substantial amount of processing overhead to the
   routers. This is one area where a new signaling protocol may be
   needed to reduce the processing complexity in the resource
   reservation process.

------end quote-----

As I mentioned in another mail, I think reliablbe transport isn't required 
if there's a "low" amount of signaling to be processed. If NSIS will be 
designed to prevent a "high" signaling load in backbones, I guess I 
won't have a problem. Besides RSVP TE (and DiffServ aware TE) there's also 
RFC 3175 ( aggregated RSVP). Both aim on rather stable state in the 
backbone by flow aggregation. 
Backbone load reduction is a "SHOULD" in the requirements, pointing to 
the framework for details. I was not able to clearly identify them. I'm 
concerned that NSIS is focused too much on end-system based signaling and 
might fail on the edge to edge part.  

Regards, Rudiger

|-----Original Message-----
|From: Scott W Brim [mailto:[email-masked]]
|Sent: Monday, July 21, 2003 1:14 PM
|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
|

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 22 Jul 2003 11:25:53 +0100

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.

> From: Scott W Brim [mailto:[email-masked]]
> Sent: Monday, July 21, 2003 12:14
> To: [email-masked]
> 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
>

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 23 Jul 2003 12:42:41 +0200

Hello Attila

|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.

I don't remember any past consensus on the issue. I'd like to 
add that part of the problem is that re-inventing reliable 
transport (or other interesting TCP/SCTP features) on higher 
layers like NSLP probably isn't felt to be desirable by all.

Regards, Rüdiger

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 23 Jul 2003 22:31:56 +0100

Hi Henning,

As usual, there is more than one question here.

I'm also not a fan of relying on only 'end-to-end'
(in the sense of first-NSIS-node-to-last-NSIS-node)
reliability.

However, even if we agree that a signalling application
needing reliability needs it between (say) adjacent NSLP
peers rather than simply end-to-end, there is still the 
question of which layer it should be provided at (NTLP
or within each application).

I argued in my email to Scott that there were good
reasons why this functionality should be part of the 
NTLP. I'd be interested in views on whether those
arguments were valid (or what other arguments were 
valid). I think the practical consequence would be that
some form of reliable message transport (*) would be
mandatory functionality in the NTLP, optional for an
NSLP to invoke on a message-by-message basis.

cheers,

r.

(*) coupled ideally with some form of express routing
to bypass intermediate nodes between the NSLP peers.

-----Original Message-----
From: Henning Schulzrinne
To: "Attila Báder (ET/ETH)"
Cc: Hancock, Robert; [email-masked]
Sent: 23/07/2003 18:25
Subject: Re: [NSIS] Reliable Transport for NTLP

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...

Attila Báder (ET/ETH) wrote:

> 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

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 25 Jul 2003 11:35:08 +0100

dear all,

just as an fyi, i am planning to write a small analysis draft
on the reliability issue during august, which would hopefully
summarise what we have and have not agreed and what questions
still need to be answered once and for all. it will also 
contain a proposal on this issue and the layer split. I hope
that sounds like a good idea.

if anyone has pointers to information that I should consider
(e.g. in particular whatever was 'in the air' at the time 
2961 was being put together, anything with quantitative
analysis of rsvp behaviour/known problems) I'd be very interested
to hear it.

r.

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, July 24, 2003 14:44
> To: Thanh Tra LUU
> Cc: "Attila Báder (ET/ETH)"; [email-masked]
> Nary Tra,
> in order to make progress in this WG, we have to keep from 
> repeating the 
> same non-disagreements again and again. Nobody here, as far as I can 
> tell, is suggesting that TCP be mandatory to support or use for a 
> particular NSLP, only that it (or similar protocols, such as SCTP or 
> DCCP) are appropriate parts of the tool kit.
> 
> You may also find it interesting to read some of the proposals that 
> indicate how router alert options are being used. The two issues are 
> orthogonal.
> 
> Maybe we need a FUD FAQ :-)
> 
> Henning
> 
> Thanh Tra LUU wrote:
> 
> > hi Attila,
> > 
> > I am a fan of E2E reliable delivery but I don't agree with 
> your idea.
> > If TCP is used, reliable delivery is always used even though your
> > signaling application needs it or not. It belongs to lower layer and
> > there is no relationship between stateless attribute and lower layer
> > here.
> > 
> > I feel that TCP is something too 'solid' and not flexible. If TCP is
> > used, signaling application must bear all the security 
> attacks of this
> > protocol (e.g. SYN TCP attack). It will be easier for attack a
> > signaling aware node because a packet can be sent from a 
> distant host
> > to a signaling node on the data path without Router Alert 
> Option being
> > set.
> > 
> > I'll try to find some more arguments for using IP or UDP as a lower
> > layer of NTLP.
> > 
> > Nary Tra,
> > ENST, Paris
> > 
> 
> 
>