[go: up one dir, main page]

|
|
Subscribe / Log in / New account

QUIC as a solution to protocol ossification

QUIC as a solution to protocol ossification

Posted Feb 8, 2018 18:34 UTC (Thu) by Wol (subscriber, #4433)
In reply to: QUIC as a solution to protocol ossification by karkhaz
Parent article: QUIC as a solution to protocol ossification

And it seems quite clear to me that nim-nim THINKS that the owner of the middle box should control the middle box. Except it's also quite clear that the person who *really* controls the middle box is the box vendor, who over-rides the owner's changes.

And the hilarious thing is that the middle box's job is to transmit the customer's data - which it is clearly and blatantly failing to do!

What Google wants, and (maybe slightly altered) what everyone else wants, is for whatever leaves my *source* network should get to my *destination* network INTACT and UNALTERED. What f'ing right does the TRANSPORT network have to interfere and alter my data or throw it away? Because that's what nim-nim is advocating - let the transport network (and indeed, not even that, let the vendors of the equipment running the transport network) dictate what traffic is allowed is allowed to pass over the transport network. NOT good if I'm paying for my data to be transported ...

Cheers,
Wol


to post comments


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds