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

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 24 Jun 2003 00:24:20 +0100

dear all,

i think my sympathies are with Bob here. if it is worth implementing 
congestion control at all, we should use it for all the signalling 
traffic.

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. 

some detailed points:
*) shouldn't we generally try to avoid 'magic numbers' (like 5%) in the 
protocol suite architecture?
*) i can see that it makes sense for signalling to have resources 
engineered for it. however, NSIS protocols will have to be deployed 
incrementally, and will short (and very likely long) term need to operate
over network clouds with no QoS support at all. so, I don't think we can 
depend on this as a general solution.
*) we have agreed earlier (I think) that a signalling
application isn't forced to use the NTLP to transport all its messages. the
question at hand is, should the NTLP guarantee that it will forward messages
adaptively (so as not to cause congestion) - then an NSLP which *only* uses
the NTLP is pre-guaranteed to be network friendly.
[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.]

cheers,

r.

> -----Original Message-----
> From: Bob Braden [mailto:[email-masked]]
> Sent: Monday, June 23, 2003 18:56
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: AW: [NSIS] framework: proposal on congestion/flow control
> 
> 
>   *> 
>   *> > Michael,
>   *> > 
>   *> > I could be wrong, but it seems to me that to do 
> congestion control you
>   *> > need state.  The issue is when that state is 
> established.  In the case
>   *> > of ephemeral messages that you want to send using UDP 
> (or better,
>   *> > DCCP), I would think that the state could be set up 
> roughly once, when
>   *> > two neighbor nodes first discover each other.  So, 
> it's a question of
>   *> > when, not whether, to establish state.
>   *> > 
>   *> > Bob Braden
>   *> 
>   *> I agree, but It's also a question of how much state you
>   *> establish, or (more important) how often you need to update it.
>   *> DCCP requires a lot of state and acks every packet, which is ok
>   *> for any long-term data transfer, but I thought that there might
>   *> be sporadic messages in signaling (error messages of some
>   *> sort ... keepalives ... stuff like that) where this would be
>   *> unnecessary overhead.
>   *> 
>   *> For instance, an occasional "source quench"-like message (from
>   *> the receiver, not an intermediate router!) might suffice in
>   *> such cases. Rate-based open-loop instead of window-based
>   *> closed-loop congestion control, perhaps using rather old
>   *> state (as you mention - it is indeed a question of when!).
> 
> Michael,
> 
> I believe that you are confusing congestion control with flow control.
> The "source-quench-like" or windowing mechanisms you describe are
> hop/hop flow control.  Congestion control has to do with the 
> interaction
> of the signaling traffic with other Internet traffic.  We don't
> want signaling traffic to starve out other traffic, either TCP traffic
> or realtime traffic.  Internet transport is supposed to be 
> "TCP-friendly".
> I have not looked at DCCP lately, but I assume it has the minimal
> mechanism required for honest Internet congestion control.
> 
>   *> 
>   *> And even without setting up any kind of state, it is reasonable
>   *> to limit the rate of signaling traffic: if a node generally
>   *> keeps its signaling traffic below, say, 5% of the payload it
>   *> generates, the whole signaling traffic in the whole network
>   *> will not exceed 5% of the whole payload traffic. This means
>   *> that signaling traffic scales linearly with payload (which
>   *> can, in turn, be expected to be limited through congestion
>   *> control) ... while this is not as good as full-fledged
>   *> congestion control, it's a start. I think that such a limit
>   *> was also specified for RTCP, btw.
> 
> As you imply above, the notion of sporadic needs to be made more
> precise, because there can be bursty behavior even when the
> steady-state rates are reasonable.  Suppose that a route changes, so a
> lot of reservations have to be signaled at one time.  The initiating
> NSIS node and the recipient NSIS node may be perfectly happy to blast
> across these reservation packets, but the result could be like a DoS
> attack on the link!
> 
> Is your fixed percentage bound good enough?  I don't know.  5% FEELS
> OK, because it seems negligble, and we assume there are not 10 other
> fixed overheads each taking 5%.  There is only one NSIS flow (or is
> there?)  And if the other traffic is low, you might want to let
> signaling take a higher percentage.  And the situation might be
> different in the core of the network and in the edge.  Finally,
> such rate limiting is NOT congestion control, since it does not
> react dynamically to congestion.  It is like an RTP media stream.
> 
> It always seemed me reasonable that NSIS (or RSVP) traffic should
> be given its own scheduling class (e.g., diffserv code point), but
> nobody seemed to agree.
> 
> None of this is to say that I know the answer here; it's a hard
> problem.  As a practical matter, the AD (;-)) will decide what
> congestion control in NSIS is good enough.  But then, if NSIS
> were easy, it would have been done 5 years ago, I guess.
> 
> Bob Braden
> 
>   *> 
>   *> Doing this would be my recommendation for such sporadic
>   *> messages.
>   *> 
>   *> Best regards,
>   *> Michael
>   *> 
> 
> _______________________________________________
> 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: Henning Schulzrinne <[email-masked]>
Date: Mon, 23 Jun 2003 22:30:17 -0400

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

> protocol suite architecture?

I don't see how any magic number can make sense. RTP uses a 5% default 
for RTCP, but it is in relation to a well-defined 'payload bandwidth', 
the media stream itself. There is no similar ratio for NTLP, 
particularly once you stray a bit beyond the well-trod field of QoS 
signaling. If you ask for a large reservation, are you allowed to send 
more signaling messages? That seems the wrong incentive.

> depend on this as a general solution.

I agree that edge-to-edge signaling will be common. I think we want to 
engineer a 'safe' protocol that operates according to well-established 
'good neighbor' principles even if the application differs from what we 
can currently picture. As a somewhat far-fetched example, consider an 
application that updates all routers along a path with some 
active-network code. It's far more efficient to do this with NTLP than 
having individual transport connections from the origin to each router, 
but there's no sensible 5% limit (over what time horizon? compared to 
what bandwidth?) and the messages can be large.

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

Henning

---

From: Michael Welzl <[email-masked]>
Date: 24 Jun 2003 09:27:18 +0200

Hi all,

> congestion control at all, we should use it for all the signalling 

My original point was that even signaling traffic that would use
UDP anyhow should have SOME kind of congestion control. I wasn't
aware that the idea is to use full-fledged TCP or DCCP for each
and every type of signaling, but that's fine with me.

> (for example) is liable to be non-trivial. 

Right.

> protocol suite architecture?

Hmm, I agree. Magic number are a problem indeed.

> depend on this as a general solution.

Right.

> way. I suspect that argument is still to come.]

I would also be happier with prescribed congestion control for
everything and no means to bypass it. I still claim that, in a
perfect world, a congestion control mechanism should be tailored
for the specific type of signaling message, but

a) we have no solution at hand
b) we'd better use SOME than NO congestion control

So, I fully agree with everything you say.

Best regards,
Michael