Subject: Re: [tcpm] Initial Window units.

From: Bob Briscoe <[email-masked]>
Date: Mon, 2 Apr 2012 16:24:23 +0100

Anantha,

I agree bytes are a more appropriate unit to specify the likely 
constraint than packets. Ie. IW=14600B.

No-one will ever guess we made up that number; it looks really quite 
scientific.

Even tho the IW comes after a 3WHS, when the PMTU will have been 
discovered, I still think bytes are a more appropriate unit. Anyway 
with TCP Fast Open (TFO) the 3WHS could have occurred on a path with 
a different PMTU.

Bob

At 12:02 30/03/2012, Anantha Ramaiah (ananth) wrote:
>Content-Class: urn:content-classes:message
>Content-Type: multipart/alternative;
>         boundary="----_=_NextPart_001_01CD0E64.9F29AC5F"
>
>Hi,
>     I had brought this question to Jerry offline.  TCP communicates 
> receive window in bytes (sliding window is based on bytes) So, it 
> would be useful to have the initial window as bytes. Oh, yeah the 
> "bytes versus packet" argument again J Is that an issue? Maybe not 
> but with larger IW's it probably would..
>
>     Consider the case of IW=10, and the stack doesn't do PMTU, then 
> we end up putting more segments on the network, in case of 
> fragmentation in the path). Even with PMTU,  PMTU convergence takes 
> time and it can complicate things.  Would it be useful to list this 
> relationship and recommend a lesser IW if the MSS > 1500?  In such 
> cases the # of bytes would be useful metric.  Another point in 
> favor of this thought would be that Jerry mentioned that anything 
> above than IW=10 wasn't that useful for many web objects.. so 
> having  IW in bytes versus packets seems useful.  Basically I am 
> nervous about the high watermark (cap) of IW in packets, would 
> think it is safer if bytes were used instead.
>
>-Anantha
>_______________________________________________
>tcpm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tcpm

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Mon, 2 Apr 2012 18:32:22 +0200

Bob, Anantha,

draft-ietf-tcpm-initcwnd-03 recommends the following threshold (in bytes):

min (10*MSS, max (2*MSS, 14600)) 
 
Do you suggest to change this? If so, how?

Michael

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Bob Briscoe
> Sent: Monday, April 02, 2012 5:24 PM
> To: Anantha Ramaiah (ananth)
> Cc: [email-masked]
> Subject: Re: [tcpm] Initial Window units.
> 
> Anantha,
> 
> I agree bytes are a more appropriate unit to specify the 
> likely constraint than packets. Ie. IW=14600B.
> 
> No-one will ever guess we made up that number; it looks 
> really quite scientific.
> 
> Even tho the IW comes after a 3WHS, when the PMTU will have 
> been discovered, I still think bytes are a more appropriate 
> unit. Anyway with TCP Fast Open (TFO) the 3WHS could have 
> occurred on a path with a different PMTU.
> 
> 
> 
> Bob
> 
> >"bytes versus packet" argument again J Is that an issue? 
> Maybe not  but 
> >with larger IW's it probably would..
> >
> >     Consider the case of IW=10, and the stack doesn't do 
> PMTU, then we 
> > end up putting more segments on the network, in case of 
> fragmentation 
> > in the path). Even with PMTU,  PMTU convergence takes time 
> and it can 
> > complicate things.  Would it be useful to list this 
> relationship and 
> > recommend a lesser IW if the MSS > 1500?  In such cases the 
> # of bytes 
> > would be useful metric.  Another point in favor of this 
> thought would 
> > be that Jerry mentioned that anything above than IW=10 wasn't that 
> > useful for many web objects.. so having  IW in bytes versus packets 
> > seems useful.  Basically I am nervous about the high 
> watermark (cap) 
> > of IW in packets, would think it is safer if bytes were 
> used instead.
> >
> >-Anantha

---

From: Andre Oppermann <[email-masked]>
Date: Mon, 02 Apr 2012 18:58:35 +0200

On 02.04.2012 17:24, Bob Briscoe wrote:
> Anantha,
>
> I agree bytes are a more appropriate unit to specify the likely constraint than packets. Ie. IW=14600B.
>
> No-one will ever guess we made up that number; it looks really quite scientific.
>
> Even tho the IW comes after a 3WHS, when the PMTU will have been discovered, I still think bytes are
> a more appropriate unit. Anyway with TCP Fast Open (TFO) the 3WHS could have occurred on a path with
> a different PMTU.

The 3WHS doesn't truly discover the PMTU.  Only the first full sized
packet would do that.  In reality most devices that are in front of
a link that reduces the MTU employ MSS fixup's for transiting SYN's.
Which in turn breaks TCP-AO if it is deployed beyond link local.

-- 
Andre

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 2 Apr 2012 18:16:13 +0100

Michael,

That's good.

Sorry - we were reacting to the abbreviation 'IW10' rather than 
checking the draft. Slap wrists. Won't do it again.

Bob

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Mon, 2 Apr 2012 11:27:02 -0700

Michael,
    The value looks fine. I guess more clarification can be added.. I
see that the section titled "TCP motivation" is similar in wordings to
RFC 3390 (same section) However in RFC 3390, it is more clearer, it
doesn't only give the formula but also says something  like :-

"Equivalently, the upper bound for the initial window size is based on
   the MSS, as follows:

       If (MSS <= 1095 bytes)
           then win <= 4 * MSS;
       If (1095 bytes < MSS < 2190 bytes)
           then win <= 4380;
       If (2190 bytes <= MSS)
           then win <= 2 * MSS;"

something of this sort would be useful, here as well. 

(You could use the MTU plateau values defined in RFC 1191, but that may
be outdated)

-Anantha

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Bob Briscoe
> Sent: Monday, April 02, 2012 10:16 AM
> To: Scharf, Michael (Michael)
> Cc: [email-masked]; Anantha Ramaiah (ananth)