Re: Framing and control-frame continuations

As opposed to endlessly debating the matter.. any chance we can see some
real metrics on all this? Specifically, it would be very informative to see
a breakdown of exactly what impact small, large and variable-sized frames
have on latency and throughput on both ends of the connection. It would
also be helpful to see what kind of processing overhead could be expected
if we allow for large control frames... for example, if we do end up going
with delta compression for headers in control frames, what would be the
impact of allowing that frames to scale up to 32-bit lengths?

(I must say, however, that I have not seen anything that would ever suggest
that we need or want control frames to scale up to 32-bit lengths. To
paraphrase a comment Mark made previously, I don't want to live in a word
with that much protocol and processing overhead.)

- James



On Wed, Feb 6, 2013 at 12:36 PM, Roberto Peon <grmocg@gmail.com> wrote:

> Why would I like it if the new and supposedly better stuff is worse with
> naive implementations, given that a requirement for a smaller frame size
> would likely do a good job of preventing the sucking in the first place? :)
>
> This problem isn't theoretical, by the way-- we've seen it in the wild. It
> is something which, unless one stops to think, one won't realize why it
> would cause a problem, but that doesn't stop it from doing so.
>
> -=R
>
>
> On Wed, Feb 6, 2013 at 12:21 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote:
>
>> Content-Type: text/plain; charset=ISO-8859-1
>> --------
>> In message <CAP+FsNdvAwThsTfp1FATETABT=fVP0pPOYkei2hWQh8Ys=
>> RiWw@mail.gmail.com>
>> , Roberto Peon writes:
>>
>> >Unfortunately, by the time the reciever sees the frame the damage is
>> likely
>> >already done.  As a result of sending a large frame, the session may back
>> >up and prevent other data from being sent on other streams either
>> >successfully, or without undue delay.
>>
>> And who gets a problem ?
>>
>> If a browser does this, its user exeperience suckage.
>>
>> If a webservers does this, the webserver will appear sucky to people
>> visiting it.
>>
>> What's not to like about that ?
>>
>> --
>> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
>> phk@FreeBSD.ORG         | TCP/IP since RFC 956
>> FreeBSD committer       | BSD since 4.3-tahoe
>> Never attribute to malice what can adequately be explained by
>> incompetence.
>>
>
>