Re: [Trigtran] Comments to current trigtran drafts

[Spencer Dawkins <[e-mail]>]

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

--- Reiner Ludwig <[e-mail]> wrote:
> 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

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