Subject: [NSIS] Short Review of draft-schulzrinne-nsis-ntlp-00

From: [email-masked]
Date: Tue, 8 Jul 2003 15:01:26 +0300

Hi all,

I'm doing a quick review on documents to be discussed at IETF 57.

As this document is quite preliminary, I don't intend to give a detailed 
review, but an initial overview of the document.

http://www.ietf.org/internet-drafts/draft-schulzrinne-nsis-ntlp-00.txt

1) Terminology 

This section needs to be expanded, with definitions provided.

2) Introduction

Needs some improvement - the introduction feels like it makes a jump 
straight into the details, where I feel that some more introductory
material would be useful.

3) Objectives

I would quibble with this objective:

   1.  Discover the set of nodes along the path from the data sender to
       the receiver (peer discovery);

I've always thought that discovery comes as part of signaling along
the data path.  I think it is more proper to consider something
along the lines of determining the concerned nodes along the path,
rather than full-fledged discovery.

4) Overview of Operations

In generally, I think that this style of this section is effective in
providing an overview of the protocol.  However, after I reading this
section, I have worries about the amount of state needed - I feel
that the devil may be in the details here - which, of course, are
left for future versions of this document.

5) Transport Usage

This section is quite short, but after reading it, I started to think that
what we may want is to support datagram mode as the default and connection
mode multiplexing traffic, etc.  This is a very vague thought - but I wonder
if this is what you were getting at in the document, Henning.

6) Message Format 

Not much comment yet, probably would like to see a future update with some
of this fleshed out.

7) Security Considerations

Not much comment, but I am glad to see a more than perfucntory security 
considerations section

SUMMARY

The document is readable and does have a somewhat straight-forwardness to
it, which is a good thing in my opinion.  I worry about some of the
state management, which has been a problem with RSVP, so I think
this is one area that requires a bit of work.

thanks,
John   

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 08 Jul 2003 14:16:28 -0400

Some remarks.

> rather than full-fledged discovery.

This is probably more a difference in terminology than objective. It is 
probably both determining the nodes by sending packets towards the 
destination and, indirectly, discovering what they are (by any messages 
that tell a previous hop what the next hop is).

One more general point is that I'd like to logically keep these separate 
as there is no technical necessity that discovery/next-hop-determination 
is only done by sending packets. It currently is, but as discussed 
during the 'reroute' discussion, under some circumstances it may be more 
expedient to consult the source of routing behavior rather than poll for 
it.

> left for future versions of this document.

 From our implementation, the amount of state is not terribly large and 
no larger than (and likely smaller than) RSVP. There is per-session 
state such as the next and previous hop address and a last-message 
timer, as well as housekeeping information. The additional transport 
state is per-peer, not per-session. The number of peers is likely to be 
much smaller than the number of sessions, or at least bounded by a 
constant (depending on state management policies).

Clearly, this needs to be spelled out in more detail.

> if this is what you were getting at in the document, Henning.

Yes, roughly. To put the motivation very sloppily: have NTLP handle the 
easy transport, punt to a professional transport protocol for the hard 
cases. Easy = short messages sent infrequently to new destinations with 
relaxed reliability, so that fragmentation, RTT estimation, 
less-than-N-RTT loss detection, flow control and congestion control are 
largely somebody else's problem.

> Not much comment yet, probably would like to see a future update with some

Definitely. My current preference is RSVP TLV-like. Although we haven't 
talked about this much, judging from other contributions to this 
discussion, this may be the first IETF working group where the bit 
format is not a major bone of contention :-)

> state management, which has been a problem with RSVP, so I think

More details are needed, but the outline is that if there is transport 
state at all (many sessions won't need it), it needs to be subject to 
the same soft-state mechanisms as other NTLP state, but implementations 
should be free to trade the cost of establishing new state vs. the cost 
of maintaining state by hanging onto transport state if both ends agree.

Thanks for your comments.

Henning