Re: [lisp] Fwd: New Version Notification for draft-rodrigueznatal-lisp-oam-00.txt

[Matthieu Coudron <[e-mail]>]

We agree with your corrections. See comments inline.

Cheers

Matthieu Coudron
Stefano Secci

 >     ____________________________
 >     2. Underlay definition
 >     "The underlay corresponds to the RLOC space"
 >     This appears as too restrictive, as information about the underlay
 >     could come also from local AS/domain-level information such as
 >     traffic engineering databases, monitoring tools, etc, unaware of 
LISP.
 >
 > [AR] I think we could reword that. How about this text?
 >
 > "In most cases the underlay is equivalent to the RLOC space, however it
 > can also comprise information from external sources such traffic
 > engineering databases, monitoring tools, etc"
ok

 >     ____________________________
 >     3.2 MPTCP
 >     "Each of these sub-flows behaves as a legacy TCP flow and hence,
 >     from the network point of view, each sub-flow is a different TCP
 >     session. The network conditions over the different paths the
 >     sub-flows follow affect the whole MPTCP session.  Since MPTCP has to
 >     keep the aggregate session consistent, each aggregated flow can
 >     perform as good as the worst of the sub flows it integrates."
 >
 >     This paragraph seems incorrect. MPTCP RFC 6182 section 2.1 states
 >     that MPTCP should be at least as good as TCP, which in practice is
 >     true except in a few cases (e.g., if a subflow with a large share of
 >     the window becomes inactive, then you need to wait several timeouts
 >     before being able to be aggressive enough on other subflows). The
 >     RFC does not precisely address the scheduling mechanisms, but if for
 >     instance you consider the Linux implementation
 >     (http://www.multipath-tcp.org)__, it sends a maximum amount of data
 >     on the subflow with the lowest RTT and once its window is full, it
 >     will send on the 2nd lowest RTT subflow etc... so providing there is
 >     enough buffering at each endpoint, in terms of sheer throughput
 >     MPTCP should be able to aggregate all the subflows independently of
 >     their latency. It is true though that if packets are not scheduled
 >     carefully on each subflow, then application latency may  increase.
 >
 >
 > [AR] I believe that we are on the same page here. The point that we
 > tried to make here is that "on worst case scenario, MPTCP performs as
 > good as TCP". Perhaps that was not stated clearly enough. Maybe we could
 > keep this paragraph short (one sentence) and just point people to MPTCP
 > RFC. Would that make sense?
Agreed with both points. The document should focus on how MPTCP can 
benefit from LISP and there are several ways. The one you present is to 
focus on maximally disjoint paths to support the best link backup 
scenario. If increased throughput is the goal of the scenario, then 
maximally disjoint paths may not be the best solution; the subflows 
could share some links as long as this link is not a bottleneck for the 
connection.
An additional scenario could be to forward at least one subflow on a 
LISP path that is considered secure, e.g., over it it would be harder 
for an attacker to rebuild the stream of data.

       ____________________________
 >     4. Requirements / Device Discovery
 >     "This is solved for xTRs by sending Map Register messages."
 >
 >     Did you mean Map Requests? Or can you explain why only Map Register?
 >
 > [AR] We were talking here about the fact that in vanilla LISP the
 > MappingSystem can be aware of existing xTRs since they keep sending
 > MapRegisters. The MapRegister process works already as an automated
 > discovery mechanism. We'll extend the sentence to clarify this.

ok - it seems more appropriate to replace "xTRs" with "ETRs".

 >
 >     ____________________________
 >     4. Requirements / Forwarding Actions
 >
 >     "These actions can be implemented as extensions to the current
 >     specifications of LISP-TE or LISP-SR or be defined by means of a new
 >     LCAF."
 >
 >     Here it would be better not to exclude existing LCAF. For the MPTCP
 >     use-case, we have a prototype using already proposed LCAF messages.
 >
 >
 > [AR] Good point. How about this?
 >
 > "These actions can be implemented as extensions to the current
 > specifications of LISP-TE or LISP-SR, leverage on reusing existing LCAF
 > types or be defined by means of a new LCAF."
ok