Subject: [tcpm] removing TCP's initial window

From: Mark Allman <[email-masked]>
Date: Tue, 24 Nov 2015 12:43:08 -0500

A proposal for allowing end hosts to set their initial cwnd to
whatever they want ... in the canonical form that we use to propose
such things ...

  draft-allman-tcpm-no-initwin-00.txt

allman

--
http://www.icir.org/mallman/

---

From: Theodore V Faber <[email-masked]>
Date: Wed, 25 Nov 2015 00:07:43 +0000

Seconded.

Replace “congestion” with “congest” in 2(c).

Rock on.

-- 
Ted Faber <[email-masked]>
Engineering Specialist
Computer Systems Research Department
310-336-7373

On 11/24/15, 09:43, "tcpm on behalf of Mark Allman" <[email-masked]

---

From: Rick Jones <[email-masked]>
Date: Tue, 24 Nov 2015 16:54:33 -0800

>    draft-allman-tcpm-no-initwin-00.txt

Admiral Farragut would be pleased :)

In the vein of giving an inch and they will ask to take a mile, if such 
a paced, large IW is OK for the start of a connection, would it also be 
OK for "slow start after idle?"  Or perhaps the lesser of that IW and 
cwnd when the connection went idle.

rick jones

---

From: Theodore V Faber <[email-masked]>
Date: Wed, 25 Nov 2015 01:01:07 +0000

Well said.

On 11/24/15, 16:54, "tcpm on behalf of Rick Jones" <[email-masked]
on behalf of [email-masked]> wrote:

>_______________________________________________
>tcpm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tcpm

---

From: Mark Allman <[email-masked]>
Date: Tue, 24 Nov 2015 22:46:35 -0500

> Admiral Farragut would be pleased :)

Ha!

> In the vein of giving an inch and they will ask to take a mile, if
> such a paced, large IW is OK for the start of a connection, would it
> also be OK for "slow start after idle?"  Or perhaps the lesser of
> that IW and cwnd when the connection went idle.

Perhaps.  The difference is that in this case the host has *some*
notion of the path it is traversing.  But, at some point that notion
is so dated that indeed treating it like a brand new connection from
a CC standpoint seems OK to me.  But, there are probably more
considerations here than at the start of a connection.

allman

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 24 Nov 2015 22:13:35 -0800

Hmm. Is there any guidelines to apply this? We don't need TCB sharing for this?
Also, why it's BCP?

Thanks,
--
Yoshi

---

From: SALLANTIN Renaud <[email-masked]>
Date: Wed, 25 Nov 2015 10:46:06 +0100

In 1(C), I think that "pacing" needs to be defined.

I am in favor of a lower and an upper limit for the pacing time between 2 segments transmission.

If the number of segments you have to send across the RTT makes the pacing time lower than a minimal value (TBD), then we'd better not pace. 
Indeed, pacing adds an unnecessary complexity. 

If the number of segments you have to send across the RTT makes the pacing time higher than a maximal value (TBD), then we'd better use this upper limit as pacing time.
Indeed, after a certain value, increasing again the pacing time between 2 segments transmission is useless and harmful:
*it does not reduce the congestion impact on your segments transmission; 
*but it adds an unnecessary (and long) delay in case of long RTT. For example, pacing without upper limit an IW of 10 segments in satcom adds around 500ms...

I know that many points have to be discussed, and that's why we would be interested in a draft on the Pacing.

[@@ THALES ALENIA SPACE INTERNAL @@]

-----Message d'origine-----
De : tcpm [mailto:[email-masked]] De la part de Yoshifumi Nishida
Envoyé : mercredi 25 novembre 2015 07:14
À : Mark Allman
Cc : [email-masked]
Objet : Re: [tcpm] removing TCP's initial window

Thanks,
--
Yoshi

---

From: Michael Welzl <[email-masked]>
Date: Wed, 25 Nov 2015 11:19:30 +0100

I very much agree about TCB sharing.

On the other hand, I also very much agree with the first sentiment expressed in the "reasoning" list:

***
    (a) The author thinks that talking about the initial window for the
        better part of two decades is probably enough.  And, definitely
        boring.
***

So all in all, I appreciate this proposal a lot  (and admittedly, I'm also becoming a fan of Mark's combined sense of humor and system design  - I still think that tcpx2 was the best solution ever proposed to solve header space issues).

Cheers,
Michael

> On 25 Nov 2015, at 07:13, Yoshifumi Nishida <[email-masked]> wrote:
>

---

From: Mark Allman <[email-masked]>
Date: Wed, 25 Nov 2015 07:47:45 -0500

> Hmm. Is there any guidelines to apply this?

Not sure I follow.

(I mean, clearly, it isn't fleshed out very well.  It was just a
sketch to see if there are any actual legs to it.)

> We don't need TCB sharing for this?

Nope.

> Also, why it's BCP?

Oh, sorry.  That is because I quickly re-used the boilerplate from
something else.

allman

---

From: "Agarwal, Anil" <[email-masked]>
Date: Wed, 25 Nov 2015 14:05:43 +0000

Few thoughts -

1. Following statement is probably not true in many cases,

   e.g., cellular and satellite access networks.

   " (c) An overly aggressive IW is likely to congestion (sic) local networks

        before burdening remote portions of the path"

   An overly aggressive IW will cause congestion at cellular/satellite head-end.

2. Following rationale is a bit weak -

   " (g) Ultimately, being egregiously overly aggressive will not be in

    the sender's best interest---e.g., there will be a fight for

    local resources among the sender's own connections---and

    therefore there is an incentive to be reasonable."

   If being overly aggressive does not affect the sender's own local resources,

   but affects remote resources instead, a sender might feel incentivized to be

   more aggressive than others, perhaps resulting in an IW-arms-race.

3. Rule (3) in section 1 describes actions after packet drops. We presume it applies to

   ECN marks as well.

4. It would seem logical that IW simply not be a one-size-fits-all value for a given server.

   A server serves many clients with different time-varying path characteristics.

   Making IW a function of the client path characteristics, perhaps based on TCB sharing

   and/or cached historical information and/or configured parameters would seem to be prudent.

Anil

-----Original Message-----
From: tcpm [mailto:[email-masked]] On Behalf Of Mark Allman
Sent: Wednesday, November 25, 2015 7:48 AM
To: Yoshifumi Nishida
Cc: [email-masked]
Subject: Re: [tcpm] removing TCP's initial window

Not sure I follow.

(I mean, clearly, it isn't fleshed out very well.  It was just a sketch to see if there are any actual legs to it.)

Nope.

> Also, why it's BCP?

Oh, sorry.  That is because I quickly re-used the boilerplate from something else.

allman

---

From: Mark Allman <[email-masked]>
Date: Wed, 25 Nov 2015 09:28:11 -0500

> If being overly aggressive does not affect the sender's own local
> resources, but affects remote resources instead, a sender might
> feel incentivized to be more aggressive than others, perhaps
> resulting in an IW-arms-race.

Yeah- but the thing is that IW isn't the overall driver here.  That
is, I could try to dump as much as the advertised window would
allow.  But, if I see loss then I have to revert back.  And, I have
to repair that loss.  And, so ultimately there is a check here.

> 3. Rule (3) in section 1 describes actions after packet drops. We

(Sure.)

> value for a given server.  

Right.  There is no one-size-fits-all.  And, so we---and I am
clearly as much to blame as anyone---have chosen a
one-size-fits-nobody approach.

> A server serves many clients with different time-varying path
> characteristics.  Making IW a function of the client path
> characteristics,

Right.  The ideal IW depends on the time-varying conditions.  The
problem is that when starting up we don't have much of an idea about
this.

> perhaps based on TCB sharing and/or cached historical information
> and/or configured parameters would seem to be prudent.

I don't disagree.  Nothing in the draft precludes any of this.  That
is, the draft frees implementations to use whatever they deem as
reasonable for the initial window.  That could be a constant based
on their own upstream.  Or, some function based on the RTT during
the 3WHS.  Or, based on historical characteristics of the given
remote IP / routed block.  Or, whatever.  There are lots of ideas in
the air for arriving at something sensible.  And, there is not one
"sensible" for all situations.  So, let's stop pretending there is
some magic number that solves this and just let implementations /
instantiations puzzle through it for themselves.

allman

@mallman_icsi

---

From: SALLANTIN Renaud <[email-masked]>
Date: Wed, 25 Nov 2015 17:36:37 +0100

Why not pace the IW of less than 10 segments? 

-----Message d'origine-----
De : tcpm [mailto:[email-masked]] De la part de SALLANTIN Renaud
Envoyé : mercredi 25 novembre 2015 10:46
À : 'Yoshifumi Nishida'; 'Mark Allman'
Cc : [email-masked]'
Objet : Re: [tcpm] removing TCP's initial window

If the number of segments you have to send across the RTT makes the pacing time higher than a maximal value (TBD), then we'd better use this upper limit as pacing time.
Indeed, after a certain value, increasing again the pacing time between 2 segments transmission is useless and harmful:
*it does not reduce the congestion impact on your segments transmission; *but it adds an unnecessary (and long) delay in case of long RTT. For example, pacing without upper limit an IW of 10 segments in satcom adds around 500ms...

-----Message d'origine-----

Thanks,
--
Yoshi

---

From: Mark Allman <[email-masked]>
Date: Wed, 25 Nov 2015 11:56:29 -0500

> Why not pace the IW of less than 10 segments? 

I didn't say not to.  I said for IW > 10 you MUST.

If you want to, great.  But, we have already agreed on IW10 without
pacing and so it seems like we don't need to add a requirement for
pacing there.

allman

---

From: Joe Touch <[email-masked]>
Date: Wed, 25 Nov 2015 10:43:54 -0800

I like the assumptions, esp. that AQM is widely deployed, but they're
just that - assumptions.

I'd like to see some evidence this approach is safe first, because
pacing traffic out seems more likely to mask a "tragedy of the commons"
issue than bursting would have, esp. when AQM isn't available.

Joe

---

From: Rick Jones <[email-masked]>
Date: Wed, 25 Nov 2015 11:24:12 -0800

> issue than bursting would have, esp. when AQM isn't available.

Much as I'd like to see bursting the IW (Damn the torpedoes and all 
that) because it would enable using TSO/GSO, why would pacing mask a 
tragedy of the AQM-less commons?  If there is no AQM available at the 
bottleneck, it will either trigger a drop at the tail of the queue or 
not, and if it does not, all we have is a slight (one RTT?) delay before 
the sender "really" dumps a load on the bottleneck.

Heck, if we are lucky (well, are we, ever?) that paced IW if it does get 
through without drops may complete the sending to be done anyway, and if 
it doesn't, it suggests there was going to be a queue fill/overflow if 
we started with a classic, smaller IW anyway.  If not during the 
classic, smaller IW itself then during the subsequent RTTs.

rick jones

---

From: Joe Touch <[email-masked]>
Date: Wed, 25 Nov 2015 11:32:15 -0800

> the sender "really" dumps a load on the bottleneck.

Losses can occur all along a path, they don't have to occur only at one
bottleneck. If you burst, you're more likely to see a drop in one of
those locations than if you pace things out.

In a sense, bursting is like a heavy-handed version of packet-pair in
terms of measuring the drop behavior along the path - you're more likely
to create a situation where you cause a drop of your own packets,
because you're the dominant occupant of the queues at a given router.

> classic, smaller IW itself then during the subsequent RTTs.

Except that if you run over several RTTs, you run a greater chance of
experiencing a drop during one of those RTTs on the way to a larger window.

Joe

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 25 Nov 2015 20:59:08 +0100

> On 24 Nov 2015, at 18:43, Mark Allman <[email-masked]> wrote:
> 
> 
Hi Marc,

I really like and support this document. Wouldn't is make sense
not to restrict this document to TCP, but also cover SCTP?

Best regards
Michael

---

From: Mark Allman <[email-masked]>
Date: Wed, 25 Nov 2015 15:06:10 -0500

> not to restrict this document to TCP, but also cover SCTP?

Absolutely.  While I am kicking one beehive, I might as well kick
two! :-)

It is fun to know that I can still make enough noise to make people
think.

allman

---

From: Joe Touch <[email-masked]>
Date: Wed, 25 Nov 2015 13:30:09 -0800

One other point to consider:

	If you're seeing loss, it also means you might be causing
	loss for others too.

That's why we increase the window gently until we know better, and why
getting one packet through might be permission to send another, but
should not be interpreted as being safe to send a lot.

Joe

---

From: SALLANTIN Renaud <[email-masked]>
Date: Thu, 26 Nov 2015 11:30:07 +0100

Unlike for Jumpstart, you do not modify the TCP behavior after the IW transmission. 
Don't you think that, in some cases, double the IW may trigger some congestion? 
Would it be possible to refine the mechanism, and for example, determine what should be used in the following RTTs  (slow start or CC) in function of the IW size? 

-----Message d'origine-----
De : tcpm [mailto:[email-masked]] De la part de Mark Allman
Envoyé : mardi 24 novembre 2015 18:43
À : [email-masked]
Objet : [tcpm] removing TCP's initial window

A proposal for allowing end hosts to set their initial cwnd to whatever they want ... in the canonical form that we use to propose such things ...

allman

---

From: Mark Allman <[email-masked]>
Date: Mon, 30 Nov 2015 09:30:34 -0500

> Unlike for Jumpstart, you do not modify the TCP behavior after the

I am not sure if I follow.

Regardless of what the IW is or how that is arrived at I think it is
perfectly fine to send 2 * IW in the second RTT of data transmission
if there was no loss in the first window of data.  That is just
traditional slow start.

And, if an implementation wanted to somehow decide to transmit less
than 2 * IW in the second RTT then that would also be fine with me.
(I.e., you are always free to be more conservative than the spec
allows.) 

These two bits follow directly from the spec and would seem
non-controversial to me.

Does that answer the question?

allman

---

From: Mark Allman <[email-masked]>
Date: Mon, 30 Nov 2015 11:02:31 -0500

> 	If you're seeing loss, it also means you might be causing

The dynamics are not that simple.

E.g., if the other folks had started faster they might actually be
out of the way when I start and not still sending.

E.g., if I am seeing loss then that is bad for me.  And, I don't
have incentive to do bad things to myself.  If the proposal would
cause pain for others and not me then perhaps I'd buy this point
more.  But, I don't see that it will.  So, in some sense my own self
interest also serves to protect others.

allman

---

From: Joe Touch <[email-masked]>
Date: Mon, 30 Nov 2015 10:06:57 -0800

> out of the way when I start and not still sending.

They might. They might not.

I'll wager that my "might" is a "probably", though, because the chance
that paced transmission is exactly the only thing dropped at a buffer is
vanishingly small, given AQM.

However, again this is a place where experiments would help, and the
status-quo is the only viable position until we have evidence that
cross-drops aren't the likely result.

Joe