Subject: [NSIS] Reliable Transport for NTLP

From: [email-masked]
Date: Mon, 14 Jul 2003 19:49:36 +0300

Hi All,

At today's meeting, Melinda pointed out that in her opinion, reliable transport
is not required for NTLP.  Rüdiger seemed to indicate that there is not a
significant cost to NTLP.  Unfortunately, there has been no working group
consensus that NTLP will be using reliable transport.  Also, I feel that
Rüdiger behavior was inappropriate for a professional meeting.  I should have
asked Rüdiger to display more professional courtesy at the mic.

However, my point is that the WG has not come to agreement that NTLP
should use reliable transport.  In fact, there is a significant cost,
in my opinion, in terms of setup time & latency.  I will outline a scenario.
Two end hosts, A & B, need to setup some signaling between them.  If TCP
is used as a transport, it is not a simple 3 way handshake that is 
needed. If A & B are x NTLP hops away, they will need x TCP connections,
which, depending upon implementation, will result a 3 way handshake 
between x+1 nodes, which is a significant problem.  In addition, needing
to setup TCP connections during fast mobility can also be a problem.

My point is that I do not see the requirement for reliable transport
in NTLP.  If there are parties interested in using reliable transport,
the burden of proof is with them.  

Please note, that Henning has proposed that there may be some advantageous
of using a partially reliable transport mechanism, however, I think
he has planned on providing more details to the list of how this could
be achieved, as it was not completely specified in his draft.

John

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

---

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

> to setup TCP connections during fast mobility can also be a problem.

John, this is simply not true and has not been true in all of these 
discussions. There has always been the assumption that connections are, 
on average, already established since the number of peers in most cases 
is bounded. There is no need to start from scratch for every session.

> the burden of proof is with them. 

I'm not sure what the threshold of "proof" is. I thought we had 
extensive, but inconclusive, discussions on how to address 
fragmentation, flow control and congestion control in NTLP.

> be achieved, as it was not completely specified in his draft.

Without trying to write a draft on the fly, here's the simple outline. 
I really need a whiteboard here. There are three choices:

1) one message, no reliability: just forward and have NSLP or e2e 
retransmission; subject to security issues such as DOS attacks, but 
quick and low overhead.

2) one message pair per hop: adds reliability, but no delay. Doesn't 
address DOS issues completely.

3) one message pair per hop + reliable protocol for large messages: adds 
reliability; adds delay for large signaling message. Addresses DOS 
issues better and.

---

From: Roland Bless <[email-masked]>
Date: Tue, 15 Jul 2003 09:10:34 +0200

Hi John,

On Mon, 14 Jul 2003 19:49:36 +0300 [email-masked] wrote:

> transport.  Also, I feel that Rüdiger behavior was inappropriate for a
> professional meeting.  I should have asked Rüdiger to display more
> professional courtesy at the mic.

Maybe I missed something, but I don't remember any offending statement
from him. He mainly asked Melinda to check for existing signaling
protocols that use an underlying reliable transport.

> in my opinion, in terms of setup time & latency.  I will outline a

If NTLP must implement congestion control we may also need a three way
handshake (see current DCCP spec).

> scenario. Two end hosts, A & B, need to setup some signaling between
> them.  If TCP is used as a transport, it is not a simple 3 way
> handshake that is needed. If A & B are x NTLP hops away, they will
> need x TCP connections, which, depending upon implementation, will
> result a 3 way handshake between x+1 nodes, which is a significant
> problem.  In addition, needing to setup TCP connections during fast
> mobility can also be a problem.

As others already stated: there may be already established connections
that can be reused.

> the burden of proof is with them.  

I think Henning mentioned the "SIP experience" several times and the
current discussion reminds me somehow of it...   

- Roland