[Trigtran] Comments to current trigtran drafts

Some comments to
draft-dawkins-trigtran-probstmt-01.txt, and
draft-dawkins-trigtran-framework-00.txt

draft-dawkins-trigtran-probstmt-01.txt:
---------------------------------------

- I'm missing from the document some earlier discussions we had on already 
existing *implicit* triggers. So, I repeat them here. The document says 
that the initial focus is on TCP ...
  * but, for "link down", and "rate down" TCP already has a fairly 
effective implicit trigger: "timeout and slow-start". The few spurious 
retransmits will probably amount to the same order of extra traffic as the 
proposed explicit out-of-band triggers. This implicit trigger also has the 
benefit that TCP (automatically) goes into a 
path-characteristics-learning-phase again, and the big benefit that it 
doesn't raise any trigger-spoofing concerns, and
  * for "link up", the soon-to-be-BCP-RFC, "Advice for Subnetwork 
Designers", and its proposed solution for transient link outages had been 
mentioned a couple of times. Yet, I don't see that documented in the draft.

- You say: "TIGTRAN routers and hosts must be able to discover each other". 
It would be nice if you could motivate that a bit more.

- In section 5 (protocol mechanisms) it seems that only explicit 
out-of-band notifications are "within scope". Didn't you also want to 
include the option to think about in-band packet marking solutions?


draft-dawkins-trigtran-framework-00.txt
---------------------------------------

- There is lots of copy/paste from the other draft. It could imagine that 
readers would prefer to see a cleaner seperation between problem statement 
and framework.

- You mention links with a "high uncorrected error rate". I would like to 
see some references to literature, so that the reader gets an idea of what 
kind of wireless access networks you are thinking of in this respect.

- In section 6 (security assessment), you say: "we don't think a security 
association is required between the TRIGTRAN router and the correspondent 
host receiving triggers", but in the other draft in the Security 
Conciderations Section, you suggest that a "TRIGTRAN protocol will have to 
include authentication for messsages". Is this a conflict, or did I miss 
something?

///Reiner

_______________________________________________
Trigtran mailing list
Trigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/trigtran