Re: [TERNLI] Notes from tonight's ad hoc

Mark Allman <mallman@icir.org> Fri, 28 July 2006 12:57 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6RuH-0006um-9P; Fri, 28 Jul 2006 08:57:33 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6RuG-0006uh-B3 for ternli@ietf.org; Fri, 28 Jul 2006 08:57:32 -0400
Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6RuE-0005ij-UP for ternli@ietf.org; Fri, 28 Jul 2006 08:57:32 -0400
Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k6SCvNsY056853; Fri, 28 Jul 2006 05:57:24 -0700 (PDT) (envelope-from mallman@icir.org)
Received: from lawyers.icir.org (guns.icir.org [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id E24D277B6F4; Fri, 28 Jul 2006 08:57:22 -0400 (EDT)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 670AF444391; Fri, 28 Jul 2006 08:56:08 -0400 (EDT)
To: kfall@intel.com
From: Mark Allman <mallman@icir.org>
Subject: Re: [TERNLI] Notes from tonight's ad hoc
In-Reply-To: <002301c6b23f$a3ef4a90$0300a8c0@kfallmobl>
Organization: ICSI Center for Internet Research (ICIR)
Song-of-the-Day: Down on the Corner
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Fri, 28 Jul 2006 08:56:08 -0400
Message-Id: <20060728125608.670AF444391@lawyers.icir.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: ternli@ietf.org
X-BeenThere: ternli@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: mallman@icir.org
List-Id: Transport-Enhancing Refinements to the Network Layer Interface <ternli.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ternli>, <mailto:ternli-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ternli>
List-Post: <mailto:ternli@ietf.org>
List-Help: <mailto:ternli-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ternli>, <mailto:ternli-request@ietf.org?subject=subscribe>
Errors-To: ternli-bounces@ietf.org

> I'm not sure how clear-cut it is.  E.g..  a path change might imply a
> likelihood of a significant capacity and latency change.  A capacity
> change due only to modulation change would likely affect the latency
> less drammatically, I would think.  On the "other other" hand, the
> system could generate two indicators on a path change :P.

Right... but, the transport isn't going to be able to figure all this
out any more than the link-layer.

I guess I see the signals as either ...

  + Giving the transport something it can directly use.  E.g., the
    available bandwidth just increased from 2Mbps to 11Mbps.  E.g.,
    the flow experienced congestion.  E.g., some probability of the
    fraction of losses due to corruption.

    These are different from less-directly-useful information like
    "switched to a new AP" or "am now using a different coding /
    modulation scheme" which are much less directly applicable. 

  + Giving a generic signal that *something* has changed and it likely
    matters and so the transport should re-init itself (e.g., forget the
    SRTT, RTTVAR, cwnd, ssthresh, MTU value, etc.).

allman