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

From: [email-masked]
Date: Tue, 24 Jun 2003 06:57:42 +0300

Hi Bob,

Quick question for you:

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

Michael seems to be talking about flow-control on a hop-by-hop 
basis.  I've always considered congestion control as a end-to-end
mechanism.  What are your thoughts about having congestion control on 
a hop-by-hop basis - to me this sounds sub-optimal.

John

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

---

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

Hi all,

> a hop-by-hop basis - to me this sounds sub-optimal.

This is all wrong. Let me quote this sentence from my original
message:

> For instance, an occasional "source quench"-like message (from
> the receiver, not an intermediate router!) might suffice in
> such cases.

So I was talking about a message that would be semantically
similar to source quench but NOT something that would be used
on a hop-by-hop basis.

Flow control is the idea of protecting a receiver from
overload. Congestion control is the idea of protecting the
network from overload. Hop-by-hop flow control ... well ...
is the idea of protecting intermediate nodes from overload,
which clearly relates to congestion control - hop by hop
flow control can REALIZE congestion control. Just because TCP
does it on a strict end-to-end basis, that doesn't mean that
anything happening in between is NOT congestion control - RED
and ECN are good examples of network internal (hop by hop, if
you will) mechanisms that work nicely. ICMP SQ failed because
it doesn't scale.

Anyhow, that's not the issue here. This is just to clarify
what I meant - I meant rate-based congestion control, where
a receiver (not an intermediate hop!) would send an occasional
"reduce your rate" message instead of ack clocking.

Best regards,
Michael