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

From: [email-masked]
Date: Wed, 9 Jul 2003 13:30:06 +0300

Hi Henning,

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

That is good - I was a bit worried about an active discovery mechanism
that would/could search for off-path nodes, as that is clearly out of
scope for the WG:

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

Sounds reasonable.

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

Perhaps that is the source of my concern - there seems not to be
enough consideration on bounding this aspect.  More detail is a good
think.

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

For example, 2961 has a lot of complexity - one may argue that not all of
the features of 2961 are actually needed for NSIS.  However, rolling
your own mechanisms in NTLP do accomplish some of what 2961 may be
difficult.

> > 6) Message Format 
> > 
> > Not much comment yet, probably would like to see a future update with some
> > of this fleshed out.
> 
> 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 :-)

Be thankful for small things ;)

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

Agreed, more text will help.

John

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 09 Jul 2003 15:18:48 -0400

> that would/could search for off-path nodes, as that is clearly out of

The active discovery mechanism specified or envisioned does not stray 
off-path. (The modularity may enable other mechanisms, including 
off-path, but that's hopefully not a drawback :-))

> enough consideration on bounding this aspect.  More detail is a good

My philosophy is that implementors should be given choices here (without 
impairing interoperability), since there's an inherent time/space 
trade-off, with the minimum state being a reasonable one. If that's not 
ok, please let me know.

> your own mechanisms in NTLP do accomplish some of what 2961 may be

The intent is to have only the most basic mechanism from 2961 
(hop-by-hop exponential backoff retransmission) and leave everything 
else as a "hard case". I'm not sure if your statement is agreeing with 
mine, but I have no intent of re-inventing 2961. I don't think the 
subset mentioned is difficult, at least based on our implementation 
experience (one additional timer per pending session) and that of other 
bare-bones transport mechanisms (DNS, SLP, RADIUS, etc.) that do roughly 
the same thing.

Henning