Also, added some explanation of how this will feed back to overall signalling
application behaviour (again in 5.3.3):

   When the rate limiter is in effect, D-mode messages MUST be queued
   until transmission is re-enabled, or they MAY be dropped with an
   error condition indicated back to local signalling applications.  In
   either case, the effect of this will be to reduce the rate at which
   new transactions can be initiated by signalling applications, thereby
   reducing the load on the network.

Actually added in version 13:

Changed the C-mode/D-mode selection rules in Section 4.3.3 to make the use of
C-mode a SHOULD unless capacity can be explicitly engineered.  Also added a
reference to this fact in the rate control section, Section 5.3.3.

In 4.3.3:

   o  congestion control: D-mode SHOULD NOT be used for signalling where
      it is possible to set up routing state and use C-mode, unless the
      network can be engineered to guarantee capacity for D-mode traffic
      within the rate control limits imposed by GIST (see
      Section 5.3.3).

(it used to just be a 'MAY' to benefit from congestion control)

At the end of 5.3.3:

                                                           ...  Note
   that, according to the rules of Section 4.3.3, in general D-mode
   SHOULD only be used for Queries and Responses rather than normal
   signalling traffic.

The final stage in the email discussion:
(see whole thread at
http://www1.ietf.org/mail-archive/web/nsis/current/msg06715.html)

hi lars,

> -----Original Message-----
> From: Lars Eggert [mailto:lars.eggert at netlab.nec.de] 
> Sent: 20 September 2006 22:54
> To: Robert Hancock
> Cc: 'Henning Schulzrinne'; john.loughney at nokia.com; nsis at ietf.org
> Subject: Re: [NSIS] Lars Eggert: DISCUSS and COMMENT: 
> draft-ietf-nsis-ntlp
> 
> 
> Hi,
> 
> On Sep 20, 2006, at 3:56, Robert Hancock wrote:
> >> From: Henning Schulzrinne [mailto:hgs at cs.columbia.edu]
> >>
> >> Given that the major point of NSIS is to avoid re-inventing
> >> TCP, maybe
> >> the best solution would indeed be to call out this 
> restriction, i.e.,
> >> that D-mode SHOULD only be used once (and after route changes).
> >
> > Is this the seed of a solution?
> 
> I'd be happy with this approach.

awesome, to coin a phrase :-)

> 
> > I know there will be people who want to use D-mode more
> > extensively; however, they want to do so in environments
> > where they can engineer capacity for the signalling
> > traffic (don't know if that is worth adding as a rider
> > to the SHOULD).
> 
> Adding a recommendation that more extensive use of D-mode (than the  
> above) SHOULD only be considered together with provisioned capacity  
> for signaling seems like a good idea.

OK (and the people who want it would be happy too).

> 
> > In terms of the other ideas that have come up in previous
> > mails, I still find it very hard to work out how an
> > adaptive scheme could work for the Query/Response traffic,
> > since, as Henning says, there is nothing on which to build
> > up any information about the congestion state of the
> > network. Restricting the number of outstanding D mode messages
> > opens up a trivial DoS attack (signal for a flow whose
> > endpoint silently eats Query messages; the Querying node
> > will have to time out waiting for answers).
> 
> Is that attack actually possible?  There isn't any verification of  
> whether a packet comes from a valid source?

I refer you to the SAVA bof (it's basically the same problem).
We can filter some out but not everything. But in any case, that
question is moot: the signalling could come from an entirely
valid source - it's the destination that isn't valid. A simple
approach would be to signal for a flow into a paranoid corporate
network (i.e. valid address space) which never emitted any 
outgoing diagnostics.

> 
> > I still think it is necessary to consider some kind of
> > rate control discussion for the route change/peer failure
> > case. These events could trigger a GIST node to Query for
> > all its flows, and that has to be capped in some way. The
> > current text sizes the token bucket on router interface
> > capacity; #sessions is another possibility (in fact, the
> > original proposal). They are all equally non-bulletproof,
> > albeit in different ways. Or do people want the token bucket
> > stuff out altogether?
> 
> I don't see how the token buffer could be made to work based on  
> interface capacity. Could you elaborate a bit on the original  
> proposal that was based on the number of sessions?

it didn't get much more elaborate than that (we were discussing
http://www3.ietf.org/proceedings/06jul/slides/nsis-10/sld7.htm
in the session and the interface rate approach came up as an
alternative). you would size the bucket on the number of 
established sessions and the session refresh time being used
plus a bit of headroom. but this is still not robust (for example,
a routing change which puts flows onto a lower capacity link
would still be a problem).

cheers,

robert h.

> 
> Thanks,
> Lars
> -- 
> Lars Eggert                                     NEC Network 
> Laboratories
> 
> 
>

A discuss from Lars Eggert:

   DISCUSS: "Node cannot saturate the network" is a very weak statement
   when it comes to congestion control, because it does not take
   concurrent traffic into account. Furthermore, bandwidth limits of, for
   example, "5% of the node's lowest-speed interface" also don't have the
   desired effect. Consider a router with only Gigabit Ethernet
   interfaces. By the definition above, it'd be allowed to send at a rate
   of 50Mb/s. If one of those links connects to a layer-2  switch that
   connects to the next router using 10Mb/s Ethernet, those 50Mb/s will
   overload the link. A similar case exists when a non-NSIS router is
   located between two NSIS routers. Even worse, fixed rate limits do not
   take concurrent network traffic along the link/path into account.
   Along a fully loaded link/path, adding 5% traffic can significantly
   impact concurrent flows. What an appropriate mechanism could be
   deserves some more discussion. There are several options, such as
   limiting each MA to a single outstanding D-mode request, which limits
   the additional traffic to be proportional to the number of MAs/flows,
   or more complex schemes if that is too limiting (AIMD, etc.)