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

From: [email-masked]
Date: Mon, 14 Jul 2003 20:43:51 +0300

Hi Henning,

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

John

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 14 Jul 2003 14:14:55 -0400

> 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