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

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 30 Jan 2003 22:48:00 -0000

Hi Georgios, all:

On the question of whether to include transport features (congestion control, segmentation, etc.) as part of our NTLP work. You previously stated:

> For the moment I would want to mention that the NTLP that I need 
> to use does not need such features.

and:

> In my opinion we should try to reuse as much as possible 
> the existing transport layer solutions provided by RSVP.
> In this way we could reuse the current RSVP design experience 
> and RSVP protocol specification and shorten the time that 
> is needed to standardize NTLP.

Firstly, I don't know the full story, but my impression of the 'RSVP[2205] design experience' is that if you don't put these features in at the start, you have to put them in later (rfc2961). [A similar point can be made about security, i.e. 2747.]

Secondly, it is frequently stressed that the IETF strives to develop protocols which function robustly in all possible environments, i.e. open networks subject to overload, misconfiguration of individual elements, constrained links, malicious traffic, and so on (see also RFC3426). I don't see this requirement being relaxed just because we are starting from parts of an existing protocol.

In other words, even if you don't think you need these features in your protocol today, someone will use it next year in an environment where they do - by which time it could be too late. This has been the experience for other network problems in the past (it's happened in interior and exterior routing protocols, SIP), I don't see why signalling protocols should be immune.

Cheers,

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 30 Jan 2003 18:10:23 -0500

> In other words, even if you don't think you need these features in 
> your protocol today, someone will use it next year in an environment 
> where they do - by which time it could be too late. This has been the
>  experience for other network problems in the past (it's happened in 
> interior and exterior routing protocols, SIP), I don't see why 
> signalling protocols should be immune.

While SIP is not a network-layer reservation protocol, I think some of 
the lessons learned there apply here as well. (While UDP will likely 
remain part of the protocol, its sphere of use has been shrinking 
continuously.)

- MTU discovery and fragmentation is a pain. Even if you think that the 
message is small enough to fit 'near' where you are, it might get bigger 
along the way, as error indications, signatures and other things are 
added. This makes it very different from a run-of-the-mill IP packet 
that just gets its TTL bumped. Even if you can estimate the size of the 
message you send, you don't always know how big the response is going to be.

- Even if you can reasonably assume that normal (QOS) signaling traffic 
is low volume, with retries after failures, this is no longer the case.

- Wherever some notion of trust is involved, most systems talk to 
relatively few other systems in practice, so that the setup overhead for 
TCP is modest, removing one of the major TCP/SCTP problems that 
motivated UDP in the case of application-layer signaling.

- People like TLS. Yes, you can use IPsec, but once you talk to 
implementors, nobody wants to rely on it being available and 
configurable, given a choice.

I'm sure there are other lessons and not all apply here, but we should, 
I believe, look around more recent design efforts in the IETF as well.

Henning