Subject: RE: [Fwd: Re: AW: [NSIS] Transport functionality in the NTLP]

From: "Naidu, Venkata" <[email-masked]>
Date: Thu, 20 Feb 2003 15:33:49 -0500

Ping,

-> Argument 1: if we have so many issues in the existing RSVP transport,
-> and BGP/LDP are two operational protocols running over TCP between
-> routers, then why not run RSVP payload over TCP between routers? (The
-> overhead for a TCP socket is very small, at least in the 
-> latest FreeBSD and Linux.) This is a valid point.

  I am interestingly following the thread. What I am wondering
  is, why are you not considering P2MP signaling for NTLP?
  If you restrict RSVP over TCP then aren't you making signaling
  only for P2P cases?!? Don't you want to benefit from
  IP multicasting when you really want to signal a call from
  one calling party to multiple called parties (etc etc)?

  Your paper reads...
   RSVP [RFC2205] was originally designed to support real-time
   applications over the Internet. Over the past several years, the
   demand for multicast-capable real-time teleconferencing, which many
   people had envisioned to be one of the key Internet applications that
   could benefit from network-wide deployment of RSVP, has never
   materialized. 

  IMHO, making RSVP over TCP we are restricting the protocol
  too much. If you want reliability and the other benefits of TCP
  then fine but, I prefer, we should not jeopardize the envisioned 
  future applications.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 20 Feb 2003 15:43:43 -0500

To avoid any non-issue discussions: The use of a reliable transport 
protocol, as envisioned, does not interfere at all with multicast use. 
Recall that RSVP forwards Resv messages hop-by-hop (unicast) as well.