Subject: [Trigtran] Comments to current trigtran drafts

From: Reiner Ludwig <[email-masked]>
Date: Sun, 16 Mar 2003 20:13:12 +0100

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/trigtran

---

From: Spencer Dawkins <[email-masked]>
Date: Mon, 17 Mar 2003 12:47:19 -0800 (PST)

Reiner,

Thank you for your comments.

We should have made two things clearer - first, we'd like to
focus on the Framework draft at this meeting. 

We made a quick update to the Problem Statement draft to remove
00 text that we abandoned at/after the Atlanta IETF, but we
haven't made a full editing pass yet (and your comments will be
very helpful for this pass). In particular, we will insert text
on existing implicit end-to-end mechanisms when we do (and if
anyone would like to provide text, please send it along).

Second, and this is for everyone - the framework that Carl and I
put together is really a strawman proposal. 

For instance, the Connectivity Restored notification is one
alternative to solve a specific problem; it's not quite what's
been previously proposed as TCP Quickstart, or as ICMP
Encourage, and we're willing to move forward on any of these
alternatives, or on even better alternatives. It is not too late
to send text!

Thanks,

Spencer

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

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
_______________________________________________
Trigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/trigtran