MIME-Version: 1.0
In-Reply-To: <4FC880A7.9070007@250bpm.com>
References: <001a01cd3e69$4a221c10$de665430$@noemax.com>
 <4FC732DC.3000308@250bpm.com> <000e01cd3f1c$af15ad40$0d4107c0$@noemax.com>
 <4FC880A7.9070007@250bpm.com>
From: Takeshi Yoshino <tyoshino@google.com>
Date: Fri, 1 Jun 2012 21:33:11 +0900
Message-ID: <CAH9hSJaWrUX6gFNLT4xkXLYKHSUH5+Y7AvqN9cD_CwekvsNu3A@mail.gmail.com>
To: Martin Sustrik <sustrik@250bpm.com>
Content-Type: multipart/alternative; boundary=14dae9340d8369847604c1686489
Cc: hybi@ietf.org
Subject: Re: [hybi] Flow control quota
Precedence: list

--14dae9340d8369847604c1686489
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Jun 1, 2012 at 5:43 PM, Martin Sustrik <sustrik@250bpm.com> wrote:

> That seems to suggest there's some kind of mis-layering happening here.
> Frames are used for flow control. Does it make sense to use them for
> compression as well? Shouldn't the compression rather happen on top of
> mutliplexing layer?
>
> The situation is similar to compressing the payload in TCP packets. It is
> feasible, but in corner cases it can clash with MTU limits, cause
> re-fragmentation etc. The clean solution would be to layer compression on
> top of TCP layer.


Mux want to control fragmentation while per-frame compression locks down
fragmentation. Yes, it's not healthy to use of per-frame compression before
mux.

Shall we discourage this layering (preframe-compress then mux)?

--14dae9340d8369847604c1686489
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Fri, Jun 1, 2012 at 5:43 PM, Martin Sustrik <=
span dir=3D"ltr">&lt;<a href=3D"mailto:sustrik@250bpm.com" target=3D"_blank=
">sustrik@250bpm.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">


<div>That seems to suggest there&#39;s some kind of mis-layering happening =
here. Frames are used for flow control. Does it make sense to use them for =
compression as well? Shouldn&#39;t the compression rather happen on top of =
mutliplexing layer?</div>



<br>
The situation is similar to compressing the payload in TCP packets. It is f=
easible, but in corner cases it can clash with MTU limits, cause re-fragmen=
tation etc. The clean solution would be to layer compression on top of TCP =
layer.</blockquote>


<div><br></div><div>Mux want to control fragmentation while per-frame compr=
ession locks down fragmentation. Yes, it&#39;s not healthy to use of per-fr=
ame compression=A0before mux.</div><div><br></div><div>Shall we discourage =
this layering (preframe-compress then mux)?</div>

</div>
<div class=3D"gmail_quote"><div>=A0</div></div>

--14dae9340d8369847604c1686489--