Re: Large Frame Proposal

In message <CANV5PPWfkt8_ZYHPCDFSDJ1qqsdp0Gkwu54JLYDJehmN8cObXg@mail.gmail.com>
, Nicholas Hurley writes:

>Let's assume some theoretical world where I end up
>supporting large frames (VERY theoretical, at this point). If I don't know
>that I'm receiving video, I don't want to advertise large frame support,

You don't need to advertise large frame support: You can do it per
stream with the field in WINDOWS_UPDATE once you discover that this
particular stream carries video.

>because when used poorly, that will kill multiplexing and priority, 

"Deliver tools, not policies"

IP, TCP, TELNET and FTP could all be used poorly, but IETF members
were smart enough not to limit functionality just because some people
might not use them optimally.

Trying to circumscribe what people can do with your protocol (ie:
embedding politics in the protocol) has never been a success for
anybody:  People will just go and define a new protocol then (Guess
why we have started talking about HTTP/3 already?)

-- 
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.

Received on Monday, 7 July 2014 20:36:00 UTC