Re: [tsvwg] Status of ECN encapsulation drafts (i.e., stuck)

[Joseph Touch <[e-mail]>]

Hi, Bob,

> On Mar 16, 2020, at 1:47 AM, Bob Briscoe <[e-mail]> wrote:
> 
> Joe,
> 
> On 15/03/2020 19:53, Joseph Touch wrote:
>> 
>>> [BB] I should add that PLPMTUD and clamping the max packet size complement each other. 
>> 
>> Except that PLPMTUD works over authenticated or encrypted transport headers and clamping does not.
>> 
>> Clamping could be useful if the information were in an IP header that could be ignored by routers that don’t care (e.g, by not slowing them down, as IP options do).
> 
> [BB] I think I see what the terminology problem is here.
> 
> I was using the term MSS clamping from this measurement study by Gorry's group:
>     https://iain.learmonth.me/stuff/pubs/UsableMTU2018.pdf <https://iain.learmonth.me/stuff/pubs/UsableMTU2018.pdf> 
> but it uses the same term whether networks do the clamping or end-systems do. In my sentence that you've quoted, I was using it to mean the sender limiting the size of the IP payload to a lower value than could have actually traversed the path. Sorry for not making that clear.

I believe Gorry’s paper is talking about net devices, though:

> MSS Clamping is also not without issues: we found a number of misconfigured middleboxes  

I don’t know if there’s a term for endpoints pulling down the endpoint MTU in other ways.

> Also, in case it wasn't clear, when I said clamping and PLPMTUD complement each other, I meant the sender initially clamping the payload size, then subsequently using PLPMTUD and removing its clamp to use a larger, more efficient packet size instead.

It may be useful to explain that if you include the complement issue.

Joe