Re: [iccrg] [Stackevo-discuss] New Version Notification for draft-welzl-irtf-iccrg-tcp-in-udp-00.txt

[John Leslie <[e-mail]>]

Michael Welzl <[e-mail]> wrote:
>...
> so then how do you solve the 2-path problem I explained above? ...
> Consider an empty network. Path 1 has capacity X. Path 2 has capacity
> 3*X. Some device in the network decides to round-robin schedule packets
> from a single TCP connection across paths 1 and 2.
> Congestion will first appear on path 1. TCP will react, halving its
> cwnd. Most of the capacity of path 2 will always remain unused that way.
> 
> How do you solve this with e2e congestion control?

   Obviously, as you design the example, you don't.

   Neither the e2e sender nor the e2e receiver has enough knowledge if
some device along the path decides to switch paths without notice.

   (Fortunately, we don't have to discuss the case where the receiver
get notice of which path was used but the sender must guess which
path will be used!)

>... 
> The only solution I can see to my problem above is not to schedule
> traffic as I described it. Obviously the scheduler should send more
> packets on path 2 than on path 1.

   Whadaya mean, "the" scheduler? I see at least two of them here!

> Doing this correctly requires knowing the capacities of these links.

   Indeed. If the round-robin scheduler chooses to ignore the difference
in capacities, the TCP scheduler can't expect to overcome that.

   (There are operators which do this sort of thing: usually they manually
adjust things so the capacities are "close enough" and make _some_ effort
to avoid this sub-network becoming a bottleneck.)

> Considering a more dynamic network situation, it requires knowledge
> about where the bottleneck currently is, and how much capacity is
> available per link. This is a control loop.

   We have been spoiled by bottlenecks being mostly stable. They won't
always be.

   The question of where a bottleneck "currently is" isn't really knowable.
They tend (in 2015) to be stable enough that it _seems_ knowable; but
even "currently" doesn't really mean what we think it does.

   Operators find that certain "bottlenecks" can be quickly fixed by
shifting/adding capacity, while others resist that solution. Consequently,
they play _that_ whack-a-mole game; and this tends to drive "current"
bottlenecks close to the end-users. 

> If you put such a control loop in the network, you may want to give it
> a different name than me, but this is what I meant when I said
> ???this would require putting congestion controls inside the network???.

   I suspect that "a different name" would be very helpful...

   There is a lot of history of "congestion control" in networks, mostly
based upon admission-control. This seems to me less than compatible with
the TCP model of congestion control.

> As per my example above, this would mean that you???d need something
> quite similar to congestion control inside the network, or the available
> capacity for packets on all these paths must be equal, all the way to
> the receiver - else you???ll end up underutilizing your network.

   Operators _don't_ have the same horror about "underutilizing" that
you do.

   It turns out to be very practical to drive the bottlenecks close to
the endpoints; and aggregation tends to ameliorate under-utilization...

--
John Leslie <[e-mail]>