Subject: [NSIS] Transport functionality in the NTLP

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

Dear all,

We've posed questions about what transport-like functionality (reliability and so on) should be present in signalling protocols, and in particular how it should be divided in our 2 layer NTLP/NSLP model.
[On the mailing list, the discussion tends to transmogrify immediately into 'why TCP is/is not the right answer'; in the interim meeting, we made slightly more progress but didn't reach agreement in the room. Hence this mail.]

So here is a list of functionality which you might or might want in the NTLP. Make your views known, if you have any. You could say for example:
a) yes the protocol must always guarantee this feature explicitly
b) this property must be achieved but you could do it by other mechanisms as well (e.g. 'security' could be 'cryptographic protection' or 'network is physically protected')
c) it should be an option (in which case, what are the implications of having parts of the path support it and parts not)
d) no, there is no point in having this in the transport layer (e.g. it provides no benefit, or we can assume an upper NSLP will do it for us)

Here is a list of functions and an initial set of working assumptions (some deliberately provocative, but at least partly influenced by our recent discussions)
1. Congestion control (NTLP must protect the local network from signalling overload) - suggest (a)
2. High probability of delivery to the next NE even in the face of packet drops - I suggest (a)
3. Guaranteed delivery to next NSLP node with feedback on success - I suggest (d)
4. Bundling of small messages - I suggest (c), doing it has only local significance
5. Segmentation to avoid link/path MTU limits - I suggest (a), or (b) if you know all your links up to the next NE can be engineered to have a big enough MTU
6. In order delivery and duplicate detection/removal - I suggest (a) (maybe (c), if you are prepared to put it back locally in adjacent hops)
7. Framing (supporting message boundaries) - I suggest (a)
8. Flow control - not sure about this one. Maybe (c)
9. Security (confidentiality, integrity protection) - I suggest (a) or (b)

cheers,

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

---

From: Marcus Brunner <[email-masked]>
Date: Wed, 19 Feb 2003 12:01:37 +0100

--On Dienstag, 18. Februar 2003 23:42 +0000 "Hancock, Robert" 
<[email-masked]> wrote:

> Dear all,
>
> We've posed questions about what transport-like functionality
> (reliability and so on) should be present in signalling protocols, and in
> particular how it should be divided in our 2 layer NTLP/NSLP model. [On
> the mailing list, the discussion tends to transmogrify immediately into
> 'why TCP is/is not the right answer'; in the interim meeting, we made
> slightly more progress but didn't reach agreement in the room. Hence this
> mail.]
>
> So here is a list of functionality which you might or might want in the
> NTLP. Make your views known, if you have any. You could say for example:
> a) yes the protocol must always guarantee this feature explicitly b) this
> property must be achieved but you could do it by other mechanisms as well
> (e.g. 'security' could be 'cryptographic protection' or 'network is
> physically protected') c) it should be an option (in which case, what are
> the implications of having parts of the path support it and parts not) d)
> no, there is no point in having this in the transport layer (e.g. it
> provides no benefit, or we can assume an upper NSLP will do it for us)
>
> Here is a list of functions and an initial set of working assumptions
> (some deliberately provocative, but at least partly influenced by our
> recent discussions)
> 1. Congestion control (NTLP must protect the local
> network from signalling overload) - suggest (a)
>

> 2. High probability of
> delivery to the next NE even in the face of packet drops - I suggest (a)

Here I would opt for d. I assume that the probability is already high 
without any mechnism in or below NTLP. Detect and handle the any drop 
end-to-end.

> 3. Guaranteed delivery to next NSLP node with feedback on success - I

aggreed can be done in NSLP if needed.

> 4. Bundling of small messages - I suggest (c), doing it has

This might be an optimization in certain cases. I would even say d) deal 
with it later if needed.

> 5. Segmentation to avoid link/path MTU limits - I
> suggest (a), or (b) if you know all your links up to the next NE can be
> engineered to have a big enough MTU

I would asume that for environment, where security is not requiered this is 
not an issue.

> 6. In order delivery and duplicate
> detection/removal - I suggest (a) (maybe (c), if you are prepared to put
> it back locally in adjacent hops)

> 8. Flow control - not sure about this one. Maybe (c)

IMHO this depends again on whether NTLP is hop-by-hop only. If hop-by-hop 
only then d) should be done end-to-end.

> 9. Security (confidentiality, integrity protection) - I suggest (a) or (b)

b) optional

Marcus

> robert h.

--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
Phone: +49 (0) 6221 905 11 29
personal home page: http://www.brubers.org/marcus

---

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

> without any mechnism in or below NTLP. Detect and handle the any drop 

As mentioned during the interim, end-to-end is not a viable option by 
itself since the RTT estimate is likely to be extremely poor and 
variable. Do you disagree with that assertion? Indeed, the RSVP design 
experience bears this out - 2205 by itself is not sufficient and thus 
2961 adds a bare-bones hop-by-hop reliability.

Similarly, e2e congestion control is going to be extremely challenging 
given that you'll have poor RTT estimates, node-packet-dropping (due to 
lack of flow control) and link packet dropping. NEs are not just routers 
- with AAA, some nodes can hang onto an NSIS message for hundreds of 
milliseconds or longer.

Clearly, flow control cannot be performed end-to-end since the nodes to 
be protected are in the middle.

MTU discovery cannot be done end-to-end since the message size can 
change along the way.

Thus, rather than handwaving, we would need a concrete proposal as to 
how you would effectively address these issues end-to-end.

Also, as I said, it would be really helpful if somebody could cite 
verifiable engineering evidence that indicate that hop-by-hop solutions 
won't work. Simply restating this again and again or claiming that "it's 
not needed" is not very satisfying. One could argue that TCP isn't 
needed for accessing my local-LAN IMAP or HTTP server either. Are you 
suggesting that we should run IMAP or HTTP over UDP or that the 
performance would be significantly better if we did? Or are you 
suggesting that wireless web browsers should use UDP or raw IP? (If you 
look at NFS, you'll find a similar evolution of thought, btw.)

> I would asume that for environment, where security is not requiered this 
> is not an issue.

It's always easier to not turn on security than to have to back-engineer 
it later on. Again, RSVP is a good example of what happens if you try. I 
don't think designing a protocol that doesn't support it as a general 
rule is going to fly.

> IMHO this depends again on whether NTLP is hop-by-hop only. If 
> hop-by-hop only then d) should be done end-to-end.

Flow control simply cannot be done end-to-end. Please show how you can 
protect an NSIS node in the middle by an end-to-end mechanism.