[Taps] review: draft-grinnemo-taps-he-02

[Karl-Johan Grinnemo <[e-mail]>]

Hi Vaibhav!

Thanks for your comments (and sorry for my late reply).

Overall, I like this document (suggestions for improvements below). I hope an

HE mechanism helps get future transport protocols get wider adoption.

-- Vaibhav


  To be compliant with RFC 6555 [RFC6555], the Policy Management component
  SHOULD, in those cases there are no policies telling otherwise, give priority
  to IPv6 over IPv4.

-- RFC 6555 does not give priority to v6. Yes, this was the original
motivation for the document, but RFC 6555 states that the priority is dictated
by the address selection policy [RFC 6724]. In majority of the scenarios this
boils down to giving priority to native v6. However, if a host has native v4
and Teredo connectivity, a HE implementation will happily give priority to
native v4 over Teredo.



Probably this part of the text should be changed so that it aligns with RFC 6555.

To minimize the number of connection attempts that are initiated, the Transport Probing component SHOULD cache the outcome of connection attempts in a repository kept by the Policy Management component. Cached connection-attempt results SHOULD be valid for a configurable amount of time after which they SHOULD expire and have to be repeated. -- How long should this cache be? How is this configured?

The cache lifetime has been seen as an implementation-dependent parameter, and thus deliberately omitted.
Still, I am aware of RFC 6555 in Section 4, Algorithm Requirements, saying that "Cache entries should be
flushed when their age exceeds a system-defined maximum on the order of 10 minutes, so maybe this needs
some further deliberations.

D then governs the delay between the initiation of the connection attempts C1 and C2. -- how is delay D determined?

As with the cache lifetime, the exact way the delay is set is considered implementation dependent. In the
NEAT system, the system used in the example in Section 6, the delay for a connection attempt is set as
DELTA * priority, where DELTA is a parameter which governs the time difference between two consecutive
priority levels (in NEAT, priority goes from 0 and upwards, with 0 being the highest priority).

For the Transport Probing component to be able to efficiently use the connection-attempt cache, already-initiated, non-winning transport solutions SHOULD NOT be terminated as soon as a winning connection has been established. -- I found this sentence confusing. Perhaps an example helps here.

I will definitely reformulate this. Maybe, it would be easier to read this sentence if it was
shortened to "For the Transport Probing component to be able to efficiently use the connection-attempt
cache, already-initiated transport solutions SHOULD NOT be terminated..."

As pointed out in RFC 6555 [RFC6555], a HE algorithm should not waste networking resources by routinely making simultaneous connection attempts. To this end, the HE algorithm should cache the outcome of previous connection attempts to the same peer. The impact and efficiency of the HE algorithm has been evaluated in [Papastergiou16]. The paper suggests that caching significantly reduces the CPU load imposed by a HE mechanism. -- Perhaps make it clear that [Papastergiou16] discusses the impact of memory and cpu resources on the end-host and not networking resources on the wire.

Agree.

Consider a scenario in which an IPv4-only client using the ... -- Why not v6-only client instead? :)

No particular reason, could probably change from IPv4 to IPv6.

-- It was unclear to me how the the list of candidate protocols is generated by the policy manager. An example would help here. I am even thinking perhaps this is out of scope of this document.

The policy manager is not within the scope of this I-D. Still, maybe it would help
to supply a reference to our paper, N. Khademi, D. Ros, M. Welzl, Z. Bozakov, A. Brunstrom,
G. Fairhurst, K.-J. Grinnemo, D. Hayes, P. Hurtig, T. Jones, S. Mangiante, M. Tüxen, and
F. Weinrank. "NEAT: A Platform- and Protocol-Independent Internet Transport API,” which offers
a description of the policy manager.


Again, thanks for your comments!

Best Regards
Karl-Johan Grinnemo
Lektor/Senior Lecturer
Datavetenskap/Computer Science
Karlstads universitet/Karlstad university
Tfn.:/Phone: [phone]
Mobil:/Mobile: [phone]
Skype: karlgrin

-------------------------- Vaibhav Bajpai www.vaibhavbajpai.com<http://www.vaibhavbajpai.com/> Postdoctoral Researcher TU Munich, Germany --------------------------