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

[Michael Welzl <[e-mail]>]

> On 25. mar. 2016, at 11.54, John Leslie <[e-mail]> wrote:
> 
> 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!

Sorry, I meant the in-network scheduler that decides which of the two paths packets will take.


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

Interesting!


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

…though these were just research musings anyway. I’m not at all proposing to design that in-network control loop with this draft.


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

Sure, that all makes sense to me - but you’re talking about operators dealing with today’s system. I don’t think that we want to design a congestion control based on the assumption that underutilizing won’t matter anyway?

Cheers,
Michael