Subject: Re: [hybi] Length encoding performance

From: "Shelby Moore" <[email-masked]>
Date: Tue, 24 Aug 2010 18:47:56 -0400

I was unsubscribed...but Roberto emailed the list and cc'd me.  I will be
unsubscribed again after this post, so don't email me please.

technical below...

>> The point is it doesn't matter if those other things dwarf in nominal
time, the bottleneck can set an upper limit on the # of cores that can
be
>> used effectively, which limits the throughput regardless of whether those
>> things dwarf CPU load cost.
>>
>> It shows me that you don't have experience in designing highly parallel
custom hardware.  So I am sorry, I can not respect your opinion on this
one.
>>
>
> Well, personal attacks attacks and vitriol aside,

http://www.ietf.org/mail-archive/web/hybi/current/msg03652.html

"Intermediaries are, roughly, my life.
I'm not worried about the decode speed."

You set the bar on your person, not me.

> all that matters are the
> results. Your use case will/can only occur when the transaction rate on
*single connections* increases faster than the CPUs scale.
> You should
> otherwise be able to balance on the IP:port of the sender (i.e
connection) in hardware in a fully parallel fashion.

Counter points:

1) assuming an intermediary, will only work if you can make more external
outgoing connections than you have cores, because otherwise the multi-core
signalling overhead can limit # of cores you can use.

2) your IO multiplexing overhead goes up

3) it doesn't necessary help you if have a lot of processing to do per
frame, then you still have problem of needing as much possible CPU
remaining from the frame header shunt to coordinate other cores to do that
processing, which results in limit in # of cores you can use.

Mathematically there is no way to push away the bottleneck on shunting
frames to processing.  You can argue until you are blue in face.

> Your theoretical argument seems unlikely to be the real bottleneck-- I
don't
> see single connections sending frames so quickly as a likely scenario. This
> is an opinion and not fact-- none of us can predict the future and we can't
> even observe the present especially well.

Thank you for being more balanced in your analysis.

>> > It is a part of it. It is probably like the 1% part. I'd be more
>> concerned
>> > about the 99% part.
>>
>>
>> That illustrates to me at least, that you are not experienced in the
specific use case that I am pointing out in this post.
>>
>
> Out of curiosity, why do you think that will be the dominant use case?

I am not saying it will.  I am saying if it does not cost us anything,
then why not do it.  The 15/63bit header is optimal.  Then no more
problems.

But there is a slight chance it could become dominant if there is a lot of
processing on the frames in an intermediary (if my logic is correct).  I
just raised it as a game theory thought experiement.

>> >> >> Do any of you build multi-core intermediaries?
>> >> >>
>> >> >
>> >> > Yes. For years now.
>> >>
>> >> You design custom ASICs??  You build multi-core from ground up with
engineering of every component used??
>> >>
>> >
>> > No.
>>
>>
>> I knew that, I just wanted you to admit it.
>>
>> I have known for a while what sort of systems you are building.
>>
>
> Thats impressive! :)

Hehe.  I know what you mean.  Okay not every detail.

Btw, I agree on using commodity components and software in most cases.  We
have a similar philosophy.  I just didn't want you to shoot my point
without understanding it deeply.  Thanks for taking time to understand it
more.  I challenged you so you would.  How else could I get you to? :D

Roberto I have the intuition you are very good at what you do.

========conflation topic==========

In private John said that my conflation point was wrong.  Here is how I
replied to him.

The bit is not the problem.

> this is not
> conflating layers.

Yes it is.  We should Skype, this typing is too slow.

I gave you the solution.

>  WebSocket exchanges messages with the application
> layer,
> not frames.  Surely the length of a message is an attribute of the message
> itself and belongs in the layer dealing with messages.

You are conflating the length of a frame and the length of the data in
frame(s).

Do you need for me to make a list of problems it will cause?  Would it be
worth my time?  Will you post it to the list if I do?
========================

John said he didn't care and I said then I don't care either.  If you guys
 do it the conflated way with CMLP (instead of the ReAssembleSize() I
suggested), then it will be just that much easier to beat WebSockets in
the market with something better.

---

From: John Tamplin <[email-masked]>
Date: Tue, 24 Aug 2010 19:31:30 -0400

> the market with something better.

What I said was that both points of view have been adequately expressed and
it was clear we weren't going to agree, so further discussion would be a
waste of our time.

-- 
John A. Tamplin
Software Engineer (GWT), Google

---

From: John Tamplin <[email-masked]>
Date: Tue, 24 Aug 2010 20:13:25 -0400

On Tue, Aug 24, 2010 at 7:57 PM, Shelby Moore <[email-masked]> wrote:

> John do you want me to show you how stupid CML is?
>
> So let's say I build a layer on top of WS that sends data. So it tells WS
> to set CML to size of that message.  Now I decide to use that layer on TCP
> or other protocol.  I can't.  It is forever tied to WS.
>

TCP is a stream protocol, it does not transfer messages but rather a stream
of bytes.  WebSocket transfers messages, not a stream of bytes.  Read the
requirements document describing what kind of protocol we are building if
you are in doubt.

Put your new protocol on top of UDP, for example, which also transfers
messages, and it works the same (of course you have other issues with
features of TCP you no longer have).  Or invent your own framing on top of
TCP which preserves message boundaries.  Note that HTTP, for example,
defines its own framing on top of TCP when dealing with pipelining /
connection keep-alive.

> How can you claim to be an engineer and you are so stupid.
>
> Do you want more examples of breakage caused by your stupid CML?
>

This post illustrates clearly why there is no point having further
discussion with you.  You can reply all you like and get the final word, I
won't feed the trolls any more.

---

From: "Shelby Moore" <[email-masked]>
Date: Tue, 24 Aug 2010 19:57:49 -0400

---

From: "Shelby Moore" <[email-masked]>
Date: Wed, 25 Aug 2010 04:23:20 -0400

Hey I did not intend that post to go to the list. The moderator approved
it. I was unsubscribed. You cc'ed numerous people, so I clicked Reply All,
then I went to sleep. I did not realize that it went to the list too. I
clicked the url this morning to cancel the post from going to the list,
but it said I was too late, the moderator had already approved.

John can you not read?

http://www.ietf.org/mail-archive/web/hybi/current/msg03677.html

Shelby Moore wrote:
> I was unsubscribed...but Roberto emailed the list and cc'd me.
> I will be unsubscribed again after this post, so don't email
> me please.

Why do you keep dragging me back here, when I am trying to leave?

I was so exhausted last night, because of 3+ days of this nonsense with
you. The list is tired and I am tired too. You reply to every email I make
and often with some nonsense illogic. And you even have the audacity to
use words like "absurd", when you are the one being "absurd". You are the
problem here, not me. You have had at least 5 logic errors that you keep
repeating over and over again, which cause you to go on endless goose
chases and increase the email load by an order-of-magnitude. I offered to
Skype with you, but you refused. How can you claim to this list that you
are trying to be efficient? As I said in past emails, you are
closed-minded. Before I said the list was closed-minded, because I didn't
want to call you out by name, but now I am sick and tired of you ruining
my contribution to this list. You are like a troll, but you think you are
doing good. And I am sick of the list people blaming me, for trying to
correct all your mistakes.

> requirements document describing what kind of protocol we are building if

That has nothing to do with what we are discussing. That you can't see
that, is indicative of the problem you have with understanding concepts.
It shouldn't be allowed for a person with insufficient intelligience
quotient to dominate a working group. You should be more open-minded to
learn from others who are smarter than you. I certainly relish the
opportunity to listen to other very intelligient people. But I really hate
when stupid people try to infringe on my free speech rights, just because
they can not understanding concepts (or understand them at the same speed
that I can).

> features of TCP you no longer have).

You don't seem to understand that framing is an optional feature
(enhancement) of the transport layer, i.e. sending data over a channel.

If I want to send some data, I can send it over TCP or UDP or what ever.

The application (higher layer) should have the least possible knowledge of
the lower layer.

Ideally the application should say "sendData()" and "receiveDatd()" and
that is all.

But in our case, we want to add an intermediate layer called framing. And
we want to give the application layer the option to keep data contiguious.
 So we offer the receiving end of the application layer an optional
standard API call, ReAssembleSize().  The receiving end can call that
after it received the data size in its first frame, and then the framing
layer can realloc its buffer (while it is still small) so it is prepared
to store all the remaining incoming frames in contiguious memory.  And
application that wants to optimally design for ReAssembleSize(), can send
an initial frame (sendData()) that is very small and only contains the
data size.

Now if the application layer is run on top some other protocol, e.g. TCP,
UDP, whatever, then the ReAssembleSize() will be ignored.

Now to implement our protocol on TCP or UDP or whatever, then we only need
to write stubs for those 3 API calls, sendData(), receiveData(), and
ReAssembleSize().

Whereas, if we do this the conflated way, with a CMLP bit carried by every
frame header in the universe, then we are forcing (instead of optional)
the application layer to declare its data sizes to the transport layer. To
be compatible with other types of protocols, the application will still
need to put the data size in the first frame of its data.  CMLP at best
only causes the duplication of effort. But actually CMLP has many other
types of breakage, some of which Thomas pointed out, because CMLP is
ill-defined conceptually.

If you want me to enumerate many different breakages points with the CMLP
conflation, I can.  But I really think the above should be sufficient
already.

>  Or invent your own framing on top of

---

From: "Shelby Moore" <[email-masked]>
Date: Wed, 25 Aug 2010 12:25:32 -0400

Quick technical improvement...

I am back to unsubscribed again after this.  Do not copy me on any emails
to list please.

[snip]
> an initial frame (sendData()) that is very small and only contains the

No ReAssembleSize() function is is needed in the standard API.

Simply have receiveData() input a buffer, offset, and a maximum size in
bytes. Or in C simply a pointer and maximum size.

The application can implement the logic I had presented above.  It reads
the data size, then it reallocates its buffer, then uses this buffer in
subsequent receiveData() calls.

This is preferred so that the reassembly will work even with TCP or UDP or
whatever.  And notice that the framing layer under receiveData() will
still be doing the reassembly of the fragmented frames (or TCP packets or
UDP messages or whatever), but no CMLP was needed.

[snip]
> conflation, I can.  But I really think the above should be sufficient
[snip]

Doing it the CMPL way, will bind the application to WebSockets frames and
this can grow tentacles throughout the application like spaghetti.

I think it is really important to get back to designing software properly,
so that maximum interoperability can be obtained. By that I mean in the
above case, maximum cross-protocol composition freedom.

---

From: "Shelby Moore" <[email-masked]>
Date: Fri, 27 Aug 2010 13:45:57 -0400

This WG is somewhat conflated right now:

http://www.ietf.org/mail-archive/web/hybi/current/msg03776.html
(re-read entire message please, especially at bottom)

http://www.ietf.org/mail-archive/web/hybi/current/msg03787.html
http://www.ietf.org/mail-archive/web/hybi/current/msg03790.html
http://www.ietf.org/mail-archive/web/hybi/current/msg03791.html

Let me see if I can help bring raise mutual understanding.

The reason you guys are having such a difficult time coming to mutual
understanding, is because you have the frame and message layers to some
degree conflated in your minds.

This may be semantics only.  Please note that the message layer will
always need to have its own size/content-length field.  In essense, the
message layer has its own message-frame header.

Please try to separate that message-frame header from the
fragmentable-frame-header.

They are two different things for two different orthogonal purposes.

I already showed an optimization (see my link above) where the
fragmentable-frame-header can be merged with the message-frame-header for
small messages WITHOUT conflating the two layers.

---

From: "Shelby Moore" <[email-masked]>
Date: Fri, 27 Aug 2010 13:55:27 -0400

> message layer has its own message-frame header.

To be pedantic/thorough with myself...

The above is true, but note that for streaming the size/content-length
could be omitted for the message.

Tangentially is another reason that the fragmentation-frame-header is
orthogonal to the message-frame-header, because fragmentation still needs
sizes.

---

From: "Shelby Moore" <[email-masked]>
Date: Fri, 27 Aug 2010 14:08:26 -0400

Some diagrams to help illustrate:

Message:

mhdr 0123456789

Frames:

fhdr mhdr 012
fhdr 3456
fhdr 789

My suggested optimization for small frames:

fhdr 0123456789