Re: [tcpm] Can't we use newcwv for IW too?

[[e-mail]]

See in-lime...

> Hi,
>
> Even reading this 3 times doesn't make me understand it. Could it be that
> we have a misunderstanding and you're thinking of what RFC2140 calls
> "ensemble sharing", when what I mean is what RFC2140 calls "temporal
> sharing" ? Or are you just primarily concerned with a situation more
> complicated than I envisioned?
>
I was initially thinking of temporal sharing when the final TCB of an
earlier session is used to initialize parameters of a new TCP connection
to the same host.

> Let's see. I was only thinking of greedy applications for now. My idea was
> just that, if you have an application that e.g. stops sending and starts
> again, greedily, after 10 seconds, new-cwv has a clear rule on what cwnd
> should be.
>
All true for a bulk flow: new-cwv would leave the flow with the same cwnd
(likely) as TCP stack without new-cwv. AND in this case cwnd would reflect
the capacity of the network path that was used - validated in the language
of CWV (within a factor of 2 or less).

> And, if you replace this with an application that, as it stops, also
> closes the connection and after 10 seconds starts a new connection, and
> then immediately uses it to send, greedily, then there isn't much
> difference between this case and the case above, and IW could probably be
> set using a similar rule from new-cwv.
>
We may agree for bulk flows.

> More below:
>
> On 30. mai 2013, at 08:30, [e-mail] wrote:
>
>>
>> So here are some thoughts - if we were talking about "bulk" flows where
>> the cwnd reflects the network capacity to a specific destination, then
>> sharing of the cwnd is something that is being done by many stacks. In
>
> Until I sent my first email about this, I wasn't aware of that (but I got
> a private message telling me, straight away). I knew that some parts of
> RFC2140 are implemented, but I didn't expect cwnd to be reused beyond the
> end of a connection to set the next IW. Anyway, as Joe said, RFC2140 is
> informational, and I don't think it has clear rules about how long cwnd
> could be kept etc., so what I'm suggesting is to make a recommendation to
> let new-cwv consider a connection that terminates the same way as it
> considers a connection that enters the non-validated phase, and then
> allows re-using the cwnd in a following connection by noticing that the
> non-validated phase ends. If a very similar reasonable behavior is already
> out there, then I guess all I'm saying is "legalise it!"  :-)
>
*IF* the flow was validated when it closed, then using new-cwv rules for
decay of the value with time may be useful - this could control the size
of the contribution to the temporal pool for new flows, decaying with
time. i.e. the older the close was, the fewer the bytes you allow to be
reused in an initial window for a new flow.

If the values are not right in new-cwv, then I'd welcome that we can
discuss that...

>
>> reality the cwnd that is "shared" is often higher than that sustained on
>> the path, since this is inflated each RTT (the extra between 1 MSS and
>> cwnd).
>
> I don't get this; sorry if it should be obvious. We're talking about the
> time between the end of connection 1 and the beginning of connection 2,
> surely this cached value isn't then updated every RTT when there's nothing
> going on? And what do you mean with "the extra between 1 MSS and cwnd" ?
>
This is a small point that we have not discussed with respect to the final
value of cwnd in a closed flow.

cwnd reflects the estimate of what we think is safe for the next RTT,
rather than what was actually found to be safe from ACKs returned in the
last RTT (a fundamental difference between pipeACK and cwnd). I was simply
suggesting that we shouldn't restart at cwnd but 1/2 cwnd?

>
>> Now, if we have a flow that does not fully utilise cwnd (variously
>> called
>> thin,variable rate, bursty, intermittent, ...) then the cwnd can be much
>> higher than the that sustained on the path. RFC 2861, attempted to keep
>> the cwnd close to the actual used capacity, but this restricts the
>> dynamics o an application and adds latency to applications that are
>> bursty. Hence if we desire to enable these applications we should not
>> aggressively trim the cwnd to what was used.
>>
>> New-cwv tries to avoid unecessary cwnd growth, but proposes to avoid
>> forcing a low cwnd on a bursty application. Instead it creates a new
>> phase
>> (the non-validated phase) where cwnd exceeds the actual path capacity
>> used, and where the cwnd growth is capped, but importantly the
>> congestion
>> response is changed to reduce more I think this helps motivate
>> persistent
>> use of TCP.
>>
>> Now, my question is what cwnd value should be "shared" when the flow is
>> in
>> the  non-validated phase? - If a flow was to share non-valiudated cwnd,
>> and all flows implemented the new-cwv algorithm, then the flow that
>> received the "extra" cwnd would be non-validated, and that would be OK.
>> If
>> it were a normal TCP flow, then I think this inflates cwnd in an
>> unreasonable way.
>
> This last paragraph gives me the impression that you're thinking of
> ensemble sharing, not temporal sharing. I'm not suggesting giving away the
> cwnd of a flow while it's running (even if it's taking a break). Yes that
> could be reasonable as you sketch it (only for new-cwv-supporting flows,
> to make flows go from non-validated to validated), but it's just a more
> complicated beast than what I was thinking about.
>
It applies also to temporal sharing.

Here is the issue... when an app uses TCP as currently defined, it can
send as much or as little as it chooses. The cwnd reflects an upper limit
to the maximum the app can send on one RTT. For bulk flows the effect of
sharing is clear (above).

For a flow that has been sending less than cwnd, it would not be
reasonable to say that the non-validated cwnd value of a closed flow could
be used by a new flow that did not start in a non-validated phase. If this
happens, the flow could have "far too much credit".

Of course if the new flow also used new-cwv and restored other TCB state
it would be the same as if the same TCP flow had been used persistently.
That would be nice.

Gorry


> Cheers,
> Michael
>