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

From: [email-masked]
Date: Tue, 4 Feb 2003 13:16:26 +0200

Lixia,

A question to you:

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

What is the feasibility of running an NSIS transport over TCP to
certain entities, like edge routers / gateways, while supporting
soft-state for routers & boxes between these edge routers / gateways?

If needed, I could supply a diagram.  I think that this is a model
that some people are suggesting.  However, I think we need to 
sort out the implications of this.

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

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 04 Feb 2003 06:33:09 -0800

> soft-state for routers & boxes between these edge routers / gateways?

That'll need more time to explain than what I have in hand at this time
(heading to airport in an hour)

But briefly: the fundamental problem is mismatch of semantics/data framing
in providing reliability.

One simple example:
- TCP offers reliable byte stream.
- That's not what you need.  A later signaling msg may replace an
  earlier one, yet you cannot take back the bytes that you have
  already passed to TCP.

Another example:
- TCP has this notion of connection
- when TCP connection broke, what assumption would you make regarding
  the state at the other signalling party?
  currently BGP assumes all states were gone, and it ships another
  copy of that huge routing table of 118000 entries over again
  (bar the recent graceful restart, that does not handle all
  the cases anyway)

And don't assume that TCP sessions between two signalling ends never
break--if experience with BGP serves an example, it shows they do, and a lot
more frequent than one would think

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 04 Feb 2003 12:28:15 -0800

> (bar the recent graceful restart, that does not handle all

If I may add a 3rd example: consider route changes
(at least BGP doesn't have that problem)

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 04 Feb 2003 17:23:26 -0500

>   earlier one, yet you cannot take back the bytes that you have

This is only a problem if there is a long delay in the pipe. Otherwise, 
UDP or TCP, the message will be delivered after the same time. (If you 
believe head-of-line blocking matters, SCTP would presumably address 
that problem.)

> more frequent than one would think

At least in our model, the existence of a TCP connection has no 
relationship to the existence of an NSIS session. A single NSIS session 
could use multiple TCP connections over time and multiple NSIS sessions 
can share a single TCP connection, either sequentially or in parallel. 
The decision when to drop a TCP connection is purely an optimization. If 
you expect a new signaling message between two entities soon, it makes 
sense to keep a TCP connection around.

(Aside: Early H.323 made the mistake of tying session lifetime to TCP 
lifetime; there was a related, transaction-level tie for SIP. Both have 
since seen the error of their ways and decoupled transport session 
lifetime from higher-layer sessions.)

Henning