Re: [Spud] updated draft PLUS charter, rev. 1 June

[Brian Trammell <[e-mail]>]

hi Szilveszter,

> On 14 Jun 2016, at 16:50, Szilveszter Nadas <[e-mail]> wrote:
> 
> Hi,
> 
> I was probably mis-using the term happy eyeballs. I meant that whatever mechanism selecting how SPUD is used may also consider and try the separate protocol number option before falling back to e.g. UDP.
> 
> I agree that separate protocol number is not deployable in itself. Whether it is at all practical now and in the foreseeable future, I am not sure, it might be worth a consideration. Some data on this (similarly that for UDP and IPv6 extension header) might help.
> 
> Summarizing, I see it as something to consider during the design, and definitely not the mainstream solution in the short run.

I'd tend to say that designing PLUS such that it can never run over a protocol number than 17 would be a mistake, yes. But in the short term it's the only thing I see that has a chance to deploy.

Cheers,

Brian

> 
> Cheers,
> Sz.
> 
>> -----Original Message-----
>> From: Brian Trammell [mailto:[e-mail]]
>> Sent: Tuesday, June 14, 2016 16:44
>> To: Szilveszter Nadas
>> Cc: Joe Touch; spud
>> Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June
>> 
>> 
>>> On 13 Jun 2016, at 17:21, Szilveszter Nadas
>> <[e-mail]> wrote:
>>> 
>>> Hi,
>>> 
>>> 
>>>> It would be useful if whatever comes out of an eventual PLUS working
>>>> group could be implemented either over UDP or IPv6 EH, since the lack
>>>> of access to EH problem is simply a matter of changing APIs. But I'm
>>>> not convinced that's a hard requirement.
>>> 
>>> Is a separate protocol number for SPUD also an option?
>> 
>> 
>> It doesn't seem to me that using an alternate protocol number for PLUS (or
>> QUIC) actually meets the requirements of either effort. One is the ability to run
>> on unmodified kernels, which is a somewhat bigger deal for QUIC than for
>> PLUS. Another is middlebox transparency, where experience with SCTP has not
>> been great. True, we don't have a lot of data here; on our list of path
>> transparency measurements to run at ETH is "UDP/TCP with mangled protocol
>> number"; I suspect that NAPT breaks in the overwhelming majority of cases
>> here.
>> 
>> In a world in which every kernel is relatively quickly updatable, NAPT is
>> irrelevant, and other middlebox brokenness negligent, alternate protocol
>> numbers are an option. We are somewhat closer to that world, I think, than
>> we were a decade ago. But I don't think we live in it yet.
>> 
>>> Then the happy eyeball mechanism used could also consider that.
>> 
>> I'm not sure how the protocol number is relevant to happy eyeballs... can you
>> expand on this a bit?
>> 
>> Cheers,
>> 
>> Brian
>> 
>>> Cheers,
>>> Sz.
> 
> _______________________________________________
> Spud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud