Subject: [NSIS] consensus probe on one aspect of NTLP operation

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 18 Feb 2003 23:42:24 -0000

Dear all,

It's clear that the signalling exchanges considered by NSIS can go a long way across a network, visiting a sequence of NSIS entities (NEs). The protocol stack carrying the signalling is divided into a common layer (the NTLP) and signalling application specific layer (an NSLP).

I believe we have a roughly agreed working assumption (NB no claim of an official WG consensus) that the NTLP operates only between adjacent NEs ('hop-by-hop'), whereas any larger scope issues (including e2e aspects) are left to the NSLP.

Note: the practical content of the 'hop-by-hop' statement is something like: When a signalling message is ready to be sent from one NE, it is given to the NTLP along with information about what flow it is for; it is then up to the NTLP to get it to the next NE along the path, where it is received and the responsibility of the NTLP ends. (The receiving NE may decide to forward the message directly, invoking the NTLP again; or, it may give the message to a signalling application for further processing which then generates another message to be sent via the NTLP.) In particular, the NTLP at a given NE does not use any knowledge about addresses/capabilities/status/etc. of any NEs other than its direct peers.

If people have desires for NTLP functionality which are not covered by the previous paragraph, I'd very much appreciate it if they would say (a) specifically how it should be extended, and (b) why it is necessary.

[So, I'd obviously be happy to get no relevant replies to this message. However, if people have better words for a definition, I'd be happy to see them.]

Cheers,

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

---

From: Melinda Shore <[email-masked]>
Date: Tue, 18 Feb 2003 22:33:44 -0500

Robert, it's the chair's job to call consensus.  I still
don't know what the technical arguments are for departing
from RSVP on this, and since the minutes from the interim
meeting have not been posted those of us who were not there
don't know what was discussed or presented.  I'm happy with
accumulating path state in the application, but I'm still
highly not comfortable with accumulating routing state in
the transport layer.  This seems like a big step backwards
to me.

Melinda

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 18 Feb 2003 22:37:51 -0500

Melinda,

I suspect you have a somewhat different picture in mind. I'm not 
precisely sure what you mean by "routing state in the transport layer". 
At least in the discussions I recall, the state in the NTLP isn't all 
that different from what's in RSVP. Even with a non-raw-IP transport 
layer (below NTLP in my view of the world, within NTLP in the current 
fw; the term is overloaded, but I've said my piece on that...), the NTLP 
would keep the equivalent of next-hop/previous-hop state, except that 
this state might reference a TCP, SCTP or similar socket rather than an 
IP address. This does not imply any additional knowledge, at best, one 
(local) level of indirection (since the socket state would reference the 
next/previous hop by address).

Henning

---

From: Melinda Shore <[email-masked]>
Date: Tue, 18 Feb 2003 22:58:56 -0500

Sockets don't come free.  Depending on which OS you're
running they don't even come cheaply.  That's less of a
consideration for QoS applications, perhaps, but it's
something to keep in mind when thinking about applications
in which per-flow information is not aggregatable and there
are a lot of flows.  Enterprise NAT is a good example
because you've got to treat every flow that crosses the
device and you've got potentially very wide fan-out to the
next-hop devices participating in the application.

At any rate it would be a help if the minutes from the
interim meeting were posted to the mailing list.

Melinda

---

From: Marcus Brunner <[email-masked]>
Date: Wed, 19 Feb 2003 11:02:03 +0100

> I believe we have a roughly agreed working assumption (NB no claim of an
> official WG consensus) that the NTLP operates only between adjacent NEs
> ('hop-by-hop'), whereas any larger scope issues (including e2e aspects)
> are left to the NSLP.
>

I wonder what this assumption implies.
E.g., does it mean that an acknowledgment of successful state setup always 
has to travel back the reverse path?  IMHO it must NOT be excluded that an 
acknowledgement directly gets back to the NSIS Initiator along a potential 
different path. (And I am aware of the security problems, and reliability 
problems of that, but I would like to see this solved end-to-end as much as 
possible.)

In general I like to see the end-to-end argument applied for signaling as 
much as possible. See more on the issue of transport functionality.

Marcus

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 19 Feb 2003 09:29:15 -0500

> E.g., does it mean that an acknowledgment of successful state setup 
> always has to travel back the reverse path?  IMHO it must NOT be 
> excluded that an acknowledgement directly gets back to the NSIS 
> Initiator along a potential different path. (And I am aware of the 
> security problems, and reliability problems of that, but I would like to 
> see this solved end-to-end as much as possible.)

I don't see the value of this extra complexity. You now need to maintain 
transport state (whether as a TCP connection or your own homebrew 
protocol) from each node back to the originator. The security problem 
gets much harder, as you mention. Plus, in many cases the confirmation 
message is needed by the intermediate nodes anyway. For example, in the 
resource reservation case, you might want to commit the resources when 
the reservation has succeeded end-to-end.

The only "cost" is the slight increase in processing in each node. Given 
the processing capability of modern CPUs, this is largely a non-issue.

> 
> In general I like to see the end-to-end argument applied for signaling 
> as much as possible. See more on the issue of transport functionality.

The end-to-end argument doesn't apply here. The NEs *are* the end since 
they are participants in the protocol at hand.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 19 Feb 2003 10:25:36 -0500

Melinda,

would you happen to have quantitative evidence of the cost relative to 
doing raw IP sockets plus storing roughly the same information at the 
application layer? At least from our initial experiments, Linux can 
handle several ten thousand sockets.

Thanks.

Henning

---

From: Melinda Shore <[email-masked]>
Date: Wed, 19 Feb 2003 10:45:00 -0500

> handle several ten thousand sockets.

I can get a lot more sockets that that from a BSD system.
Nevertheless, while I don't have actual numbers I think
you'd clearly be quite hard-pressed to argue that the data
and buffers associated with, say, a TCP socket don't
substantially outweigh the amount of state associated with
an RSVP reservation.  Where you can get a win is in
circumstances where you can aggregate diverse messages
between NSIS nodes, which you can't currently do with RSVP,
but I think we need to consider applications in which
there's substantial fan-out and persistent connections.  If
we're willing to make that compromise let's make it
explicit, but I do think it's worthwhile to point out that
you may end up limiting the extent to which the NTLP is
useful as a generalized transport for inband signaling
applications.

Melinda

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 19 Feb 2003 11:11:55 -0500

If I understand you correctly, you are saying that this is primarily a 
memory issue, where an RSVP state is substantially smaller than TCP 
state. I'm curious if somebody has measured this; I wasn't able to find 
any current reference. I think RSVP state is around 500 bytes/session.

Maybe we should also set a target connection count we definitely want to 
support on current hardware, so that we can mock up a system to see if 
this would work.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 19 Feb 2003 13:50:19 -0800 (PST)

> support on current hardware, so that we can mock up a system to see if 

If you're going to do this, you'd need to compare
apples to apples. As in, what part of RSVP's per
session state is being used to maintain the
transport part of the session. My guess is that
that's substantially less than the 500 bytes you
cite. Indeed, since the two are tangled in RSVP, a
direct comparision might be rather tricky.

		Mike

---

From: "Lars.Westberg" <[email-masked]>
Date: Thu, 20 Feb 2003 10:21:07 +0100

Hi!
I am also worried about applications with high "fanout" for NTLP.

Do you have any experience about the performance difference between a
TCP-solution and a RSVP solution with substantial fanout ?

regards Lasse