Subject: RE: AW: [NSIS] framework: proposal on congestion/flow control

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 3 Jul 2003 11:13:20 +0100

hi henning,

> > in my view, the cost of congestion control is not the per-packet 
> > processing overhead; it's the architectural constraint that (so far
> > as we all can tell, I think) you can't send messages without 
> > knowing what congestion control state to apply, i.e. which 
> peer you are
> > sending to. so, applying congestion control directly to 
> PATH messages 
> > (for example) is liable to be non-trivial. 
> 
> This depends. I just submitted a draft, temporarily at
> http://www.cs.columbia.edu/~hgs/nsis/gimps/draft-schulzrinne-n
> sis-ntlp-00.html
> that tries to find a compromise similar to all existing 
> congestion-controlled transport protocols: the first small message is 
> (congestion-control) free. To be more precise, if you know 
> where you are 
> going, by previous state or some external knowledge (e.g., all your 
> non-local messages go through a border router or you are running a 
> link-state routing protocol that somehow conveys this 
> information or all 
> your routers support NTLP), you use an existing congestion-controlled 
> association. Large messages that could cause congestion 
> themselves are 
> always subject to congestion control.
> 
> After all, TCP SYN and kin aren't congestion controlled, 
> either, except 
> that their loss causes exponential back-off. I think the best we can 
> hope to do is to mimick this behavior in environments where the first 
> message goes off into the blue yonder.

I am familiar with the concepts you describe in that draft ...

It's clear that something can be done. The key point i was trying to make
was that the concept of a 'congestion controlled association' which you
can use because 'you know where you are going' is hard to match with 
the use of PATH-like methods for refresh/route change probing. Some people
think that's a big deal, some don't, but that's the point which needs to
be confronted and resolved (IMHO).

> > [As an aside, we've just finished writing an NSLP 
> definition which optionally
> > sends some messages outside the NTLP like this, to skip 
> processing in network
> > interior nodes - very like rfc3175 in fact. but it's very 
> hard to be convincing
> > that the result is network friendly overall. i'd be much 
> happier with a
> > congestion-controlling NTLP that was able to bypass 
> interior nodes the same
> > way. I suspect that argument is still to come.]
> 
> Nothing prevents 'short-cut' or 'express' NTLP connections, 
> in general. 
> This is just a matter of trivially tuning the discovery mechanism.
> 

Broadly, I agree with you, and I'd be happier with a protocol
that allowed this sort of 'express routing'. How it is done of course
depends on what the rest of the protocol looks like (e.g. does it even
have an identifiable discovery mechanism to be tuned in the first place).

There are two additional points I would emphasise:
a) Sometimes you really want messages to be routed through intermediate
NSIS-aware (but NSLP-unaware) nodes, but processed statelessly (e.g. 
flow-id re-writing in a NAT, or imposing a policy forwarding rule). 
So, it's hard to have the intermediate nodes completely drop out of 
the picture.
b) For scaling/aggregation reasons, you may want to be able to have some
messages bypass a lot of NSIS processing in interior nodes. 3175 grabs a new
protocol number and suggests modifications to the router alert option to
achieve this. We haven't really looked at this up to now.

cheers,

robert h.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 03 Jul 2003 17:02:20 -0400

> be confronted and resolved (IMHO).

Fundamentally, if one has no clue where the next hop is, there is no way 
to maintain congestion state, since congestion state is generally tied 
to some sort of association. The only other solution is to have a 
"global" congestion state, i.e., a state that limits the number of 
unacknowledged messages to any destination. If each node is only allowed 
to have one "unknown destination" packet in the ether at any one time, 
congestion is going to be bounded. This is clearly extremely 
conservative and would limit the concurrent number of sessions to a very 
small number, but I think it is provable that given the "know nothing" 
constraint, that's the best you can do for those messages.

In this context, I'd like to add some evidence to my contention that for 
most popular destinations, routing changes are rare, on the order of 
several days between events. See the paper

BGP Routing Stability of Popular Destinations
Jennifer Rexford, Jia Wang, Zhen Xiao, Yin Zhang
ACM SIGCOMM IMW (Internet Measurement Workshop) 2002
http://citeseer.nj.nec.com/rexford02bgp.html

for the details. Thus, there may be better ways to deal with these than 
probing every 30 seconds. I can think of a number of heuristics. I 
suspect that a 30-second probing interval is both too long and too 
short. It's too long if your signaling state is critical to the session 
and too short for efficiency and scaling. For example, for QoS, it might 
be better to use indications of trouble (packet loss) or change (changed 
TTL, for example) to resend the signaling message. If there's a routing 
change with a transient or flapping, it is not clear that any signaling 
protocol can keep up during that period of instability or that this is 
useful. By the time you've gotten AAA permission from the new routers, 
the route has oscillated again...

> have an identifiable discovery mechanism to be tuned in the first place).

 From what I can tell, it is not too difficult to provide this as an 
option. It does not appear to add any appreciable complexity to NTLP.

> So, it's hard to have the intermediate nodes completely drop out of 

We clearly want to allow nodes that are 'generally aware', i.e., process 
all messages, but are a no-op at the NSLP level. I used the term 
omnivorous for those at some point :-)

> achieve this. We haven't really looked at this up to now.

There are probably three levels of ignorance:

(1) bypass at router alert level
(2) see NTLP message, but forward without inspection or modification 
(transparently)
(3) do NSLP-unaware processing (allow modification of NTLP)