Subject: [tcpm] laminar tcp

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 13 Mar 2012 19:58:48 +0000

Hi Matt,

I'm currently reading your draft, and found a few nits, and two comments/questions:

1.1: s/simpler simpler/simpler/
1.2:    s/to to/to/
3.2: s/WIth standard TCP, any application stall reducs/With ... reduces/
4: s/MAX_WINOW/MAX_WIN/

Ad Section 3.6:

I think you are aiming at MPTCP here, correct?
I think the text, as written, is really only relevant when you know (automagically) that the congestion control triggering event was somewhere along a common path of these separate TCP flows...  I.e. same sending interface, same destination, same source or destination network. It may be worthwhile to explicitly spell out the intent here (ie. RFC2140 has host-pair only).

Ad section 3.7:
Another comment: The text of the draft appears to operate on packet units, rather than byte units (which may complicate things, in particular if the flow consists of non-uniform sized packets). Then again, the sample code appears to work on byte units. Perhaps the text can be checked again that it talks about byte (or packet) oriented implementations for consistency. For the non-SACK example,  will laminar deviate much if SMSS is assumed to have left the network on a DUP ACK, even if only a smaller packet triggered the ACK?

Best regards,

Richard Scheffenegger

---

From: Michael Welzl <[email-masked]>
Date: Wed, 14 Mar 2012 11:12:52 +0100

Hi,

I also read Laminar TCP now, and I applaud! This is great stuff!

As for the document itself, while this certainly forms a good basis for 
discussion, if I imagine that being an RFC, I would say that it's too 
messy, in several ways:

1)
I think that most of what this document does is just to provide guidance 
to application designers, i.e. it could be an informational description 
of how a TCP could be implemented in an easier and more modern fashion. 
There doesn't seem to bee much in it, now, that is (as the abstract 
says) "technically in violation of all existing TCP standards"?   I 
mean, does counting packets instead of bytes make Linux TCP in violation 
of the standards? I guess not... similarly, would I violate standards if 
I call ssthresh "xythresh" in my implementation? I guess not... so I 
think that only behavioral changes really affect the rules laid out by 
the other TCP RFCs.

That would, then, only concern the behavior when TCP is 
application-limited, I think, and that would perhaps only update RFC 
2861  :-)

Of course, if that would really lead to an RFC updating not much more 
than RFC 2861 and one or two others, one would have to make pretty damn 
sure that the behavior of Laminar REALLY doesn't diverge from the 
standards in any other way.

2)
You seem to have made a rather arbitrary selection of algorithms that 
you survey in section 3 - e.g., why mention F-RTO and not Eifel? Anyway 
both really don't seem to have much to do with Laminar...  and which RFC 
defines "Undo"? I guess what you mean is the Eifel Response algorithm.

3)
I find your mention of aggressiveness, Tragedy of the Commons etc. out 
of place. It just strikes me as unrelated. I also think it's weird to 
mention the de-obfuscation of code achieved with Laminar as a possible 
security concern   :-)

Again, all of these comments concern only the document writing style and 
structure, not the technical idea, which I think is just beautiful.

Cheers,
Michael

---

From: Matt Mathis <[email-masked]>
Date: Fri, 16 Mar 2012 15:23:20 -0700

Thanks for the comments!  Nits have been fixed.

Yea, I was sloppy about units.  I will make it (fractional) bytes everywhere.

> I think the text, as written, is really only relevant when you know
> (automagically) that the congestion control triggering event was somewhere
> along a common path of these separate TCP flows…  I.e. same sending
> interface, same destination, same source or destination network. It may be
> worthwhile to explicitly spell out the intent here (ie. RFC2140 has
> host-pair only).

I was actually only thinking about the narrower host pair case.  For
MPTCP you do need to keep CCwin and total_pipe per flow.  Since
Laminar decouples the CCwin adjustment from other complexity, it
becomes easier for some higher level function to dynamically allocate
the window adjustment across flows other than where it was detected.
In particular it is reasonable to update the CCwin of another flow,
without worrying about what state it is in.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

---

From: Matt Mathis <[email-masked]>
Date: Fri, 16 Mar 2012 15:57:36 -0700

Thanks!   I just realized that my earlier reply wasn't to the entire list.

(Revised)

My big question for Paris will be how to frame this work relative to
TCPM.  I was actually deliberate about writing this draft for the
wrong audience (it is addressed to the WG itself sort of in the form
of an independent submission.  TCPM docs are normally addressed to TCP
implementers.)

It is also very spotty about which algorithms it chose to update.
This will improve as the draft evolves.

I used "undo" in a generic sense.

Thanks,
--MM--

On Wed, Mar 14, 2012 at 3:12 AM, Michael Welzl <[email-masked]> wrote:
> discussion, if I imagine that being an RFC, I would say that it's too messy,
> in several ways:
>
>
> 1)
> I think that most of what this document does is just to provide guidance to
> application designers, i.e. it could be an informational description of how
> a TCP could be implemented in an easier and more modern fashion. There
> doesn't seem to bee much in it, now, that is (as the abstract says)
> "technically in violation of all existing TCP standards"?   I mean, does
> counting packets instead of bytes make Linux TCP in violation of the
> standards? I guess not... similarly, would I violate standards if I call
> ssthresh "xythresh" in my implementation? I guess not... so I think that
> only behavioral changes really affect the rules laid out by the other TCP
> RFCs.
>
> That would, then, only concern the behavior when TCP is application-limited,
> I think, and that would perhaps only update RFC 2861  :-)
>
> Of course, if that would really lead to an RFC updating not much more than
> RFC 2861 and one or two others, one would have to make pretty damn sure that
> the behavior of Laminar REALLY doesn't diverge from the standards in any
> other way.
>
>
> 2)
> You seem to have made a rather arbitrary selection of algorithms that you
> survey in section 3 - e.g., why mention F-RTO and not Eifel? Anyway both
> really don't seem to have much to do with Laminar...  and which RFC defines
> "Undo"? I guess what you mean is the Eifel Response algorithm.
>
>
> 3)
> I find your mention of aggressiveness, Tragedy of the Commons etc. out of
> place. It just strikes me as unrelated. I also think it's weird to mention
> the de-obfuscation of code achieved with Laminar as a possible security
> concern   :-)
>
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Yuchung Cheng <[email-masked]>
Date: Wed, 28 Mar 2012 19:17:29 -0700

As a TCP developer, I would like to give a big +1 because Linux
suffers the exact
 problem Laminar is trying to address.

Some questions:
1) are cwnd and ssthresh obsolete in Laminar? but IW is mentioned in the draft.

2) Linux performs burst suppression by pulling cwnd to pipe+max_burst
   AFAIU, Laminar replaces that with (implicit) slow-start. But the
   pseudo code appears to moderate burst in transmission scheduling
     // cue the (re)transmission machinery
     sndBank += sndcnt
     limit = maxBank()
     if sndBank > limit:
        sndBank = limit

   What does maxBank() do?

3) does in_recovery() and new_recovery() include timeout recovery? it
seems so to
   me (but it suggests a loss window = 2 which I would love to change to).

Thanks!

---

From: Matt Mathis <[email-masked]>
Date: Thu, 29 Mar 2012 01:03:18 -0700

>  problem Laminar is trying to address.
Thanks!  The standards themselves are problematic.  I would expect the
problems to be present in all TCP implementations.

> 1) are cwnd and ssthresh obsolete in Laminar? but IW is mentioned in the draft.
You are correct.  IW is misnamed, it should be Initial Burst or
something like that.

>     // cue the (re)transmission machinery
sndBank is needed to support TSO, and normally it would never be
larger than the TSO chunk size.   However the receiver window check
and NIC back pressure (e.g. Ethernet pause frames) both happen deep
inside of the TCP output code, and could cause sndBank to become
arbitrarily large.  After such an output stall, maxBank() controls how
much TCP can catch up by by using Laminar's transmission scheduling
algorithm vs sending a line rate burst.   If sndBank gets pulled down
it deflates total_pipe and the transmission scheduler will have to
make up the difference on future ACKs.

If there is no TSO, sndBank is not needed and output stalls could just
cause total_pipe to deflate.

BTW  There is a simple thought experiment to determine if total_pipe
is implemented correctly: if you imagine disabling the the CCwin based
sndcnt adjustments (e.g. constant window as long as the network
remains lossless), total_pipe will not be affected by either irregular
delayed ACKs (DeliveredData not uniform) or irregular TSOs (SndBank
not uniform) or any combination.

>   me (but it suggests a loss window = 2 which I would love to change to)
Yea, I was being wishful.  That should probably be a separate change.

My presentation in TCPM will be Friday AM.

Thanks,
--MM--