Subject: RE: [NSIS] comments on NTLP design proposals

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 11 Jul 2003 00:29:44 +0100

hi john,

> Some random thoughts / comments. I've clipped the bits of your
> mail that I am replying to, complete email is left unmolested.

and it is grateful for that...

> 
> > 1. The single most important issue seems to me to be how the
> > 'core' transport functions should be provided. 
> 
> Perhaps you should define what you mean by 'core' transport functions.

i suppose the most objective definition would actually be 'the difficult
ones', i.e. ones which are hard to define correctly, but which are
already provided in other protocols. 

head of my list would be congestion control and DoS protection (from
initialisation floods). Message number management (including non-cryptographic
replay protection) can also be tricky.

Fragmentation/reassembly (and the associated PMTU discovery), multiplexing,
and (optionally) selective reliability and flow control would probably come
into several people's core list; however, I think of them as more just
'nice to be given' since they aren't so hard to design oneself given the
other functionality described above - you don't need several decades' worth 
of experience just to avoid making horrendous errors. (Maybe fragmentation/
reassembly is a borderline case here - it's interesting that the DCCP people
left it out.)

> 
> > It may be that (b) is ruled out by the terms of John's 'Starting
> > NTLP Work' slide from San Francisco, but I can't see that the others
> > are. 
> 
> (b) is ruled out by our charter.  If we want a clean sheet approach,
> we need to demonstate why something like 2205+2961 is not sufficient
> for the task at hand.
> 
> > So, maybe (d) would be nice. Unfortunately, I think (d) is 
> > impossible using a fully reliable transport; 
> 
> Using a fully reliable transport option as a starting point requires 
> proof that reliable transport is needed.  I have yet to see good
> justification that a relaible transport is required.  My gut 
> feeling is that we start with a connectionless protocol and see how & 
> if a connection-oriented protocol can be supported.

Whether or not this is true, it's orthogonal (i.e. irrelevant) to the
point I was making: if you want to re-use an existing transport, you
probably can't retain having a PATH-like message if you reuse an existing
reliable transport (regardless of whether or not you want its reliability
properties). But you could re-use an unreliable transport. 

r.

As an aside, what exactly do you mean by 'connectionless' and
'connection-oriented'? Are you using them as synonyms for 'unreliable'
and 'reliable'? Or do you mean connectionless as 'holding no per-peer state'?
Is 2961 connectionless in your book? (It has selective reliability and
manages per-peer state, after all.)

> 
> John
> 
> 
> > -----Original Message-----
> > From: ext Hancock, Robert [mailto:[email-masked]]
> > Sent: 10 July, 2003 12:50
> > To: [email-masked]
> > Subject: [NSIS] comments on NTLP design proposals
> > 
> > 
> > Dear All,
> > 
> > I have some questions & observations about how we are proceeding
> > with the NTLP design process. (Most of them have been stimulated
> > in fact by reading Melinda's draft-shore-..., but the one I 
> > consider most important/interesting is actually pretty general,
> > and I've put it at the start.) I have been out of the office for 
> > a few days and am not fully up to date with the recent mailing list
> > discussions, so apologies in advance if any of what follows is
> > redundant with that.
> > 
> > 1. The single most important issue seems to me to be how the
> > 'core' transport functions should be provided. I can see (at
> > least) 4 options -
> > a) take existing protocol components straight out of 2205+2961, 
> > re-arrange them in the NSIS layer model, and add pieces for 
> > additional functionality needed.
> > b) do (a) but starting from a clean sheet, i.e. a new 'path coupled
> > transport protocol'.
> > c) build the NTLP out of an existing transport protocol, and live 
> > with a separated signalling transport and route discovery 
> > process.
> > d) do (c) but trying to keep the ability to have unified 
> > transport and route discovery (like PATH does today).
> > 
> > It may be that (b) is ruled out by the terms of John's 'Starting
> > NTLP Work' slide from San Francisco, but I can't see that the others
> > are. I feel that we need to bottom out this question before really
> > getting into the details of protocol design (message formats and
> > so on), since the 'shape' of the protocol depends so strongly on
> > it.
> > 
> > Just for the record, let me say that I can see the attraction of 
> > (a) in terms of providing a conceptual starting point. However, I
> > have a suspicion that extra functionality - fragmentation, 
> > better congestion control, protection against 
> > denial-of-service attacks, pmtu discovery,
> > and so on - will be hard for us to design and hard to build into
> > the protocol in a nice way. (Another side effect of approach (a)
> > might well be that the NTLP inherits functionality which was 
> > natural in 2961 - like message summarisation, awareness of 
> > signalling application state - which shouldn't logically be there.)
> > 
> > On the other hand, I am not blind to the issues with (c), mainly
> > the need for a separate discovery procedure. I suspect it's 
> > impossible to provide a proof (which satisfies everyone) that this
> > doesn't matter.
> > 
> > So, maybe (d) would be nice. Unfortunately, I think (d) is 
> > impossible using a fully reliable transport; however, I'm now
> > pretty (90%) sure that something sensible can be done by
> > re-using DCCP, and selectively layering reliability on top
> > (where needed). (You could also use a different congestion response,
> > like TFRC, which might be nice. In fact, DCCP seems to have *lots*
> > of nice features...)
> > 
> > 2. In earlier days of the WG, we were careful to consider the
> > problems of signalling going through clouds which were not pure
> > IP DA routed (see also recent discussion on this list about
> > Allison's comments on the requirements). So, I'm nervous about
> > protocol designs which assume that the IP DA fully defines the
> > route taken by a flow (i.e. this is all you need in the PATH-like
> > message). [Even RSVP uses both the flow SA and DA in PATH messages.]
> > 
> > In fact, we have up to now had an object in the framework (the
> > flow id, maybe a better name would be 'flow routing information')
> > which supposedly exposed at the NTLP level all the information 
> > needed to work out where to send a signalling packet. In addition,
> > this object could be processed at an NTLP-aware NAT to provide
> > a traversal service for most signalling applications. I'd be 
> > interested to know if people think this should actually be reflected
> > in NTLP design (or, if they think it is just a terminally silly 
> > idea - in which case I can take it out of the framework as well).
> > 
> > 3. Just for the avoidance of confusion, the NSIS framework as
> > currently defined has no concept of message identifiers (global
> > or local), regarding them as purely internal. The thing it calls
> > the session id (possibly referred to as flow-id in the Shore draft)
> > identifies an application layer session.
> > 
> > See you in Vienna,
> > 
> > Robert H.
> > 
> > _______________________________________________
> > 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 21:33:48 +0300

Hi Robert,

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

Several people have come across as stating that, Rüdiger's comment
struck me as if he was of this opinion, for exampl
 
> 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"

My opinion is that a basic raw-IP / UDP mode is supported by default
and we look at how TCP/SCTP could be supported without running into
state bloat caused by multiple protocol support.  It does not need
to be a either / or question.
 
> 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.

Proof in engineering terms is often quite different than in mathmatical
terms.  Proof, in my usage, is nearly equivalent to a strong argument
that gains consensus.

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

I think we can consider how much of 2205 + 2961 needs to be supported.
I have not suggested, myself, dropping all of 2961, but to look at 
what to support. 2961 lists the following enhancements to RSVP:

	RSVP Bundle Message
	MESSAGE_ID Extension 
	Summary Refresh Extension 
	Exponential Back-Off Procedures 

The Exponential Back-Off Procedures is probably not needed.

John

---

From: [email-masked]
Date: Mon, 14 Jul 2003 21:35:56 +0300

Hi Henning,

I basically agree with your text, I just wanted to add clarifying
text - as I was unsure of the intention of some of the comments today.

John

> From: ext Henning Schulzrinne [mailto:[email-masked]]
> Sent: 14 July, 2003 21:15
> To: Loughney John (NRC/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [NSIS] comments on NTLP design proposals
> 
> 
> [email-masked] wrote:
> 
> >>That sounds familiar... I think this discussion would be 
> helped if the 
> >>word "reliable" is made a bit more precise.
> > 
> > 
> > Perhaps it would make more sense if we just were just 
> direct.  TCP/SCTP
> > provides connection-oriented functionality + 
> retransmission.  It provides
> > congestion control. It requires a 3 way handshake.  
> > 
> > For some trivial NSLP applications, retransmission & 
> congestion control
> > are probably not required, so in that sense, TCP would be 
> overkill.  
> 
> I think we're in agreement on this part; that understanding certainly 
> informed my strawman. The only issue I raised in my presentation was 
> whether that choice is made per-NSLP, per-hop or some combination.
> 
> I'm not sure if others are disagreeing with that part of the discussion, 
> but my reading is that most of those arguing for reliability don't see 
> this as a "must always be used" issue.
> 
> I also happen to think that some NSLP applications will not work well or 
> be severely constrained if such a reliable mode is not available 
> (without being forced on those NSLPs who do not need it). Do you agree 
> with that statement?
> 
> Also, since this seems to be common argument: the 3-way handshake 
> overhead is not incurred with every session setup. It is only incurred, 
> at least in the low fan-out cases I can think, once per peer. Thus, most 
> sessions will never see that overhead. (They will still see the 
> additional roundtrip time of finding the next hop.)
> 
> We should also acknowledge, however, that one-message setup has 
> potentially severe denial-of-service implications, as discussed in the 
> context of Hanne' recent message.
> 
> In general, I think it would be helpful to see this as an interconnected 
> issue.
> 
> Henning
> 
>

---

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

Hi John

>to be a either / or question.

I totally agree that a basic raw-IP / UDP mode should be supported 
by default.
This means that this mode is the mandatory mode. A NSLP initiator
should be able to select this mode.

I am not sure about the TCP/SCTP mode. We probably have to investigate 
its complications. However, even this mode will be supported it should be

an optional mode, that might also be selected by a NSLP initiator.

>The Exponential Back-Off Procedures is probably not needed.

The other three enhancements are actually interesting in quite static
reservation environments. In mobile/wireless environments, where there 
is a high amount of dynamic reservations (due to handoff procedures) 
these features are not very usefull. Therefore, in my opinion these 
features should be optional.

Best Regards,
Georgios

---

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

John,

|> i don't think there is anyone arguing at the moment that *all* 
|> signalling should be sent reliably.
|
|Several people have come across as stating that, Rüdiger's comment
|struck me as if he was of this opinion, 

I'm a backbone engineer and my experience with backbone signaling 
is that it is in many cases using reliable transport. It further 
is in some way congestion aware. BGP is around for a while, but 
also the later LDP uses TCP as a transport ptotocol. If a 
new signaling protocol may create a heavy signaling and/or 
processing load in the backbone, it should:
- be congestion aware to enable backbone routers to reduce 
  signaling load.
- minimize related state maintenance within backbone routers 
 (reliable transport between adjacent NTLP peers seems to 
 reach this aim better than NTLP per session message counting).

I expect the signaling relations within the backbone to be 
rather stable. Connection oriented transport seems to be 
possible. Awareness of the next NTLP message receiver  
may help to secure signaling (connection oriented transport
alone however won't do, an NTLP keep alive mechanism is required).

The connection between backbone NTLP peers is fired up and
then be kept alive for a long time. 

It is perfectly clear to me that an environment with a low amount 
of signaling messages and frequent changes in signaling relations 
results in other requirements. The same holds for stable 
signaling relations with a rather low amount of message exchanges.
But what's relevant in parts of the network may not be valid for 
the whole network. 

Regards, Rüdiger