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

From: Bob Braden <[email-masked]>
Date: Sun, 22 Jun 2003 15:07:05 -0700 (PDT)

*> Hi,
  *> 
  *> >   *> 
  *> >   *> Some signaling messages may only be of a sporadic nature
  *> >   *> (e.g. the RETRY or REPAIR messages in the draft) - for
  *> >   *> such messages, the initial negotiations of protocols such
  *> >   *> as TCP and DCCP would be unnecessary overhead (if a
  *> >   *> routing protocol used DCCP to convey its messages, it
  *> >   *> would introduce additional state in routers!), so UDP
  *> >   *> would be the protocol of choice.
  *> >   *> 
  *> > 
  *> > I wonder how you can do congestion control without state at each end,
  *> > which requires setup.  How does it help to use UDP and move the
  *> > congestion state into the "application", i.e., into NSLP?  It would
  *> > seem that DCCP is what the doctor ordered here.
  *> 
  *> If you think that this is reasonable for each and every type
  *> of signaling message (no cynism here - I'm just not sure), then
  *> I agree. I only wanted to make a case for some kind of rate
  *> limiting function instead of
  *> congestion-control-for-some-cases-and-nothing-at-all-otherwise.
  *> 
  *> Best regards,
  *> Michael

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

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

---

From: Michael Welzl <[email-masked]>
Date: 23 Jun 2003 08:09:42 +0200

Dear Bob,

> when, not whether, to establish state.

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

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.

Doing this would be my recommendation for such sporadic
messages.

Best regards,
Michael