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

From: [email-masked]
Date: Thu, 10 Jul 2003 14:07:52 +0300

Robert,

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

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

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

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: Henning Schulzrinne <[email-masked]>
Date: Sat, 12 Jul 2003 16:18:45 -0400

> we need to demonstate why something like 2205+2961 is not sufficient

Didn't we have this discussion, at length, in the context of 
fragmentation, flow control and congestion control, on this very list?

> protocol can be supported.

That sounds familiar... I think this discussion would be helped if the 
word "reliable" is made a bit more precise.