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

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 19 Jun 2003 20:20:50 +0100

dear all,

as the fragmentation debate dies away (at least for now),
my next f/w open issue is where responsibility for overload 
handling should go; specifically, what functionality (if
any) should the NTLP have in protecting the network from
congestion, and assisting the NSLP in detecting and adapting
to overload higher up in the protocol stack.

the arguments on all sides seem to me to be unclear and complex.
once my summary email got beyond 5 pages i decided to put them
in an i-d instead, which (while it goes through the editor 
queue) you can find here:
http://sigcomp.srmr.co.uk/~reh/draft-hancock-nsis-overload-00.txt

i'll just list the proposed tentative conclusions here:
   1. The NTLP needs to prevent network overload in the IP layer between 
   NTLP peers (i.e. should enforce congestion control).
   2. However, NSLPs need to detect and adapt to overload within the 
   NSIS protocols themselves (i.e. they can't just 'send blind')
   3. Detection may take place by noting messages dropped by the NTLP, 
   as well as any flow control imposed by the NTLP.

these conclusions are tentative because they depend on 
various assumptions (which may be wrong) and tradeoffs 
(which could be balanced either way), which are all discussed
in the draft. so, you might like to read it. on the other hand,
you might like to jump in and sound off straight away, which is
fine too. i'll try to keep track.

happy debating,

robert h.

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

---

From: Michael Welzl <[email-masked]>
Date: 20 Jun 2003 08:33:46 +0200

Hi all,

I'm (somewhat) new to this group, so please forgive me if
I'm talking nonsense.

Having said that, I just read this document, and my
opinion is:

- I agree that, in general, congestion control should be
  done by the NTLP (after all, doing congestion control
  on top of congestion control means stacking a control
  loop on top of another one).

- I agree that a NSLP should provide a flow control mechanism
  to cope with NSLP-layer overload

BUT:

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.

In (_ONLY_) these cases, the NSLP should handle
network congestion to some degree at least. A first step
in this direction could be to limit the signaling
traffic appropriately - e.g., make it a fraction of
payload, as would be natural for NORMAL and REFRESH
messages. It then automatically scales with payload
traffic in a linear manner; I think that this is
specified for RTCP.

The problem is, of course, that these messages may
need to be sent in times of interrupted payload
traffic, so the enforcement should perhaps not be
strict but use a rate limiter such as a token bucket...
which could make things quite complex.

Maybe it would suffice to mention that sometimes,
NSLPs would probably have to use UDP, and that
they should handle congestion in these cases.

Best regards,
Michael Welzl

-- 
Michael Welzl <[email-masked]>
University of Innsbruck