Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05

[Olivier Bonaventure <[e-mail]>]

Yoshi,
> 
> 
> 1: It seems that there are two modes in the converter architecture. One is clients use server's addresses for destination and the other is clients use converter's addresses for destination. 


The first one is clearly the most important one. I’m not aware of implementations that have explored the second case. 

>    But, clients need to use convert protocol to utilize converters. there won't be a transparent proxy like converter.
>    When I think in this way, I am wondering what's the advantages for clients to use server's address for their destinations.
>    BTW, do the implementations support both modes?

Taking MPTCP as an example, the motivation is that if the server supports MPTCP, it might be more interesting for a smartphone to establish the MPTCP connection directly to the final server. If the server does not support MPTCP, then it is better for the smartphone to establish first a connection to the converter to benefit from MPTCP in the access network. 
> 
> 2: In my understanding, this version of converter supports "client has feature X, but server doesn't" cases while it doesn't support "server has feature X, but client doesn't" cases. Or, can we do both cases? It seems to me this point is a bit unclear in the draft.   

The question becomes what are the options that the converter advertises in the SYN that it sends to the final server. One could imagine a converter that uses feature X for specific servers even if clients do not use it. A simple example is the timestamp option. Windows does not currently use timestamps
AFAIK while Linux uses them by default. A converter running on Linux and used by a Windows client would naturally advertise the timestamp option when interacting with a remote server. The same could apply to other options.

> 
> 3: I am not sure how TLS works when converter does mptcp conversions.
>     When a client have multiple subflows to a mptcp converter and use TLS for all subflows, can we establish an end-to-end TLS session between the client and the server?
> 

yes. TLS uses the bytestream and the 0-rtt convert protocol is fully transparent to the bytestream


Olivier


-- 


Disclaimer: https://www.tessares.net/mail-disclaimer/ 
<https://www.tessares.net/mail-disclaimer/>