Subject: [NSIS] comments on NTLP design proposals

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 10 Jul 2003 10:49:56 +0100

Dear All,

I have some questions & observations about how we are proceeding
with the NTLP design process. (Most of them have been stimulated
in fact by reading Melinda's draft-shore-..., but the one I 
consider most important/interesting is actually pretty general,
and I've put it at the start.) I have been out of the office for 
a few days and am not fully up to date with the recent mailing list
discussions, so apologies in advance if any of what follows is
redundant with that.

1. The single most important issue seems to me to be how the
'core' transport functions should be provided. I can see (at
least) 4 options -
a) take existing protocol components straight out of 2205+2961, 
re-arrange them in the NSIS layer model, and add pieces for 
additional functionality needed.
b) do (a) but starting from a clean sheet, i.e. a new 'path coupled
transport protocol'.
c) build the NTLP out of an existing transport protocol, and live 
with a separated signalling transport and route discovery 
process.
d) do (c) but trying to keep the ability to have unified 
transport and route discovery (like PATH does today).

It may be that (b) is ruled out by the terms of John's 'Starting
NTLP Work' slide from San Francisco, but I can't see that the others
are. I feel that we need to bottom out this question before really
getting into the details of protocol design (message formats and
so on), since the 'shape' of the protocol depends so strongly on
it.

Just for the record, let me say that I can see the attraction of 
(a) in terms of providing a conceptual starting point. However, I
have a suspicion that extra functionality - fragmentation, better congestion control, protection against denial-of-service attacks, pmtu discovery,
and so on - will be hard for us to design and hard to build into
the protocol in a nice way. (Another side effect of approach (a)
might well be that the NTLP inherits functionality which was 
natural in 2961 - like message summarisation, awareness of 
signalling application state - which shouldn't logically be there.)

On the other hand, I am not blind to the issues with (c), mainly
the need for a separate discovery procedure. I suspect it's 
impossible to provide a proof (which satisfies everyone) that this
doesn't matter.

So, maybe (d) would be nice. Unfortunately, I think (d) is 
impossible using a fully reliable transport; however, I'm now
pretty (90%) sure that something sensible can be done by
re-using DCCP, and selectively layering reliability on top
(where needed). (You could also use a different congestion response,
like TFRC, which might be nice. In fact, DCCP seems to have *lots*
of nice features...)

2. In earlier days of the WG, we were careful to consider the
problems of signalling going through clouds which were not pure
IP DA routed (see also recent discussion on this list about
Allison's comments on the requirements). So, I'm nervous about
protocol designs which assume that the IP DA fully defines the
route taken by a flow (i.e. this is all you need in the PATH-like
message). [Even RSVP uses both the flow SA and DA in PATH messages.]

In fact, we have up to now had an object in the framework (the
flow id, maybe a better name would be 'flow routing information')
which supposedly exposed at the NTLP level all the information 
needed to work out where to send a signalling packet. In addition,
this object could be processed at an NTLP-aware NAT to provide
a traversal service for most signalling applications. I'd be 
interested to know if people think this should actually be reflected
in NTLP design (or, if they think it is just a terminally silly 
idea - in which case I can take it out of the framework as well).

3. Just for the avoidance of confusion, the NSIS framework as
currently defined has no concept of message identifiers (global
or local), regarding them as purely internal. The thing it calls
the session id (possibly referred to as flow-id in the Shore draft)
identifies an application layer session.

See you in Vienna,

Robert H.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 12 Jul 2003 16:13:39 -0400

> signalling application state - which shouldn't logically be there.)

Agreed. 2961 suffered a bit from being a catch-all clean-up effort that 
commingled a number of separate problems, I believe more for historical 
reasons (they all appeared at roughly the same time, after people had 
had a bit of RSVP implementation experience), than technical reasons.

> impossible to provide a proof (which satisfies everyone) that this

I would find a logical separation that allows determining the next hop 
as a by-product a good compromise. It does not reduce performance, but 
allows the "swapping out" if the need should arise in the future.

> like TFRC, which might be nice. In fact, DCCP seems to have *lots*

Definitely a possible choice. I'm not convinced it has to be the only 
one. I'm somewhat perplexed by the reliability issue. I can't see how a 
reasonable QoS mechanism, for example, can be built without fast 
hop-by-hop recovery, where reasonable includes a call setup time that 
falls within the well-known human factors limits of post-"dial" delays.

> message). [Even RSVP uses both the flow SA and DA in PATH messages.]

I think we discussed this trade-off in a few previous meetings. The 
choices all seem uniformly bad under some circumstances.

> idea - in which case I can take it out of the framework as well).

It is probably still somewhat vague what this is meant to be. Can I take 
this to mean "simple flow descriptor", basically the 5-tuple + IPv6 flow 
ID + DSCP?

---

From: Marcus Brunner <[email-masked]>
Date: Thu, 17 Jul 2003 10:31:08 +0200

>> So, maybe (d) would be nice. Unfortunately, I think (d) is impossible 
>> using a fully reliable transport; however, I'm now

If the "well-known human factors limits of post-"dial" delays" are the 
metric I would assume end-to-end reliability might be enough (implies 
that reliability is an NSLP issue).

If the setup delay impacts an ongoing session (re-setup at a new 
location), setup delay needs to be in another range.

Concerning recovery I wonder what the proposed trigger mechanisms are to 
detect the problem and start the recovery mechanism. So far I was 
assuming that we relay on the routing protocol or change in forwarding 
table.
What is the detection time of a failure using for example TCP in 
function of the various timeout settings?

>> which supposedly exposed at the NTLP level all the information needed 
>> to work out where to send a signalling packet. In addition,
>> in NTLP design (or, if they think it is just a terminally silly idea - 
>> in which case I can take it out of the framework as well).
>

I really like it to keep it in. The NTLP routing decision might even be 
based on that information. This would solve the DA only routed problem.
I also like it for the NAT traversal case.

> this to mean "simple flow descriptor", basically the 5-tuple + IPv6 flow 

Yes I think so.

Marcus

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 17 Jul 2003 05:01:04 -0400

> that reliability is an NSLP issue).

I'm not sure I agree. The difficulty is that NSLP has a really hard time 
picking the appropriate timer on the first message. The first message is 
likely to trigger a number of AAA operations along the way, which can 
vary greatly in their delay. Thus, you'll either pick a very 
conservative delay appropriate for multiple AAA invocations (say, 3 
seconds) or you pick an aggressive one reflecting a conservative 
estimate of network round-trip time (say, 500 ms). If you take the long 
value, a single packet loss means that you are talking about delays 
exceeding the typical post-dial delay, while the lower one will result 
in spurious retransmissions that could easily multiply the number of 
messages by a factor of 5 or 6.

> function of the various timeout settings?

There is no difference - you detect that the next hop has changed (e.g., 
by triggers) and re-send the message.

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 17 Jul 2003 14:04:53 +0000 (GMT)

> I also like it for the NAT traversal case.

Good, thanks.
As an example of what we are trying to achieve, at least one of the recent
rash of QoS-NSLP proposals is I believe automatically transparent
to any NAT provided that that  NAT is NTLP aware, since the NSLP
carries no
addressing information itself. In other words, an NTLP-aware NAT
can support any NSLP without needing a signalling ALG, provided that
the NSLP refers to what it wants to talk about as "this flow" rather
than "the flow with IP SA fred and IP DA bert and protocol alf...".

> > this to mean "simple flow descriptor", basically the 5-tuple + IPv6 flow

Conceptually this is it. There are questions about exactly what
fields are needed and which can be wildcarded - I'd leave these as
details for the NTLP designers. The problem with wildcarding is that
at some point the flow path becomes ambiguous (packets could go in more
than one direction) - at that stage, I suppose, the NTLP could
report an "I'm giving up here" error message (could be complicated,
but useful in some access scenarios).

r.

---

From: Roland Bless <[email-masked]>
Date: Thu, 17 Jul 2003 17:14:16 +0200

> idea - in which case I can take it out of the framework as well).

Yes, I think it should be reflected and I'd like to keep it 
in for the same reasons that Marcus stated.

Regards,
 Roland