Re: [Trigtran] Comments to current trigtran drafts

sjkoh@etri.re.kr Tue, 18 March 2003 19:57 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26853 for <trigtran-archive@odin.ietf.org>; Tue, 18 Mar 2003 14:57:19 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IKEKe14571 for trigtran-archive@odin.ietf.org; Tue, 18 Mar 2003 15:14:20 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IKEKO14568 for <trigtran-web-archive@optimus.ietf.org>; Tue, 18 Mar 2003 15:14:20 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26838 for <trigtran-web-archive@ietf.org>; Tue, 18 Mar 2003 14:56:47 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IKEAO14559; Tue, 18 Mar 2003 15:14:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IKDsO14523 for <trigtran@optimus.ietf.org>; Tue, 18 Mar 2003 15:13:54 -0500
Received: from cms1.etri.re.kr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26823 for <trigtran@ietf.org>; Tue, 18 Mar 2003 14:56:20 -0500 (EST)
From: sjkoh@etri.re.kr
Received: by cms1 with Internet Mail Service (5.5.2653.19) id <G8R60F0R>; Wed, 19 Mar 2003 04:58:04 +0900
Message-ID: <54A1DDB4ACD5D511B0F900D0B7A8DC08796AA5@cms1>
To: trigtran@ietf.org
Subject: Re: [Trigtran] Comments to current trigtran drafts
Date: Wed, 19 Mar 2003 04:58:03 +0900
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2ED88.AF9B9760"
Sender: trigtran-admin@ietf.org
Errors-To: trigtran-admin@ietf.org
X-BeenThere: trigtran@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/trigtran>, <mailto:trigtran-request@ietf.org?subject=unsubscribe>
List-Id: Triggers for Transport <trigtran.ietf.org>
List-Post: <mailto:trigtran@ietf.org>
List-Help: <mailto:trigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/trigtran>, <mailto:trigtran-request@ietf.org?subject=subscribe>

My name is Seok Joo Koh.

Basically I support the creation of TRIGTRAN WG, because
I think any triggers could be helpfully used for the existing protocols,
whether it is an implicit L2 trigger or an explicit trigger from TRIGTRAN
routers.

Actually, my personal interest is in the use of triggers for IP handover
(and movement detection)
in mobile SCTP as well as mobile IP.

I believe the TRIGTRAN works are at least worthwhile to make a big jump for
the other IETF protocols/works.

Just my two cents.

Seok Joo Koh

----- Original Message -----
From: "Spencer Dawkins" <spencer_dawkins@yahoo.com>
To: <trigtran@ietf.org>
Sent: Tuesday, March 18, 2003 5:47 AM
Subject: Re: [Trigtran] Comments to current trigtran drafts


> 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 <Reiner.Ludwig@eed.ericsson.se> 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
> Trigtran@ietf.org
> https://www1.ietf.org/mailman/listinfo/trigtran