Re: [Last-Call] Tsvart Last Call assignment: draft-ietf-masque-connect-ip

[Bob Briscoe <[e-mail]>]

David, and all,

I am trying to get review written up before your masque WG mtg. But...
Writing up my review stalled over the last few days, 'cos I focused on 
end of WGLC of one of my large drafts (just finished write-up of all the 
reviews).
My time tomorrow has just been DoS'd by my new line manager (I'm 
consulting for Apple), which is when I was planning to complete your 
review write up.
Might still do it tomorrow, but no promises. If/when you get it, it will 
be long, I'm afraid.


Bob

On 23/03/2023 22:36, Bob Briscoe wrote:
> David,
>
> On 23/03/2023 20:37, David Schinazi wrote:
>> [ + usual email lists ]
>>
>> Hi Bob, thanks for your review!
>
> [BB] That wasn't my review - working on it.
>
>
> Bob
>
>> Responses inline.
>> David
>>
>> On Thu, Mar 23, 2023 at 2:27 AM Bob Briscoe <[e-mail]> wrote:
>>
>>     masque-connect-ip authors,
>>
>>     My apologies. I do still intend to send in my tsv-art review of
>>     masque-connect-ip, but I'm running over a week late now.
>>     (It seems that my turn for review comes up more often than not just
>>     before the IETF meeting.)
>>
>>     I've got a number of detailed comments. But the main thing that's
>>     taking
>>     time is thinking through the potential interaction problems there
>>     might
>>     be when running a connectionless protocol as generic as IP through a
>>     connection-oriented tunnel. Particularly given there might be
>>     another
>>     connection-oriented protocol within the inner IP datagram.
>>
>>
>> FWIW, the issue here isn't the fact that anything is connection-oriented.
>> I don't think there is any problem to be had by running connectionless
>> protocols over connection-oriented ones or vice versa. That said, what
>> can make things interesting performance-wise is whether there are
>> nested congestion controllers or nested loss recovery mechanisms.
>>
>>     This probably
>>     needs a section akin to §6 of RFC9298, but I'm trying to think more
>>     widely of problems that might not have been considered when the IP
>>     packet was constrained to only encapsulate UDP.
>>
>>
>> That's a fair ask. Mentioning what we know about nested loss recovery
>> and about PMTUD can't hurt. I don't expect there to be much here in
>> addition to what he had in s6 of RFC 9298 though, since the switch
>> from UDP to IP won't change much (modulo IPv6 minimum MTU, which
>> is already covered).
>>
>>     I don't see any place for discussion of this in the draft, so I
>>     wondered
>>     whether there has been ML discussion somewhere that worked
>>     through all
>>     this and decided there were no issues. If you could point me to
>>     that it
>>     would greatly help me.
>>
>>
>> We had some good WG conversations about MTU here:
>> https://github.com/ietf-wg-masque/draft-ietf-masque-connect-ip/issues/45
>> https://github.com/ietf-wg-masque/draft-ietf-masque-connect-ip/issues/62
>> The discussions around performance happened around RFC 9298,
>> but we can copy that text here.
>>
>>     This email was not sent via the review tool, so apologies if I
>>     haven't
>>     got the email distros correct.
>>
>>     Bob
>>
>>     On 06/03/2023 08:42, Magnus Westerlund via Datatracker wrote:
>>     > Last Call review of: draft-ietf-masque-connect-ip (no specific
>>     version)
>>     > Deadline: 2023-03-15
>>     > Pages: 36
>>     > Requested by: (System)
>>     >
>>     >
>>     https://datatracker.ietf.org/doc/draft-ietf-masque-connect-ip/reviewrequest/17185/login/
>>     >
>>     > Magnus Westerlund has assigned Bob Briscoe as a reviewer for
>>     this document.
>>     >
>>     >
>>     >
>>     >
>>     >
>>
>>     -- 
>>     ________________________________________________________________
>>     Bob Briscoe http://bobbriscoe.net/
>>
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/