Subject: [NSIS] Lars Eggert: DISCUSS and COMMENT: draft-ietf-nsis-ntlp

From: <[email-masked]>
Date: Fri, 15 Sep 2006 16:04:53 +0300

Here's a DISCUSS and comment from Lars about GIST.  Robert is traveling,
but it would be good to discuss this in the WG to find out ways to
address 
his DISCUSS.

John 

>-----Original Message-----
>From: ext Lars Eggert [mailto:[email-masked]] 
>Sent: 12 September, 2006 14:54
>To: [email-masked]
>Cc: [email-masked]; [email-masked]; 
>[email-masked]
>Subject: DISCUSS and COMMENT: draft-ietf-nsis-ntlp 
>
>Discuss:
>  DISCUSS: For anything sent over UDP, i.e., D- and Q-mode, it must be
>  made clear that messages must have payloads smaller than the PMTU
>  (minus headers) or 512 bytes if the PMTU is unknown, to avoid
>  fragmentation. (Section 5.4.1 and 5.8.1.2 do so, but other 
>sections do
>  not.) Because some messages MUST be transmitted in D- or Q-mode, are
>  such messages guaranteed to be less than this limit in all cases?
>  Furthermore, a suitable rate control mechanism for the use with UDP
>  must also be described. The token bucket in section 5.3.3 is
>  insufficient, see below.
>
>
>Section 3.5., paragraph 8:
>>    o  Messages with the same SID that are to be delivered reliably
>>       between the same GIST peers are delivered in order.
>
>  DISCUSS: If messages with the same SID go over different messaging
>  associations, there is a possibility that they reach the peer out-of
>  order, even if each messaging association guarantees in-order
>  delivery. I don't see this case addressed in the document.
>
>
>Section 2., paragraph 4:
>>    The basic rate-control requirements for D-mode traffic are
>>    deliberately minimal.  A single rate limiter applies to 
>all traffic,
>>    for all interfaces and message types.  It applies to 
>retransmissions
>>    as well as new messages, although an implementation MAY choose to
>>    prioritise one over the other.  Rate-control applies only 
>to locally
>>    generated D-mode messages, not to messages which are 
>being forwarded.
>>    When the rate limiter is in effect, D-mode messages MUST be queued
>>    until transmission is re-enabled, or an error condition MAY be
>>    indicated back to local signaling applications.  The rate limiting
>>    mechanism is implementation-defined, but it is RECOMMENDED that a
>>    token bucket limiter as described in [31] be used.  The 
>token bucket
>>    MUST be sized to ensure that a node cannot saturate the 
>network with
>>    D-mode traffic, for example when re-probing the network 
>for multiple
>>    flows after a route change.  A suitable approach is to 
>restrict the
>>    token bucket parameters so that the mean output rate is a small
>>    fraction, such as 5%, of the node's lowest-speed interface.
>
>  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.)
>
>Comment:
>COMMENT:
>
>  Nit: Mixes US and British English (e.g., signalling vs. signaling,
>  etc.) - pick one.
>
>
>Section 3.1., paragraph 7:
>>              Figure 2: Protocol Stacks for Signaling Transport
>
>  Nit: TLS doesn't currently operate over DCCP, and there are some
>  issues with operating over some variants of SCTP.
>
>
>
>Section 3., paragraph 0:
>>        a messaging association.  The Query is encapsulated in a UDP
>>        datagram and injected into the network, addressed towards the
>>        flow destination and with an IP Router Alert Option (RAO)
>>        included.
>
>  Some IP options force packets onto a router's slow path, which may
>  contribute to resource exhaustion. I assume that the authors have
>  verified that Router Alert Options are safe to use in this regard?
>
>
>Section 4., paragraph 0:
>>    4.  The Query passes through the network towards the flow 
>receiver,
>>        and is seen by each router in turn.  GIST-unaware routers will
>>        not recognise the RAO value and will forward the message
>>        unchanged; GIST-aware routers which do not support the NSLP in
>>        question will also forward the message basically unchanged,
>>        although they may need to process more of the message 
>to decide
>>        this.
>
>  Many middleboxes drop packets with IP options (Alberto Medina, Mark
>  Allman, Sally Floyd. Measuring the Evolution of Transport 
>Protocols in
>  the Internet. ACM Computer Communication Review, 35(2), April 2005.)
>  Although I assume that this will mostly occur on the first or last
>  couple of hops, this can still interfere with end-to-end NSIS
>  operation.
>
>
>Section 4.1.2., paragraph 2:
>>    Reliability:  This attribute may be 'true' or 'false'.  
>When 'true',
>>       messages MUST be delivered to the signaling application in the
>>       peer exactly once or not at all;
>
>  "Once or not at all" isn't exactly the typically definition of
>  reliability. Is there a better term for what is meant here?
>
>
>Section 4.1.2., paragraph 3:
>>       TCP is considered in Section 5.7.2.  Messages with the 
>same SID to
>>       the same peer MUST be delivered in order.
>
>  ...unless they are not delivered at all.
>
>
>Section 4.1.2., paragraph 4:
>>       When 'false', a message
>>       may be delivered, once, several times or not at all, 
>with no error
>>       indications in any case.
>
>  What about reordering when "false" - are duplicates of a message
>  allowed to arrive after later messages have arrived?
>
>
>Section 4.1.2., paragraph 6:
>>       intermediate nodes.  An NSLP may also indicate that 
>reverse path
>>       routing state will not be needed for this flow, to inhibit the
>>       node requesting its downstream peer to create it.
>
>  s/may/MAY/
>
>
>Section 4.3.2., paragraph 1:
>>    prevent looping, MUST be checked and decremented immediately the
>>    message has been received.  Further processing depends on the 
>> message
>
>  Nit: s/immediately the/immediately after the/
>
>
>Section 5.2.2., paragraph 10:
>>       The setting and interpretation of the IP-TTL field 
>depends on the
>>       message direction (upstream/downstream as determined 
>from the MRI
>>       as described above) and encapsulation.
>
>  Routers may decrement the IP TTL by more than than 1, and there is no
>  requirement that routers use the same decrement value on all
>  interfaces. Is this mechanism robust under these conditions?
>
>
>Section 5.3.3., paragraph 2:
>>    Query messages which do not receive Responses MAY be 
>retransmitted;
>>    retransmissions MUST use a binary exponential backoff.  
>The initial
>>    timer value is T1, which the backoff process can increase up to a
>>    maximum value of T2 seconds.  The default value for T1 is 
>500 ms.  T1
>>    is an estimate of the round-trip time between the querying and
>>    responding nodes.  Elements MAY use smaller values of T1 if it is
>>    known that the Query should be answered within the local 
>network.  T1
>>    MAY be chosen larger, and this is RECOMMENDED if it is known in
>>    advance (such as on high latency access links) that the round-trip
>>    time is larger.  The default value of T2 is 64*T1.
>
>  500ms seems short. TCP uses T1=3sec for SYN retransmissions and DNS
>  uses T1=5sec. (However, I think SIP uses 500ms, too?)
>
>
>
>Section 2., paragraph 2:
>>    It can be seen that all of these transport protocol options can be
>>    supported by the basic GIST message format already 
>presented.  GIST
>>    messages requiring fragmentation must be carried using a reliable
>>    transport protocol, TCP or SCTP.  This specification 
>defines only the
>>    use of TCP, but other possibilities could be included without
>>    additional work on message formatting.
>
>  This paragraph should be moved to 5.1 or even earlier, as it is not
>  specific to C-mode. It would also be good to discuss in more detail
>  what "require fragmentation" means, i.e., GIST message > path MTU (or
>  512 bytes, if path MTU is unknown). Additionally, because some
>  messages MUST be carried in D- or Q-mode - is it guaranteed 
>that their
>  payloads are always less than 512 bytes?
>
>  Also, s/must/MUST/.
>
>
>Section 5.4.2., paragraph 0:
>>    5.4.2.  Encapsulation Format
>
>  Move up, section is not specific to C-mode. Section 5.4 should
>  probably be restructured after these changes.
>
>
>Section 5.7.1., paragraph 1:
>>    A key attribute of GIST is that it is flexible in its 
>ability to use
>>    existing transport and security protocols.  Different transport
>>    protocols may have performance attributes appropriate to different
>>    environments; different security protocols may fit 
>appropriately with
>>    different authentication infrastructures.
>
>  All protocols defined in the subsections of this section are for
>  C-mode - what about D-mode?
>
>
>Section 5.8.1.3., paragraph 0:
>>     5.8.1.3.  Upstream Q-mode Encapsulation
>
>  No restriction on message size. See DISCUSS.
>
>
>Section 6.2., paragraph 20:
>>    Rule 4:
>
>  Nit: Pseudocode not indented.
>
>
>Section 7.2., paragraph 0:
>>     7.2.  NAT Traversal
>
>  Are any GIST-aware NATs in existence? It seems that this section is
>  mostly about a hypothetical mechanism.
>
>
>Section 7.3., paragraph 0:
>>     7.3.  Interaction with IP Tunnelling
>
>  This subsection doesn't really belong under "Advanced Protocol
>  Features."
>
>

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 15 Sep 2006 22:08:53 -0400

>>  or more complex schemes if that is too limiting (AIMD, etc.)

The problem with the 'single outstanding D-mode' is that this is  
likely extremely conservative, given that the sender won't  
necessarily know where the next hop terminates, so all of these  
messages could easily traverse different first and/or second hops.

AIMD has the same problem, since the destination path to the next hop  
is unknown and feedback won't arrive until it is too late. You'll  
only be sending one message in D-mode, usually, so there's nothing to  
ramp up.

I will note that GIST isn't any more congesting than, say, DNS -  
generally, one end-to-end transaction per application start (ignoring  
local caching). It would be pretty difficult to rate-control DNS for  
that same reason.

Henning

---

From: Lars Eggert <[email-masked]>
Date: Mon, 18 Sep 2006 18:28:55 +0200

Hi,

> messages could easily traverse different first and/or second hops.

right - I only included the "single outstanding D-mode" case as one  
possible solution.

> AIMD has the same problem, since the destination path to the next  
> hop is unknown and feedback won't arrive until it is too late.  
> You'll only be sending one message in D-mode, usually, so there's  
> nothing to ramp up.

It may be true that usually there is only one D-mode message, but the  
document doesn't currently place any such restriction on D-mode. If  
it said "send only the query in Q-mode, use C-mode for everything  
else that follows", that'd be significantly better. My concern is  
based on the document not placing any restrictions on how frequently  
D-mode messages can be sent and how large they can be.

> generally, one end-to-end transaction per application start  
> (ignoring local caching). It would be pretty difficult to rate- 
> control DNS for that same reason.

Agreed, but see above.

Lars
-- 
Lars Eggert                                     NEC Network Laboratories

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 18 Sep 2006 12:43:12 -0400

> document doesn't currently place any such restriction on D-mode. If it 
> said "send only the query in Q-mode, use C-mode for everything else that 
> follows", that'd be significantly better. My concern is based on the 
> document not placing any restrictions on how frequently D-mode messages 
> can be sent and how large they can be.

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

---

From: "Robert Hancock" <[email-masked]>
Date: Wed, 20 Sep 2006 11:56:58 +1000

Henning, Lars, all,

> From: Henning Schulzrinne [mailto:[email-masked]] 
> Sent: 19 September 2006 02:43
> To: Lars Eggert
> Cc: <[email-masked]>; [email-masked]
> Subject: Re: [NSIS] Lars Eggert: DISCUSS and COMMENT: 
> draft-ietf-nsis-ntlp
> 
> 
> > 

Is this the seed of a solution?

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

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

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?

cheers,

r.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 19 Sep 2006 22:54:07 -0400

> traffic (don't know if that is worth adding as a rider

Stating exceptions ("known network capacity") is certainly helpful.

> albeit in different ways. Or do people want the token bucket

I think this mostly offers the illusion of safety, while adding more  
"tweak" parameters that cause unpleasant surprises when they are set  
wrong, but forgotten. (Suddenly, voice calls fail after re-routes  
because somebody didn't update the parameter after upgrading the T1  
to an OC-12.)

Also, fixed ratios and such can't take into account that reservation  
messages may have different importance in different networks. If I  
run a corporate network where voice is most important, I will want  
the reservation messages to go through pronto, even if they  
temporarily reduce the web bandwidth.

Adding buckets and the like also introduces strange failure modes, if  
messages are queued or dropped, causing upstream retransmissions or  
duplicate messages as the queue empties.

There's probably a reasonable limit per-flow for resource  
reservation, such as not sending more than the bandwidth you'd like  
to reserve, but even that's complicated (over what time horizon?) and  
doesn't help much if message-triggering events are synchronized.

One piece of useful advice we can and should give, I think, is to  
tell people to space error-induced re-attempts N seconds (where N is  
some reasonable number, such as 5), rather than trying to grab  
bandwidth, say, by continuously sending messages.

Personally, I see it has highly implausible that any well-behaved  
NSIS application would cause problems, compared to other non-rate- 
controlled streams such as UDP games and audio. Not-so-well-behaved  
NSIS, like any other such application, won't give a [bleep] about  
fancy algorithms.

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 20 Sep 2006 10:09:27 +0200

Hi Robert and Henning  

Regarding the D-mode, yes we are using it 
extensively in the RMD-QOSM, which is applied in environments where 
we can engineer the capacity of the signaling traffic.

Best Regards,
Georgios

-----Original Message-----
From: Robert Hancock [mailto:[email-masked]] 
Sent: woensdag 20 september 2006 3:57
To: 'Henning Schulzrinne'; 'Lars Eggert'
Cc: [email-masked]; [email-masked]
Subject: RE: [NSIS] Lars Eggert: DISCUSS and COMMENT: draft-ietf-nsis-ntlp

Henning, Lars, all,

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

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

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?

cheers,

r.

---

From: Lars Eggert <[email-masked]>
Date: Wed, 20 Sep 2006 14:54:23 +0200

Hi,

> Is this the seed of a solution?

I'd be happy with this approach.

> traffic (don't know if that is worth adding as a rider

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.

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

> albeit in different ways. Or do people want the token bucket

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?

Thanks,
Lars

---

From: "Robert Hancock" <[email-masked]>
Date: Wed, 20 Sep 2006 23:35:01 +1000

hi lars,

> From: Lars Eggert [mailto:[email-masked]] 
> Sent: 20 September 2006 22:54
> To: Robert Hancock
> Cc: 'Henning Schulzrinne'; [email-masked]; [email-masked]

awesome, to coin a phrase :-)

> for signaling seems like a good idea.

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

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

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

---

From: "Robert Hancock" <[email-masked]>
Date: Thu, 21 Sep 2006 00:01:02 +1000

hi john, lars, all,

some comments on the comments and discuss (not including the

> >  such messages guaranteed to be less than this limit in all cases?

on the MTU front: fair point. Probably the note in 5.8.1.2 should
really be in 5.3 (where it applies to all cases of D mode).
See below on actual message sizes.

> >  delivery. I don't see this case addressed in the document.

it's not addressed explicitly; the simple solution is not to 
distribute messages for the same SID over multiple associations.
if (for some reason) you need to create a new association while
an existing one is active, you can either close the existing one
gracefully (4.4.3) or use a MA-Hello request/response to flush
the connection. do you want this highlighted more?

[snip]

> >  Nit: Mixes US and British English (e.g., signalling vs. signaling,

signalling it is then ;-)

> >  issues with operating over some variants of SCTP.

true; the diagram is supposed to be indicating the general structure
rather than precisely the detailed stacks that can be used. Maybe add
a note that not all protocol combinations are possible and the allowed
ones are in 5.7?

> >  verified that Router Alert Options are safe to use in this regard?

its difficult to be definitive. however, we do believe while not all
routers can handle the RAO in their fast path, at least some can,
and that from that point of view it is the safest way to mark packets
for interception which also allows a subset of the marked packets to
be pulled out of the fast path for interception (which is basically
a requirement for the multi-application support). Further discussion
of the RAO is in the extensibility document. Basically, the path-
coupling mandate of NSIS requires packet interception, and the RAO 
appears to have the optimum design for that.

> >  couple of hops, this can still interfere with end-to-end NSIS

true. one approach would be to allow a Querying node to fall back to
encapsulating without the RAO if the first message(s) fail. However,
this would interact with other fallback processing (source address
setting, relevant to the NAT discovery case) and would also make the
interception more complex.

> >  reliability. Is there a better term for what is meant here?

I believe this is the same semantic that TCP provides (once you
take into account error conditions). I can't offer a better term.

> >  ...unless they are not delivered at all.

True.

> >  allowed to arrive after later messages have arrived?

Yes. Basically, if 'false', GIST does no better than the underlying
Internet, which can do what you say.

> >>       node requesting its downstream peer to create it.

I believe not. This document is not intended to specify 
NSLP behaviour normatively, so I think 2119 language would be
inappropriate.

> >  Nit: s/immediately the/immediately after the/

OK.

> >  interfaces. Is this mechanism robust under these conditions?

I think so. The mechanism is only measuring/reporting IP TTL change
to compare it to the IP TTL change that normal data packets would see.
So, given that the Query is being routed like a normal data packet
(including through the same interfaces), I don't see a problem.

> >  uses T1=5sec. (However, I think SIP uses 500ms, too?)

Yes, and that was the origin of the value here. The response is
supposed to be lightweight to generate, and it is important that
T1 is not too large since it is the basis for the time taken to
detect some critical failures (last node, node behind a NAT, etc.)

> >  specific to C-mode. 

I don't follow. The paragraph is entirely about C mode (since only
in this mode can these protocols be used).

> >  It would also be good to discuss in more detail
> >  512 bytes, if path MTU is unknown). 

We can say that.

> >  Additionally, because some
> >  that their payloads are always less than 512 bytes?

In theory no, because things like the cookies and peer identity
are variable length strings. But I just did a quick count, and
with a worst case for the other fields (e.g. using v6 addresses,
and a couple of possible stack proposals) adds up to about 150
bytes. So I think we are safe.

> >  Also, s/must/MUST/.

OK.

> >  probably be restructured after these changes.

Again, this is about C mode (see above).

> >  C-mode - what about D-mode?

D mode only uses UDP+nothing. No flexibility is intended; if 
you wanted to negotiate another protocol, one would do so with the
C-mode mechanisms. It is probably worth saying this explicitly.

> >  No restriction on message size. See DISCUSS.

Noted.

> >  Nit: Pseudocode not indented.

Indentation not needed (rule 4 contains six steps at the same
nesting level; the ifs are genuine 1-liners).

> >  mostly about a hypothetical mechanism.

Hmm.  It would seem that any discussion of special treatment
required for NAT traversal for a new protocol is *bound* to be
hypothetical while that spec is being written. What are you 
suggesting to be done with the section?

(BTW the mechanisms in this section have been implemented in
GIST nodes and NATs, although they are not as yet widely
deployed.)

> >  This subsection doesn't really belong under "Advanced Protocol

Yes, it turned out to be less advanced than we expected.
Are you suggesting it to be moved earlier? From the point
of view of the document structure I'd prefer to leave it
where it is - it isn't needed to understand the earlier
sections, which are already pretty long.

cheers,

robert h.

---

From: Lars Eggert <[email-masked]>
Date: Wed, 20 Sep 2006 16:27:23 +0200

Hi,

below, I've cut all the stuff I agree with in your original email.

> the connection. do you want this highlighted more?

I asume "this" is that only a single MA MUST be used for messages for  
the same SID? Then yes, please.

> appears to have the optimum design for that.

We should involve the RTG/INT ADs here. We just had a discussion in  
the IESG on a similar mechanism that used IP options, where the  
stance was basically that everything that forces stuff on the slow- 
path is almost a DoS on the router CPU.

> interception more complex.

Encapsulation would also alleviate the possible concerns due to use  
of an IP option for the previous comment, so this might be something  
that needs some investigation.

> bytes. So I think we are safe.

Since you were going to add MTU-related text anyway, it may be good  
to point out that if payloads grow past the MTU, C-mode SHOULD be  
used if possible.

> Again, this is about C mode (see above).

But not only about C-mode  - D-mode uses the same encapsulation  
format, no? (Similar to the prior comment, which should be located in  
the D-mode section, because it recommends to not use D-mode in a  
specific case.)

> sections, which are already pretty long.

Maybe just change the title of section 7?

Lars

---

From: "Robert Hancock" <[email-masked]>
Date: Thu, 21 Sep 2006 12:32:34 +1000

hi,

inline:

> Sent: 21 September 2006 00:27
> To: Robert Hancock

we'll add something to cover the topic.

> path is almost a DoS on the router CPU.

I think one needs to be careful here. Since we are talking about 
signalling to control the router, all the signalling that is relevant
to the router will almost certainly cause an impact on the router
CPU. The best we can do is to minimise the impact of signalling 
traffic which is not relevant to the router in question. Given that
we're mandated to use packet interception for path coupling 
following the basic RVSP model, this means that we need
- something in the packet that marks it as a potential
  signalling packet
- something in the packet that the router can check efficiently
  to see if the packet can be ignored
I believe the RAO is a fairly precise match for this requirement.
There is more discussion of this in section 3.4 of 
http://tools.ietf.org/wg/nsis/draft-loughney-nsis-ext-02.txt
(that text originally came from the GIST spec).

Side note: interception techniques have been a topic since the 
start of NSIS. It was one of the biggest discussion points 
during the NTLP early review (search for 'interception' at
http://www3.ietf.org/proceedings/04mar/235.htm; Dave and Fred
are Oran and Baker respectively). The point made there is that,
if you are a bad person and want to DoS the router, there are
easier ways than RAO, if you can find out a router IP address.
If you are not a bad person, you want to make sure that the
marked packets are as small as possible percentage of the overall
traffic, and C-mode enables that (and the RAO design allows
rapid filtering of whatever is marked).

I don't believe that the ecn-alternates use of options is strictly
comparable. ecn-alternates (and similar mechanisms) require a
read-write operation on the option field, rather than a filter
comparison. Also, I assume it would apply to a much larger 
proportion of the total traffic than we are expecting here.

> that needs some investigation.

I am not clear on this. Note that encapsulation without using the 
RAO may make packets less likely to be dropped (solves one problem), 
but it makes the interception process harder because it requires 
5-tuple analysis (in fact, for v6 it would require complete header
chain analysis), so it makes the previous problem even worse). So 
there is a tradeoff to be made.

OK.

> the D-mode section, because it recommends to not use D-mode in a  

Similar, but not the same. The same diagram for D mode would
- remove the security encpsulation annotation
- allow only a single GIST message
- have an optional RAO included (for Q-mode)
- have several different possible addresses in the IP header
  (for Q-mode)
- allow only UDP as a transport

In retrospect, I might be tempted to remove 5.4.2 or at least
figure 5 altogether, since it it actually technically wrong 
for the TCP case anyway (although in practice this seems to 
have caused no confusion!)

> Maybe just change the title of section 7?

'Additional'?

cheers,

r.