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

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Wed, 19 Feb 2003 10:01:21 +0100

Hi Melinda

I agree with you!
In my opinion, the only strong consensus and decisions 
that have been taken during the NSIS interim meeting,
related to design considerations were:

* in addition to the flow ID an additional globally unique ID is needed
  which has to be used by NTLP. This can be the session ID;
* the typically solution for path discovery will be the path 
  forwarding routing solution (as in RSVP). When this solution cannot 
  be applied then other type of discovery procedure could be applied;
* TCP/SCTP below NTLP can be  a mode of operation. Other types of operation 
  should be allowed. This depends on the used environment/scenario and 
  also on the decission of if and where to implement features such 
  as reliability, congestion control, flow control, non-duplication
  fragmentation of signaling messages, in the NSLP or below. 
* peer to peer security is needed; However, in secure autonomous domains 
  this has not to be the case. The peer to peer security relation 
  could be between edges and not between interior nodes.

Best Regards,
Georgios

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]]
Sent: woensdag 19 februari 2003 4:59
To: Henning Schulzrinne
Cc: Hancock, Robert; [email-masked]
Subject: Re: [NSIS] consensus probe on one aspect of NTLP operation 

Sockets don't come free.  Depending on which OS you're
running they don't even come cheaply.  That's less of a
consideration for QoS applications, perhaps, but it's
something to keep in mind when thinking about applications
in which per-flow information is not aggregatable and there
are a lot of flows.  Enterprise NAT is a good example
because you've got to treat every flow that crosses the
device and you've got potentially very wide fan-out to the
next-hop devices participating in the application.

At any rate it would be a help if the minutes from the
interim meeting were posted to the mailing list.

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

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Wed, 19 Feb 2003 11:22:45 +0100

Hi Robert

>>I believe we have a roughly agreed working assumption 
>>(NB no claim of an official WG consensus) that the NTLP 
>> operates only between adjacent NEs ('hop-by-hop'), whereas 
>> any larger scope issues (including e2e aspects) are left to the NSLP.

>> Note: the practical content of the 'hop-by-hop' statement is 
>> something like: When a signalling message is ready to be sent 
>> from one NE, it is given to the NTLP along with information about 
>> what flow it is for; it is then up to the NTLP to get it to the next 
>> NE along the path, where it is received and the responsibility of 
>> the NTLP ends. (The receiving NE may decide to forward the 
>> message directly, invoking the NTLP again; or, it may give the message 
>> to a signalling application for further processing which then generates 
>> another message to be sent via the NTLP.) In particular, the NTLP at a 
>> given NE does not use any knowledge about 
>> addresses/capabilities/status/etc. of any NEs other than its direct peers.

In my opinion the main problem that we have at the moment, but also 
during the NSIS interim meeting is that we do not know what we want 
to mean by hop-by-hop protocol.
I consider a protocol that uses an end-to-end, end-to-edge, edge-to-edge
type of addressing not a hop-by-hop protocol. RSVP is in my opinion not 
a hop-by-hop protocol. 
Or am I missing something?

Best Regards,
Georgios

---

From: Tschofenig Hannes <[email-masked]>
Date: Wed, 19 Feb 2003 13:05:08 +0100

hi marcus!
> 
> The example I have been using is not from intermediate nodes 
> but from the 
> other end (typically the NSIS responder).

if it is only end-to-end - without addressing intermediate nodes at all then
it should not be part of an nsis protocol. 

> 
> >
> > please take a look at "Generalized MPLS Signaling - RSVP-TE 
> Extensions"
> > document. there they define a notify message which is 
> transmitted from an
> > intermediate node to the end host. as described in the 
> security section
> > (by steve bellovin) this requires a different security 
> protection (ipsec
> > is suggested there).
> >
> > hence in practice you only have two options:
> >
> > a) you transmit notifies on a regular basis between the nodes which
> > justifies the ipsec establishment (which is not cheap)
> > b) you only transmit notifies which do not require 
> protection (i.e. they
> > are unimportant - no action caused).
> 
> And some of us want to run the protocol in narrow scoped environments.

in certain environment it might be possible to have a more simplified
version of security. but you have to design the protocol in such a way that
the more difficult usage scenarios are also addressed. simply ignoring
message protection would be the wrong choice.

> 
> And typically you might already have a security association 
> between the 
> endpoints, which could be used again here.

mobile ip people also thought this in the beginning. but then......

ciao
hannes

> 
> Marcus
> 
> > ciao
> > hannes
> >
> >
> >   IMHO it must NOT be
> >> excluded that an
> >> acknowledgement directly gets back to the NSIS Initiator
> >> along a potential
> >> different path. (And I am aware of the security problems, and
> >> reliability
> >> problems of that, but I would like to see this solved
> >> end-to-end as much as
> >> possible.)
> >>
> >> In general I like to see the end-to-end argument applied for
> >> signaling as
> >> much as possible. See more on the issue of transport functionality.
> >>
> >> Marcus
> >>
> >>
> --------------------------------------
> 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: "Hancock, Robert" <[email-masked]>
Date: Thu, 20 Feb 2003 00:34:19 -0000

hi Melinda,

> Robert, it's the chair's job to call consensus.
I entirely agree with you (as indeed the phrase "no claim of an official WG consensus" in the 3rd sentence of the original mail might have been taken to imply).

Actually, there is a serious point here: an assumption of some form about hop-by-hop-ness of the NTLP has been floating around for about 6 months now, with not much comment against it. However, some comments at/around the interim implied that some people weren't happy with it, for reasons which were unclear. Other than writing something in the next framework draft and seeing if people notice it, it wasn't clear to me how else as editor of it to progress the issue other than writing in something suspected to be confusing. Alternative process suggestions are of course welcome.

[I haven't really analysed the resulting mail storm yet. But there seems to be
*) 1 problem of terminology (I think I would see RSVP's notional 'lower layer' as hop/hop, the same way Bob sees CSTP as hop/hop, but maybe the hop/hop term is unhelpful)
*) 1 problem of substance (the non-local notification problem) - which is certainly an issue, which I wanted to think of as orthogonal but probably isn't. It has fallen down my list of worries since making the assumption - also in the minutes of the interim - that reverse routing must be made possible, in which case the non-local notification ability seems not very useful. Obviously, if that goes in the next framework, people will be welcome to complain about that too.]

> I still
> don't know what the technical arguments are for departing
> from RSVP on this, 
what do you identify as the departure?

> 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.
which bit of the definition text makes you think this is what is proposed? would you like to propose an alternative definition?

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Thu, 20 Feb 2003 11:43:28 +0100

Hi Robert

Regarding the non-local notification issue that you addressed!
In an autonomous administrative domain, the local notification 
procedure, between edges is useful. Please note that this will 
be a NSLP procedure.
Therefore, I think that we should not exclude the local 
notification feature. However, it should be an optional feature.

Best Regards,
Georgios

-----Original Message-----
From: Hancock, Robert [mailto:[email-masked]]
Sent: donderdag 20 februari 2003 1:34
To: Melinda Shore
Cc: [email-masked]
Subject: RE: [NSIS] consensus probe on one aspect of NTLP operation 

hi Melinda,

---

From: [email-masked]
Date: Thu, 20 Feb 2003 18:35:23 +0200

Hi Mike,

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

Exactly - that was discussed at the interim meeting.

John

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 20 Feb 2003 21:53:59 -0000

dear colleagues,

It's precisely this 'you could do it N ways' possibility that led me to attempt to pose the question as a set of choices in my original email (actually on the other 'transport functionality' thread, but they seem pretty well entangled now).

To make a more detailed example of the 'should we demand a high likelihood of delivery between adjacent NSIS entities' (which seems to be one of the most contentious issues), I see 4 basic cases:
a) require the NTLP to do this
b) require an analysis that the combination (NTLP+underlying network) does this
c) make it optional, we leave it up to a local decision
d) say it's a higher layer function to recover from this

All of a/b/c/d are technically reasonable.

If we say (a) we accept the cost of doing this hop-by-hop (complexity, constraints on protocol design, etc); on the other hand, we get the benefit that losing an e2e refresh in the NSLP will presumably be a very rare occurrence and so can be treated more crudely than something you expect to happen often.

If we say (d), obviously the opposite applies (in each case).

Ideally, for this case I'd like to imagine we can get to either (a) or (d).

The other options seem less attractive. In particular:
(c) means that an NSLP designer can never have any confidence that e2e packet drop won't be common. So any NSLP would have to be designed and coded with robust e2e refresh mechanisms, and the benefit of any local recovery will be largely lost. (c) is pretty well equivalent to (d) for this function.
(b) is a more subtle issue, and I take the case of the 'reliable L2 wireless link' as a reasonable example: some link layers deliver reliably. But how easy is it to rely on this analysis in real life? Consider even almost the simplest possible example of a wired Ethernet link between two nodes. If the link lies in a single collision domain, you don't need a 'proper' transport layer to make delivery very likely; on the other hand, if there is bridging into a congested segment, loss is likely and there is no way for the sending node to know which is the case. So here, I would say (b) is only a reasonable alternative to (a) if you really guarantee (e.g. by manual deployment inspection or link quality monitoring) that it holds. That doesn't seem practical to me; maybe I'm just a pessimist.

So, I would say we need to trade off (a) and (d) for this particular function. I don't know if it's possible to calculate that trade-off except by the 'mailing list clap-ometer' method, but there are at least concrete engineering arguments that can be made on each side. (Would anyone care to offer a summary?)

Cheers,

Robert H.

PS. same process, maybe different conclusions, needed for the other transport-related functions, especially the contentious ones. so far, seem to be disagreements mainly about congestion/flow control and maybe MTU handling (fragmentation).

> From: [email-masked] [mailto:[email-masked]]
> Sent: 20 February 2003 17:35
> To: [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 21 Feb 2003 09:30:55 +0100

dear colleagues,
 
From a carrier point of view, reliability in signaling transport is a must. If packets get lost during phases of congestion, the added load on systems having to cope with these losses must be minimised. Congestion frienliness may be helpful. I guess, the lower the layer dealing with the issue, the better. a) therefore is the preferred choice. 

I didn't say "transport must be TCP". I just listed some requirements. It may be helpful if we first discuss requirements and continue with solutions later. 

Regards, Rüdiger

| To make a more detailed example of the 'should we demand a 
| high likelihood of delivery between adjacent NSIS entities' 
| (which seems to be one of the most contentious issues), I see 
| 4 basic cases:
| a) require the NTLP to do this

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 21 Feb 2003 11:14:44 +0100

John,

I think that all reliable transport protocols reqiure some kind 
of refresh mechanism. I'd guess that the further up the protocol 
stack you allocate it, the more processing is required and the 
slower the response to congestion.

I agree with Henning, that providing evidence based on 
simulations or implementations would be nice. But yes, 
apples must be compared with apples...

I don't want to say, let's take TCP. However I recognise that I 
can't offer a reasonable alternative - and I certainly don't 
want to specify a new transport protocol.

For backbone systems involved into signaling, network 
congestion must not result in increased signaling traffic, 
amplifying the stress of a router having to cope with 
congestion already. A good way of doing so seems to be to 
leave handling of congestion and reliable transport 
out of the signaling layer.

Regards, Rüdiger

| -----Ursprüngliche Nachricht-----
| Von: [email-masked] [mailto:[email-masked]]
| Gesendet: Freitag, 21. Februar 2003 10:53
| An: Geib, Rüdiger; [email-masked]
| Cc: [email-masked]
| Betreff: RE: [NSIS] consensus probe on one aspect of NTLP operation
| 
| 
| Rudiger,
| 
|  
| > From a carrier point of view, reliability in signaling 
| > transport is a must. If packets get lost during phases of 
| > congestion, the added load on systems having to cope with 
| > these losses must be minimised. Congestion frienliness may be 
| > helpful. I guess, the lower the layer dealing with the issue, 
| > the better. a) therefore is the preferred choice. 
| > 
| > I didn't say "transport must be TCP". I just listed some 
| > requirements. It may be helpful if we first discuss 
| > requirements and continue with solutions later. 
| 
| Is a soft-state refresh sufficient for reliability, or do you
| think guarenteed delivery to be important?
| 
| thanks,
| John
| 
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis