Subject: RE: [NSIS] Reliable Transport for NTLP

From: [email-masked]
Date: Mon, 14 Jul 2003 21:42:33 +0300

Henning,

I just responded to Robert, but just to make sure we are clear,
I will respond here:

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

My example was to show that there is a trade-off with using TCP, it is
not free.  We can mitigate the effects with proper engineering, I agree.

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

I don't mean proof in a literal sense, but as a burden of proof, meaning
that there needs to be a convincing argument.

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

As we discussed earlier, I think this looks like the way to go
to handle reliable transport, rather than turn it into an either /
or debate.

John

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

---

From: HELENA RUTE SOFIA <[email-masked]>
Date: Tue, 15 Jul 2003 05:27:57 -0400 (EDT)

John,

> to handle reliable transport, rather than turn it into an either /
exactly to which option are you referring to?? 1), 2), or 3)?

Rute

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 15 Jul 2003 05:32:46 -0400

To avoid artificial choices and unnecesary disagreements: I am arguing 
that all three are needed and can be readily supported without undue 
complexity in implementation, time or space. I'm *NOT* arguing that we 
need to make a choice here - the NSLP or NE gets to pick according to 
whatever trade-off it deems reasonable. (Who gets to suggest or force 
the choice is indeed an open issue.)

---

From: HELENA RUTE SOFIA <[email-masked]>
Date: Tue, 15 Jul 2003 05:54:02 -0400 (EDT)

Henning, John,

> the choice is indeed an open issue.)

Ok, not sure if this makes sense here, but I second-motion the opinion
aboeve; perhaps this could be addressed clearly on the next version of
ntlp...

Rute

---

From: Marcus Brunner <[email-masked]>
Date: Wed, 16 Jul 2003 17:38:04 +0200

> the choice is indeed an open issue.)

I like the vision of supporting all three. I might even want to add a 
4th, but this needs some more thinking on myside. Itmakes the NTLP 
pretty generic to be applicable in various environment running various 
NSLPs.

Actually, I regard this open issue a much more interesting. It might
raise issues on is the end system/NSLP initiator know what he needs. Is
an adaption to an underlying L2 technology the relevant decision
criterion. Then there is the question which entity is allowed to
overrule another entities request.

Marcus