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

From: [email-masked]
Date: Thu, 20 Feb 2003 15:55:44 +0200

Hi Melinda,

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

Its perfectly legal for WG members to ask for consensus on
an issue, which I think is what Robert was doing.  However,
it is the chair job to call the consensus when consensus
is reached.

Determining the transport functionality is probably the big
issue to determine, so I'd be happy if the WG discussed
the needs for transport.

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

---

From: Melinda Shore <[email-masked]>
Date: Thu, 20 Feb 2003 10:32:03 -0500

> issue to determine, so I'd be happy if the WG discussed

As you know I'm somewhat concerned that a particular
protocol is being promoted here and that's what's driving
some of the framework and requirements.  I'm trying to
understand what the problems with existing protocols are
perceived to be, and whether they're sufficient to drive a
substantial change in the way signaling messages are carried
between devices.  Unfortunately Ping Pan's draft on
transport issues hasn't been discussed here at all.

The issues that have been identified are:

1) reliable transport
2) message packing
3) MTU issues
4) short-lived streams result in high signaling traffic 
   volume relative to data traffic

I could use further explanation of why the fourth is a
problem peculiar to RSVP, since the signaling messages are
going to be sent regardless of underlying transport.  

Also, it seems to me that the second and third are actually
the same issue.  With changes to RSVP message formats the
only real issue with message packing is packet expansion.
This is also likely to be a problem as stronger security
mechanisms are added, and is potentially a big problem.
Packet reassembly would increase the amount of
transport-related state in RSVP.

The one I'm really not sold on is reliable transport.  Has
this really proven to be a problem in practice?  I can see
it being a problem under congestion, but we're going to need
to ensure that there are mechanisms for prioritizing
signaling traffic anyway - we need to to care, at least,
that teardown messages get through regardless of network
load.  Many applications going to need timers for whatever
ends up being the analog of PATH/RESV anyway, in order to be
able to provide affirmative success/failure responses in
cases where that matters (telephony, for example - post-dial
delay can be an issue and if the call is going fail you
don't want to wait minutes for it to do so).

I see the issues that are being raised here and don't agree
with them completely.  The question for me, ultimately,
comes down to whether the functionality that's lost (the
very neat way that RSVP handles routing, specifically) can
be regained in another way that's nearly as lightweight and
robust, and, if not, whether the gain in other functionality
is worth the tradeoff.

Melinda

---

From: Jukka MJ Manner <[email-masked]>
Date: Thu, 20 Feb 2003 18:13:05 +0200 (EET)

Hi,

why couldn't we adopt the general approach what Ping Pan just proposed in
his earlier email, that, let each individual choose the transport protocol
that best suits a certain situation? The debate on "this is better than
that in my scenario" will most probably not lead to a result anytime this
year. Let's keep the choice as open as possible - wouldn't harm anyone, I
guess.

Cheers,
Jukka

---

From: Michael Thomas <[email-masked]>
Date: Thu, 20 Feb 2003 08:27:33 -0800 (PST)

One word: complexity. Having a single mechanism
for almost any protocol is preferable to a
multiplicity unless there are *compelling* reasons
to allow flexibility. By way of example, both
English and Metric units both equally well solve
problems in measurement. Their co-existence,
however, at the very least has lead to a new
crater on Mars. Closer to home, the SIP experience
has taught that having multiple transports leads
to some combinatorial explosion, not to mention
unexpected problems with security, etc.

	   Mike

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 20 Feb 2003 11:40:31 -0500

To amplify: I think the complexity arises if you need to support the 
functionality that one underlying mechanism offers at the higher layer 
elsewhere. If SIP, say, were to only support unreliable delivery using 
UDP, this would be fairly harmless. The problem arises once you try to 
replicate all the functionality at a higher layer. Not only do you get 
complexity, you get interactions between layers, timer collisions, 
issues with hybrid transports, etc.

Thus, I have no problem with saying "support UDP (or raw IP) as an NSIS 
transport" as long as it is understood that this only offers whatever 
the network below offers, i.e., there is no attempt to "fix" the problem 
in RFC 2961 style.

Or, put differently: if you want real transport functionality, use a 
real transport protocol (and if you think you don't need it and you can 
convince the keepers of the Internet architecture that you will never, 
ever cause congestion, you don't have to use one).

---

From: Michael Thomas <[email-masked]>
Date: Thu, 20 Feb 2003 08:57:14 -0800 (PST)

Here I depart company. There is no magical
bright-line distinction between a "real" Transport
Protocol, and application layer framing (ALF).  On
the plus side, using a "real" transport layer
protocol, you inherit all of the years of
experience and predictability of that protocol. On
the minus side, you inherit all of the limitations
as well. For TCP, that means head of line blocking
and single-homing. For RSVP in particular, I don't
really understand how "router alert" functionality
and TCP/SCTP would get along. My guess: poorly.

So, there's nothing wrong with considering ALF as
Van pointed out during MEGACO. Good design can
also borrow from the 20+ years of experience with
the net as well, so it's not like rocket science
to design a customized yet net-friendly transport
these days. And if you end up with semantic
overloading, etc, all you're pointing out is that
the protocol wasn't designed in a modular way, not
the inherent futility of the approach. As with
most engineering, it's very contextual and depends
a whole lot on the engineering tradeoffs; sweeping
generalizations are rarely useful.

		    Mike

---

From: "Jim Fleming" <[email-masked]>
Date: Thu, 20 Feb 2003 10:48:26 -0600

----- Original Message -----
From: "Henning Schulzrinne" <[email-masked]>
> ever cause congestion, you don't have to use one).

Can you provide a picture of "the Internet architecture" ?

Who are "the keepers of the Internet architecture" ?

Jim Fleming
[email-masked] Consultant
http://www.Unir.NET
http://www.Unir.com
http://www.Uni%ae.com
http://www.Uni®.com

---

From: Ping Pan <[email-masked]>
Date: Thu, 20 Feb 2003 10:16:47 -0800

The messages are sent between routers. Hop-by-hop. When delivering 
messages between hops, using a different transport mechanism based on 
the interface should be a common practice in development. Where is the 
complexity? Many protocols are processed independent from their 
transport layer protocol. In case of RSVP, based on the transmit 
interface, instead of writing to a raw socket, just send through a TCP 
socket. Don't see the complexity there.

The interesting issue is how to maintain per-neighbor transport protocol 
type. Well, RFC2961 uses RSVP common header. RSVP-TE graceful restart 
uses the Hello messages. Take your pick, both are pretty simple to do.

- Ping

---

From: Ping Pan <[email-masked]>
Date: Thu, 20 Feb 2003 10:25:46 -0800

> and TCP/SCTP would get along. My guess: poorly.

:-) yeap!

> generalizations are rarely useful.

Another issue is: why do we want to figure out all the transport layer 
stuff that has nothing to do with signaling protocol itself? For 
example, after looking at how OSPF doing its reliability delivery stuff, 
  arn't you glad to see TCP is used in BGP? :-)

- Ping