[tsvwg] draft-fairhurst-tsvwg-transport-encrypt signaling (was: Re: [tcpm] Better QoS for TCP ACK question)

[Toerless Eckert <[e-mail]>]

On Mon, Apr 16, 2018 at 05:53:27PM +0100, Gorry Fairhurst wrote:
> RFC 3449 from 2002 describes this in section 5.4.2 on ACKs-first Scheduling.
> [...]
> In those ancient days, I suspect most systems did do the "ACK-First"
> scheduling based only on estimating the size of the "ACK".
> 
> So I'm not saying TCP DPI-based could do special stuff when it sees data in
> the packet and try to smartly avoid reordering any segments, and that
> timestamps, SACK, and various other things could be taken into account.
> Whether this would be a great idea is another story.

Well, i ultimately asked also re. relationship to subject draft.

I would start asking the question whether this would be a great idea
a bit different:

Lets assume we built the transport layer optimized to provide best possible
treatment from the network. Could the argument be made that such best
possible treatment should include the ability to differentially treat
different packet types of the transport stream ?

To me, the results achieved with ACK-first seem to indicate that it
could be a good idea to have such differential treatment, but i fear
it has not been well researched to give good quantitative recommendations
how exactly it should be treated differently, nor any good rule of
thumbs how much gain this gives.

IMHO, DPI into transport headers is always a second-best solution
to providing explicit marking/signaling to the network, but we have
to take what we get.

More generically wrt. your draft: Everything done with TCP headers
is ultimately a workaround given how those TCP headers where never
designed to be seen by the network. So it would be really nice if
instead of only arguing that they ultimately turned out to be highly
useful to examine (if not necessary, as i think, for network operations),
i for once would rather prefer if we would start getting to a design
where we would explicitly specify informationt hat the network MUST
see and/or that it SHOULD react to in support of the transport layer.

I don't think we should have this information effectively in per-transport
protocol headers. Thats just a silly design. Just least to promoting
the oldest, most widely adopted transport protocols. Heck, all the good
stuff from your draft, let's say i would want for SCTP. Sure, technically
no problem, but market wise not going to happen.

So now i am only lost in figuring out if/where/how one would even start
trying to specify the exact type of information the network should
have in a transport protocol independent fashion. Which WG would that
be anyhow... ICCRG ? PANRG ? Anything without RG behind it even in the
remotest trying to figure out a clean architecture ? Or is IETF just
too afrad to run into privacy or end-to-end katechism issues again ?

Cheers
    toerless