Re: [tsvwg] Update to Position Statement on ECT(1)

[Gorry Fairhurst <[e-mail]>]

Please relate ECN tunnel discussions to the relevant work items. Is this 
related to draft-ietf-tsvwg-rfc6040update-shim or the 
draft-ietf-tsvwg-ecn-encap-guidelines or to draft-ietf-intarea-tunnels?

Gorry


On 28/05/2020 11:54, Sebastian Moeller wrote:
> Hi Jake,
>
> thanks for the information. Indeed a case of the perfect being an enemy of the good.
>  From rfc3168:
> "The presence of a copy of the ECN field in the inner header of an IP
>     tunnel mode packet provides an opportunity for detection of
>     unauthorized modifications to the ECN field in the outer header."
>
> This in a nutshell was an original sin, of being clever when KISS could have carried the day. Now, at the time that was probably a reasonable choice, but I wonder whether that design decision is not worth revisiting?
>
> I would humbly ask, whether it is possible to get rid of that requirement and get back to the simple strict copy regime and leave the tampering detection to the endpoints? As the current L4S tunneling discussion indicates, that intent of being cautious back then now is a burden.
>
> I note that according to https://tools.ietf.org/html/rfc4301 tunnel entry already does the simple copy inner to outer, it is really ony the decapsulation side that needs special care...
>
>
>> On May 28, 2020, at 10:21, Holland, Jake <[e-mail]> wrote:
>>
>> Hi Sebastian,
>>
>> On 5/28/20, 12:57 AM, "Sebastian Moeller" <[e-mail]> wrote:
>>> I have a question regarding tunneling, that IMHO is left unanswered
>>> so far. Why is the rule for ECN and tunneling not simply: copy the
>>> inner to outer on encapsulation and the outer to inner on
>>> decapsulation. Period.
>> Please see RFC 6040.  Section 7 gives the design principles,
>> and Section 4 describes the current standard rules.  The Intro
>> also reviews some of the other considerations that went into it.
> 	[SM] Thanks.
>
>
>> Of course there are some important considerations toward ensuring
>> that CE is not erased on the inner or outer packet, regardless
>> of whatever network condition led to that occurring, if it
>> occurs, which seemed to get a bit more attention than the ECT(1)
>> overwriting.  But as far as I can tell, the overall reasoning is
>> more or less laid out there.
> 	[SM] So what puzzles me is that these rules all give tunneled traffic additional ECN sanity checking that non-encapsulated packets traveling over the same path and hence the same AQMs do not enjoy?
>
>
>> If you're looking for a deeper "why", I guess there's also the
>> comments in the writeup and final reviews:
>> https://datatracker.ietf.org/doc/rfc6040/writeup/
>> https://datatracker.ietf.org/doc/rfc6040/ballot/
> 	[SM] Thanks a lot, short but helpful.
>
>> Probably also there's some discussion in the list archives around
>> that time if you care to search for it.
>>
>> But it seems the consensus at the time landed on a copy of outer
>> to inner for ECT(1) overwriting ECT(0) on decapsulation, but not
>> for ECT(0) overwriting ECT(1) (which I think is the only change I'd
>> want in order to enable the 2-signal proposal, to the extent it
>> seems possibly worth doing).  To me it's an understandable decision,
>> especially considering RFC 6660, which seems essentially "SCE but
>> only applicable inside DSCP", and would prefer not to lose that pre-
>> congestion signal if something weird happens while it's tunneled.
> 	[SM] But again that same pre-congestion signal would be lost for non tunneled packets encountering the same path, no? The only additional step would e the tunnel decap, but we need that to work reliable anyway, as otherwise nothing is guaranteed anymore?
>
>> As an aside, I think it's a fair claim that Bob made, that he's the
>> one who has been trying to fit this jigsaw together for over a decade.
> 	[SM] Sure, that is quite some work and time invested in all of this.
>
>> Not to endorse his conclusion that the best choice today is to do
>> something that seems to break regular ECN, but between his authorship
>> of those specs and his long list of other publications on the topic,
>> it's a good bet that Bob has given the whole space a larger quantity
>> of thought than anyone else alive, which is certainly worth something.
> 	[SM] Sure, the sign that I propose simplistic solutions, is probably a cause of Kruger-Dunning and nit fully appreciation the intricacies of the problem space and what kind of unfortunate behavior already exists in the wild and needs to be dealt with.
>
> 	That said, "working best" with the current breed of tunnels is not the only sane criterion, especially if we are talking about longer term evolution of the network.
>
> Best Regards & Thanks
> 	Sebastian
>
>
>
>> Best regards,
>> Jake
>>
>>
-- 
G. Fairhurst, School of Engineering