Subject: RE: [NSIS] layer split summary? opinions?

From: [email-masked]
Date: Sun, 2 Feb 2003 15:51:27 +0200

Hi Henning & Georgios,

> > No, if an application needs TCP or SCTP features, then these applications 
> > should probably use the TCP or SCTP protocols, e.g., below NTLP.
> 
> That's what I've been advocating. Part of the discussion problem seems 
> to be that some people say "NTLP" and mean "whatever 'transport' layer 
> NSIS invents including the transport below", others mean "whatever sits 
> on top of either IP or TCP/SCTP". We should agree on one definition.

Well, I think we need to determine if, for example, reliable transport
is needed.  If so, then I suggest that we use TCP/SCTP; if not, then
UDP will probably be enough. 

> A different way of phrasing the confusion is that some people see NTLP 
> as an interface to the higher layer (NSLP) above - it describes all of 
> the services that the NSIS-new-stuff adds plus any underlying  existing 
> transport protocol offers.
> 
> Other people, possibly guided by the 'P' at the end, see it as a 
> protocol, i.e., describe only the services that this layer adds on top 
> of whatever L3/L4 mechanism is below.

Ultimately, this is what we will need to do.
 
> The re-use of the word transport can't help but add to 
> misunderstandings, but we probably lack the language supply to fix that 
> particular problem. (We have used the term messaging layer in one 
> context, but that term has its own set of problems.)

Agreed.

> However, your statement does add a requirement to NTLP: namely, that it 
> should be able to use either 'raw' IP or an existing transport 
> mechanism, such as UDP, TCP or SCTP (or possibly one of the emerging 
> UDP-like, congestion-controlled protocols being discussed in TSVAREA).

I agree.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 02 Feb 2003 09:19:19 -0500

> UDP will probably be enough. 

I believe the RSVP effort already came to that conclusion, albeit in a 
kludge added later. (I feel free to label it as such since I'm the 
co-author of the original paper suggesting the fix :-)).

I don't see how you can have a signaling protocol that does not offer 
reliability, and on short timescales. As far as I can tell, there are no 
deployed examples of 'unreliable' signaling protocols in other domains 
(SS7, ATM).

Now, it is possible to rely purely on end-to-end reliability, but this 
has serious design problems, in terms of efficiency. (Among other 
issues, the RTT estimate is likely going to be much better among NSIS 
peers than among some random pair of endpoints that haven't met each 
other before.)

Let me turn this question around: Where would you consider a system 
sufficient that purely relies on soft-state timeout and retransmision?

Henning

---

From: Ping Pan <[email-masked]>
Date: Mon, 03 Feb 2003 22:04:17 -0800

> co-author of the original paper suggesting the fix :-)).

Henning,

As the other co-author of the original paper to suggest the kludge, and 
the developer of getting it deployed, you are right - RSVP transport 
layer needs a lot of help. And it is more than a reliability problem. 
Come to think of it, we should have suggested to use TCP. :-)

- Ping

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 03 Feb 2003 22:34:09 -0800

> Come to think of it, we should have suggested to use TCP. :-)

No.

Pls consider separating two different concepts:
- a soft-state protocol with ACK for each message; and
- a reliable transport protocol underneath RSVP.

They are very different.
In a later paper (in ICNP'99 I believe) we stated that it is a good
enhancement to add ACK to RSVP.
But I personally consider it INfeasible to put TCP underneath.

Lixia

(if someone here runs BGP: how well has that been working)

---

From: Steven Berson <[email-masked]>
Date: Mon, 3 Feb 2003 22:57:08 -0800 (PST)

Ping, et al,

Before we make any hasty decisions, let's reconsider why TCP (etc) was
not used in RSVP.  First of all, TCP has a lot of overhead (reliable
delivery, in-order delivery, congestion control) not all of which is
really needed in RSVP.  Second, TCP does not support multicast which
was a feature in RSVP.  Third, you don't necessarily know who your
RSVP neighbor is, so it is not clear who to open the TCP connection
to.

I think that having some form of reliable transport as (at least) an
option is reasonable.  But I think we need to be clear about exactly
what features are desired and what the tradeoffs are.  Then we can 
make a good decision about mechanisms.

Regards,
Steve

---

From: "Sung Hycuk Lee" <[email-masked]>
Date: Tue, 4 Feb 2003 16:55:17 +0900

Dear all,

*****************************************************************************************
 Ping, et al,

Regards,
Steve
**************************************************************************************
 I agree with your opions (Steve).

 The goal of NSIS WG is to make a lightweight signaling (xRSVP), 
 so there are a lot of overhead if xRSVP using TCP is used in mobile (access) envrionments.

 Regards,

 Sung Hyuck Lee

-*************************************************************************************

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 04 Feb 2003 08:37:33 -0500

> really needed in RSVP.  Second, TCP does not support multicast which

A lot is being said about 'overhead'. Can somebody quantify this beyond 
just statements of opinion? My perception, based on measurements in 
other, related contexts, is that it has no impact whatsoever on 
signaling performance, compared to other operations. After all, we 
routinely build web servers that can handle thousands of operations a 
second.

> RSVP neighbor is, so it is not clear who to open the TCP connection

The latter is a solvable problem.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 04 Feb 2003 08:42:30 -0500

>  so there are a lot of overhead if xRSVP using TCP is used in mobile (access) envrionments.

I'm guessing that your mobile device has a web browser (HTTP), an email 
client (POP, IMAP, SMTP) and maybe even a SIP UA. How many queries a 
second does your web browser do? Compared to a signaling protocol?

Which do you think will do better in your mobile environment: your 
already-tuned-for-mobility TCP stack that you need for HTTP, IMAP, SMTP 
and possibly SIP or RTSP or a let's-develop-a-new-transport protocol 
that we'll develop for this special purpose?

Henning