Subject: [tcpm] Feedback on usage and deployment recommendations in draft-ietf-tcpm-initcwnd-03

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 29 Mar 2012 13:49:33 +0200

I've looked through the changes in the last revision again and I do look 
forward to finding out more at the TCPM WG meeting.

In general: I think the experiment with IW=10 is OK with me, but I am 
not sure that this draft has yet addressed the other things that were 
brought up over the time, in the mailing list.

My comments are below, mainly on understanding the impact on non-TCP 
applications, which seem to be the most likely to suffer collateral 
damage from sharing a network bottleneck with the updated mechanism.

Gorry

#####
The ID says:
    However, since the increase is one-time only (at the
    beginning of a connection), and the rest of TCP's congestion backoff
    mechanism remains in place, it's highly unlikely the increase will
    render a network in a persistent state of congestion, or even
    congestion collapse.

- I think the impression here is not entirely true. It would be nice to 
note there is no limit to the number of new TCP sessions that can start 
over a network link, and explain this ... since this a partly a 
motivation for back-off in TCP.

#####
    Although no severe unfairness has been detected on
    all the known tests so far, further study on this topic may be
    warranted.

- Pity we have not seen more studies with non-TCP flows.
- This section only partly capture my concerns.

#####
Section 8:
    The negative impact can be mitigated by hosts directly connected to a
    low-speed link advertising a smaller initial receive window than 10
    segments.

- True although I think this remedy is not so easily deployed.

And
    This can be achieved either through manual configuration by
    the users, or through the host stack auto-detecting the low bandwidth
    links.

- I do not agree with this statement at all. I strongly oppose the idea 
of requiring users to manually configure key transport parameters based 
on their understanding of the path. This seems a very undesirable way of 
solving this problem.

[I'm intrigued at how an end point can determine there is a slow link on 
the path by "auto-detecting the low bandwidth links" - are there robust 
algorithms that can do this? I've seen a lot of proposals over the years 
from things, even local interface speed (seriously flawed approach for 
finding the min path bandwidth).]

- I would REALLY like to see some simple method specified that is a part 
of this experiment. I do not believe there is one value that works for 
all paths.  I could make a strawman suggestion:

	If the sender looses a segment after the SYN to a specific
	IP host and within the first IW segments using IW>3,
         then the IP host SHOULD use a window of not more than 3
         segments for all new TCP connections to the same IP address
         (on the same interface) for the next 1 hour.

(It could be argued this should also happen on loss during rw for flow 
restart.)

I think should also update restart window for the conenction, as 
described in the ID.

I know there are issues with this: It does not catch all flows from a 
host (which would useful if the host were doing P2P), it may not always 
prevent collateral disruption - but it really would help. Any thoughts 
from others? If the experiment shows that the feature is rarely 
triggered, or doesn't benefit, then we'd be wiser - by guess is that it 
helps a lot in specific scenarios were IW=10 will be painful.

#####
    Furthermore, non-TCP traffic (such
    as VoIP) should be monitored as well. If users observe any
    significant deterioration of performance, they SHOULD fall back to an
    initial window as allowed by RFC 3390 for safety reasons. An
    increased initial window SHOULD NOT be turned on by default on
    systems without such monitoring capabilities.

- While I agree with the sentiment, how does this ID actually address 
these concerns? (see previous).

#####
NiT: I think the abstract reads like it is direct replacement for IW=3, 
which doesn't seem quite appropriate for an experimental update.

#####
I understand IW=1, IW=3 and would like to see IW=10 more widely 
available. I don't yet understand a benefit from finely tuning IW, so 
I'm not sure we need to tune IW.  As I see it, the key benefit is to 
apps that need to send ~6 to ~30K, I'm not sure I would break other 
Internet traffic to support this. I think my comments above cab be 
addressed by the group - so I am keen to see other thoughts/experience.

Gorry

---

From: Joe Touch <[email-masked]>
Date: Thu, 29 Mar 2012 11:36:59 -0400

On Mar 29, 2012, at 7:49 AM, Gorry Fairhurst <[email-masked]> wrote:

> 
> I've looked through the changes in the last revision again and I do look forward to finding out more at the TCPM WG meeting.
> 
> In general: I think the experiment with IW=10 is OK with me, but I am not sure that this draft has yet addressed the other things that were brought up over the time, in the mailing list.
> 
> My comments are below, mainly on understanding the impact on non-TCP applications, which seem to be the most likely to suffer collateral damage from sharing a network bottleneck with the updated mechanism.
> 
> Gorry
...
> - I do not agree with this statement at all. I strongly oppose the idea of requiring users to manually configure key transport parameters based on their understanding of the path. This seems a very undesirable way of solving this problem.
> 
> [I'm intrigued at how an end point can determine there is a slow link on the path by "auto-detecting the low bandwidth links" - are there robust algorithms that can do this? I've seen a lot of proposals over the years from things, even local interface speed (seriously flawed approach for finding the min path bandwidth).]
> 
> - I would REALLY like to see some simple method specified that is a part of this experiment. I do not believe there is one value that works for all paths.  I could make a strawman suggestion:
> 
> (It could be argued this should also happen on loss during rw for flow restart.)
> 
> I think should also update restart window for the conenction, as described in the ID.
> 
> I know there are issues with this: It does not catch all flows from a host (which would useful if the host were doing P2P), it may not always prevent collateral disruption - but it really would help. Any thoughts from others? If the experiment shows that the feature is rarely triggered, or doesn't benefit, then we'd be wiser - by guess is that it helps a lot in specific scenarios were IW=10 will be painful.
> 
> #####

This is basically what I proposed as an alternative, but I include a way to use the lack of lows to increase the IW over time too.

IMO this is the better way to proceed, rather than to use static, no reactive approaches or just ones that back off.

> #####
> NiT: I think the abstract reads like it is direct replacement for IW=3, which doesn't seem quite appropriate for an experimental update.
> 
> #####
> I understand IW=1, IW=3 and would like to see IW=10 more widely available. I don't yet understand a benefit from finely tuning IW, so I'm not sure we need to tune IW.  As I see it, the key benefit is to apps that need to send ~6 to ~30K, I'm not sure I would break other Internet traffic to support this. I think my comments above cab be addressed by the group - so I am keen to see other thoughts/experience.

fwiw I agree - tuning IW isnt needed, but a coarsely reactive IW over long timescales remains safer.

Joe