From nobody Mon Jan  5 13:53:41 2015
Return-Path: <aaron.falk@gmail.com>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A29E1A8AEF for <taps@ietfa.amsl.com>; Mon,  5 Jan 2015 13:53:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9D-zsDdkHfQ for <taps@ietfa.amsl.com>; Mon,  5 Jan 2015 13:53:37 -0800 (PST)
Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 567791A8AB4 for <taps@ietf.org>; Mon,  5 Jan 2015 13:53:37 -0800 (PST)
Received: by mail-vc0-f176.google.com with SMTP id hq12so8552049vcb.7 for <taps@ietf.org>; Mon, 05 Jan 2015 13:53:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:content-type; bh=XVZ/geuPrGb5lXMAV/GYav0KCr2T1YiKGMOV6ex68s0=; b=soNaEeNOdiv8+N+bpXJGrAKC5zlHlEcsxFOASq7Ebtoj7el/T5r3wFrGurvt2XKEjq zIslAlKwEwOYG96+WbZ6kKk09PQJs+qFfKhImZ1oVPiz1yTdc4ATfLGuTqR3HTxfjV0a Ru5vL+flvKGDEMXGf4H06XLf5339j2hBZAoxyAJ5s5w9y/ltLQQsYnKs9wZOp/u2oQkC gANc3BYel7LL4hbXmYQTqv+cYOGz1UYgKo3tOy5uL3bUd8bdHBSAgZWrn4gG3JyS8Hfs jgvc0A83HBBCh+/Ih+XdXnHbFEMLB2sW/imonVCqJNoojervPsrbE0EF7j+kwEMxAJn1 FfqA==
MIME-Version: 1.0
X-Received: by 10.221.66.138 with SMTP id xq10mr59211113vcb.24.1420494816527;  Mon, 05 Jan 2015 13:53:36 -0800 (PST)
Received: by 10.52.28.174 with HTTP; Mon, 5 Jan 2015 13:53:36 -0800 (PST)
Date: Mon, 5 Jan 2015 16:53:36 -0500
Message-ID: <CAD62q9XGimi4xTF3FPqiJ869cGn50CA9efYp1+DZbVAosTS8=g@mail.gmail.com>
From: Aaron Falk <aaron.falk@gmail.com>
To: "taps@ietf.org" <taps@ietf.org>
Content-Type: multipart/alternative; boundary=001a11364ca4f1ca02050beeb831
Archived-At: http://mailarchive.ietf.org/arch/msg/taps/T_7l8YF6Mck3fcTWSb_LPSMlbuE
Subject: [Taps] Dallas meeting planning - conflicts
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Jan 2015 21:53:39 -0000

--001a11364ca4f1ca02050beeb831
Content-Type: text/plain; charset=UTF-8

It's time to sign up for a meeting slot at IETF-93 in Dallas.  Here is the
list of conflicts I have from the last meeting.  My working definition of a
conflict is that someone active (or planning to be active) in the working
group has a commitment (e.g., an author or presenter) in another group that
would prevent them from attending the meeting.  Do we need to add any
others?

appsawg apparea aqm httpbis iccrg icnrg mptcp nvo3 ppsp rmcat  tcpinc tcpm
tsvarea tsvwg webpush

--aaron

--001a11364ca4f1ca02050beeb831
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">It&#39;s time to sign up for a meeting slot at IETF-93 in =
Dallas.=C2=A0 Here is the list of conflicts I have from the last meeting.=
=C2=A0 My working definition of a conflict is that someone active (or plann=
ing to be active) in the working group has a commitment (e.g., an author or=
 presenter) in another group that would prevent them from attending the mee=
ting.=C2=A0 Do we need to add any others?<div><br></div><div><span style=3D=
"font-size:13px">appsawg apparea aqm httpbis iccrg icnrg mptcp nvo3 ppsp rm=
cat=C2=A0 tcpinc tcpm tsvarea tsvwg webpush</span><br style=3D"font-size:13=
px"></div><div><br></div><div>--aaron</div></div>

--001a11364ca4f1ca02050beeb831--


From nobody Tue Jan  6 04:01:46 2015
Return-Path: <palmarti@cisco.com>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5135B1AC3F8 for <taps@ietfa.amsl.com>; Tue,  6 Jan 2015 04:01:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bcWHRRb2b3O for <taps@ietfa.amsl.com>; Tue,  6 Jan 2015 04:01:37 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FE6B1AC3D1 for <taps@ietf.org>; Tue,  6 Jan 2015 04:01:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4498; q=dns/txt; s=iport; t=1420545694; x=1421755294; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9sHhlxB/7tBB2yBlXbJOrOAZ6sTT9f0lAhNvI3/qIao=; b=fMiT15QaIU9GQQG4BGIjAIoE5I2PHI+y5VZQWr9hp2yIuKuXxB5vCTP9 rePjQIg0UFM0/pcpZ9VdOKoFMW1owec0IJ3UuJbVlHJDVJdibtCefniux c40aCkCCsSLr7EVQ/YcDwU06vI7RsvEGcIQLz4n+swO/YBy9p5chmPKOb Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArgFAFvNq1StJV2Z/2dsb2JhbABcgkNDUlgEgwHDNQEJhXMCHHMWAQEBAQF9hA0BAQQBAQEgSwsQAgEIBDsDAgICHwYLFBECBA4FiBgDEQ2tLZAcDYNuAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSNToIqB4JoLoETBY4ghzGBRIt/hVoig25vgUV+AQEB
X-IronPort-AV: E=Sophos;i="5.07,707,1413244800";  d="scan'208,217";a="110693113"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-2.cisco.com with ESMTP; 06 Jan 2015 12:01:33 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t06C1WpC021587 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Jan 2015 12:01:32 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.6]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Tue, 6 Jan 2015 06:01:32 -0600
From: "Pal Martinsen (palmarti)" <palmarti@cisco.com>
To: Aaron Falk <aaron.falk@gmail.com>
Thread-Topic: [Taps] Dallas meeting planning - conflicts
Thread-Index: AQHQKTIS1e7cUvnozUa/KJJK6TQi9JyzYzQA
Date: Tue, 6 Jan 2015 12:01:31 +0000
Message-ID: <A5044AFA-A7EB-4D73-9B6D-0D61D1A290EB@cisco.com>
References: <CAD62q9XGimi4xTF3FPqiJ869cGn50CA9efYp1+DZbVAosTS8=g@mail.gmail.com>
In-Reply-To: <CAD62q9XGimi4xTF3FPqiJ869cGn50CA9efYp1+DZbVAosTS8=g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.77.93]
Content-Type: multipart/alternative; boundary="_000_A5044AFAA7EB4D739B6D0D61D1A290EBciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/taps/w-uq9yAd4l5cEZftm_vwnN07hUg
Cc: "taps@ietf.org" <taps@ietf.org>
Subject: Re: [Taps] Dallas meeting planning - conflicts
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Jan 2015 12:01:40 -0000

--_000_A5044AFAA7EB4D739B6D0D61D1A290EBciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGksDQoNCg0KTWF5YmUgVFJBTSBhbmQgTU1VU0lDPyBUaGV5IGhhdmUgdGhlIHBvdGVudGlhbCBv
ZiBiZWluZyBhIGZ1dHVyZSBUQVBTIHVzZXIuDQoNCk5vdCBzdXJlIG90aGVyIFRBUFN0ZXJzIGFy
ZSBoYXZpbmcgdGhpcyBjb25mbGljdC4gV291bGQgYmUgbmljZSB0byBhZGQsIGJ1dCBtYXliZSB3
aXRoIGEgbG93IHByaW9yaXR5IGZsYWcgb2Ygc29tZSBraW5kPw0KDQoNCi4tLg0KUMOlbC1Fcmlr
DQoNCg0KT24gMDUgSmFuIDIwMTUsIGF0IDIyOjUzLCBBYXJvbiBGYWxrIDxhYXJvbi5mYWxrQGdt
YWlsLmNvbTxtYWlsdG86YWFyb24uZmFsa0BnbWFpbC5jb20+PiB3cm90ZToNCg0KSXQncyB0aW1l
IHRvIHNpZ24gdXAgZm9yIGEgbWVldGluZyBzbG90IGF0IElFVEYtOTMgaW4gRGFsbGFzLiAgSGVy
ZSBpcyB0aGUgbGlzdCBvZiBjb25mbGljdHMgSSBoYXZlIGZyb20gdGhlIGxhc3QgbWVldGluZy4g
IE15IHdvcmtpbmcgZGVmaW5pdGlvbiBvZiBhIGNvbmZsaWN0IGlzIHRoYXQgc29tZW9uZSBhY3Rp
dmUgKG9yIHBsYW5uaW5nIHRvIGJlIGFjdGl2ZSkgaW4gdGhlIHdvcmtpbmcgZ3JvdXAgaGFzIGEg
Y29tbWl0bWVudCAoZS5nLiwgYW4gYXV0aG9yIG9yIHByZXNlbnRlcikgaW4gYW5vdGhlciBncm91
cCB0aGF0IHdvdWxkIHByZXZlbnQgdGhlbSBmcm9tIGF0dGVuZGluZyB0aGUgbWVldGluZy4gIERv
IHdlIG5lZWQgdG8gYWRkIGFueSBvdGhlcnM/DQoNCmFwcHNhd2cgYXBwYXJlYSBhcW0gaHR0cGJp
cyBpY2NyZyBpY25yZyBtcHRjcCBudm8zIHBwc3Agcm1jYXQgIHRjcGluYyB0Y3BtIHRzdmFyZWEg
dHN2d2cgd2VicHVzaA0KDQotLWFhcm9uDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KVGFwcyBtYWlsaW5nIGxpc3QNClRhcHNAaWV0Zi5vcmc8bWFpbHRv
OlRhcHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rh
cHMNCg0K

--_000_A5044AFAA7EB4D739B6D0D61D1A290EBciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <0E43093684D54C4FA04CBD1872C3299C@emea.cisco.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksDQo8ZGl2IGNsYXNzPSIiPjxi
ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N
CjxkaXYgY2xhc3M9IiI+TWF5YmUgVFJBTSBhbmQgTU1VU0lDPyBUaGV5IGhhdmUgdGhlIHBvdGVu
dGlhbCBvZiBiZWluZyBhIGZ1dHVyZSBUQVBTIHVzZXIuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi
ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Ob3Qgc3VyZSBvdGhlciBUQVBTdGVy
cyBhcmUgaGF2aW5nIHRoaXMgY29uZmxpY3QuIFdvdWxkIGJlIG5pY2UgdG8gYWRkLCBidXQgbWF5
YmUgd2l0aCBhIGxvdyBwcmlvcml0eSBmbGFnIG9mIHNvbWUga2luZD88L2Rpdj4NCjxkaXYgY2xh
c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N
CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4uLS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+UMOlbC1Fcmlr
PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i
Ij48YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+
DQo8ZGl2IGNsYXNzPSIiPk9uIDA1IEphbiAyMDE1LCBhdCAyMjo1MywgQWFyb24gRmFsayAmbHQ7
PGEgaHJlZj0ibWFpbHRvOmFhcm9uLmZhbGtAZ21haWwuY29tIiBjbGFzcz0iIj5hYXJvbi5mYWxr
QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNo
YW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj5J
dCdzIHRpbWUgdG8gc2lnbiB1cCBmb3IgYSBtZWV0aW5nIHNsb3QgYXQgSUVURi05MyBpbiBEYWxs
YXMuJm5ic3A7IEhlcmUgaXMgdGhlIGxpc3Qgb2YgY29uZmxpY3RzIEkgaGF2ZSBmcm9tIHRoZSBs
YXN0IG1lZXRpbmcuJm5ic3A7IE15IHdvcmtpbmcgZGVmaW5pdGlvbiBvZiBhIGNvbmZsaWN0IGlz
IHRoYXQgc29tZW9uZSBhY3RpdmUgKG9yIHBsYW5uaW5nIHRvIGJlIGFjdGl2ZSkgaW4gdGhlIHdv
cmtpbmcgZ3JvdXAgaGFzDQogYSBjb21taXRtZW50IChlLmcuLCBhbiBhdXRob3Igb3IgcHJlc2Vu
dGVyKSBpbiBhbm90aGVyIGdyb3VwIHRoYXQgd291bGQgcHJldmVudCB0aGVtIGZyb20gYXR0ZW5k
aW5nIHRoZSBtZWV0aW5nLiZuYnNwOyBEbyB3ZSBuZWVkIHRvIGFkZCBhbnkgb3RoZXJzPw0KPGRp
diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxM3B4IiBjbGFzcz0iIj5hcHBzYXdnIGFwcGFyZWEgYXFtIGh0dHBiaXMg
aWNjcmcgaWNucmcgbXB0Y3AgbnZvMyBwcHNwIHJtY2F0Jm5ic3A7IHRjcGluYyB0Y3BtIHRzdmFy
ZWEgdHN2d2cgd2VicHVzaDwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtc2l6ZToxM3B4IiBjbGFzcz0i
Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh
c3M9IiI+LS1hYXJvbjwvZGl2Pg0KPC9kaXY+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NClRhcHMgbWFpbGluZyBsaXN0PGJyIGNs
YXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOlRhcHNAaWV0Zi5vcmciIGNsYXNzPSIiPlRhcHNAaWV0
Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby90YXBzPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxi
ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_A5044AFAA7EB4D739B6D0D61D1A290EBciscocom_--


From nobody Fri Jan 30 03:46:47 2015
Return-Path: <mirja.kuehlewind@tik.ee.ethz.ch>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A98C91A8BC5 for <taps@ietfa.amsl.com>; Fri, 30 Jan 2015 03:46:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.91
X-Spam-Level: 
X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmQd7RVluN6v for <taps@ietfa.amsl.com>; Fri, 30 Jan 2015 03:46:42 -0800 (PST)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A8621A8BB5 for <taps@ietf.org>; Fri, 30 Jan 2015 03:46:42 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 600A6D930D; Fri, 30 Jan 2015 12:46:40 +0100 (MET)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Y01Ugf7ZIvFP; Fri, 30 Jan 2015 12:46:40 +0100 (MET)
Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 2BAC1D930B; Fri, 30 Jan 2015 12:46:40 +0100 (MET)
Message-ID: <54CB6F1F.90507@tik.ee.ethz.ch>
Date: Fri, 30 Jan 2015 12:46:39 +0100
From: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= <mirja.kuehlewind@tik.ee.ethz.ch>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Joe Touch <touch@isi.edu>, Brian Trammell <ietf@trammell.ch>,  taps WG <taps@ietf.org>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>
References: <20141218140655.20397.13028.idtracker@ietfa.amsl.com> <B886DBE9-444B-4715-968D-FA56A9ACEC8D@trammell.ch> <549365CF.7020604@isi.edu>
In-Reply-To: <549365CF.7020604@isi.edu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/taps/Se6iG8Sv3Hg5oZ-nF_2H8Sa_JYc>
Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Jan 2015 11:46:45 -0000

Hi Joe,

I reply to the TCP part in this mail... see below.

On 19.12.2014 00:39, Joe Touch wrote:
> Some feedback below. Although I focus on some TCP and UDP specifics,
> some observations apply to other transports as well.
>
> Joe
>
> -----
>
> 3.1.1
> 	TCP segments fit into IP packets, but those packets are not
> 	necessarily constrained to fit into a lower-layer frame.
> 	They can be source fragmented.
Yes, but this is handled by IP and not by the transport. Therefore I believe 
that does not need to be mention here...?


>
> 	PathMTU discovery is supported by TCP but may be inhibited
> 	by network conditions (ICMP blocking); PLMTUD is supposed
> 	to be supported as well.
I added PLMTUD separately as well as the respective RFCs for both. However, I'm 
not sure if we actually need to distinguish which mechanism is used than rather 
just saying TCP supports path MTU discovery. (The notation in the draft current 
is PathMTU discovery which references to a specific mechanism but that be 
changes...).

>
> 3.1.2
> 	TCP's API is mostly specified in RFC793.
>
> 	What's missing are how options and parameters are managed.
Thanks, changed this.

>
> 3.1.3
> 	TCP provides a byte-ordered reliable stream. How that
> 	is delivered - e.g., by segments - is irrelevant, if only
> 	because TCP can change those segment boundaries during
> 	operation (e.g., with path MTU updates).
Yes but it is still something that TCP implements as a component. The discussion 
if this component should be revealed to the application as a transport feature 
should follow in the next paragraphs (which are not there yet...)

>
> 	this section should also mention flow control - TCP
> 	doesn't dump data on the floor if the receiver
> 	can't process it fast enough (vs. UDP)
Done. Somehow just forgot this...

>
> 	additionally, the ports ought to be discussed in more detail.
> 	ports in the SYN have a different meaning that ports in other
> 	segments. The SYN destination port indicates the receiving
> `	service, which typically involves BOTH demuxing to a process
> 	within a host AND indicating the format of the stream. Ports
> 	there and in all other segments are only demultiplexing
> 	indicators.
Added one sentence in section 3.1.1. and extended the connection setup up point to

	"connection setup with feature negotiation and application-to-port mapping"

Does that make sense to you?

Mirja


>
> 3.4.1
> 	UDP doesn't fragment packets into IP packets; it maps to
> 	a single IP packet, which itself may be fragmented. The
> 	IP fragments are what are limited by the lower-layer
> 	frames.
>
> 	Because UDP is connectionless, if you're going to talk
> 	about properties of sequences of messages, you need to
> 	explain what that sequence is - i.e., you need to
> 	define what it means to have a UDP flow, and only
> 	such flows are subject to flow/congestion control,
> 	PMTUD, etc.
>
>
> 3.4.2
> 	RFC768 describes an API for UDP. As with TCP,
> 	it leaves out options and parameters.
>
> 3.4.3
> 	should include port demuxing here too, with the same
> 	caveats as noted above for TCP (i.e., ports for
> 	messages have multiple meanings)
>
> ----
>
>
> On 12/18/2014 6:44 AM, Brian Trammell wrote:
>> Greetings, all,
>>
>> We've posted a -01 rev of the TAPS transports document. We believe that the format and level of detail for the TCP section is about what we're targeting for each of the other sections, but this is still open to discussion. The document also includes at least a little text on most of the transport protocols identified in the -00 revision. Welcome also to Mirja Kühlewind, added as an additional editor.
>>
>> If there are any additional transport protocols we're missing, or other comments on document structure, please send them to the list.
>>
>> Document source is available (with a kramdown-rfc2629-based workflow) at https://github.com/britram/taps-transports. Feel free to send pull requests against the markdown, or XML/text diffs to the editors, for contributions to sections of the document.
>>
>> Cheers, and merry Christmas,
>>
>> Brian
>>
>>> On 18 Dec 2014, at 15:06, internet-drafts@ietf.org wrote:
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>> This draft is a work item of the Transport Services Working Group of the IETF.
>>>
>>>         Title           : Services provided by IETF transport protocols and congestion control mechanisms
>>>         Authors         : Godred Fairhurst
>>>                           Brian Trammell
>>>                           Mirja Kuehlewind
>>> 	Filename        : draft-ietf-taps-transports-01.txt
>>> 	Pages           : 15
>>> 	Date            : 2014-12-18
>>>
>>> Abstract:
>>>    This document describes services provided by existing IETF protocols
>>>    and congestion control mechanisms.  It is designed to help
>>>    application and network stack programmers and to inform the work of
>>>    the IETF TAPS Working Group.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-taps-transports/
>>>
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-taps-transports-01
>>>
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-01
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> Taps mailing list
>>> Taps@ietf.org
>>> https://www.ietf.org/mailman/listinfo/taps
>>
>> _______________________________________________
>> Taps mailing list
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
>>
>
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps
>

-- 
------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Communication Systems Group
Institute TIK, ETH Zürich
Gloriastrasse 35, 8092 Zürich, Switzerland

Room ETZ G93
phone: +41 44 63 26932
email: mirja.kuehlewind@tik.ee.ethz.ch
------------------------------------------


From nobody Fri Jan 30 11:23:39 2015
Return-Path: <touch@isi.edu>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3931A03A1 for <taps@ietfa.amsl.com>; Fri, 30 Jan 2015 11:23:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.61
X-Spam-Level: 
X-Spam-Status: No, score=-6.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joI1wgJjU_DU for <taps@ietfa.amsl.com>; Fri, 30 Jan 2015 11:23:35 -0800 (PST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B02191A039D for <taps@ietf.org>; Fri, 30 Jan 2015 11:23:35 -0800 (PST)
Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t0UJN35O026230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 30 Jan 2015 11:23:04 -0800 (PST)
Message-ID: <54CBDA16.30005@isi.edu>
Date: Fri, 30 Jan 2015 11:23:02 -0800
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= <mirja.kuehlewind@tik.ee.ethz.ch>, Brian Trammell <ietf@trammell.ch>, taps WG <taps@ietf.org>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>
References: <20141218140655.20397.13028.idtracker@ietfa.amsl.com> <B886DBE9-444B-4715-968D-FA56A9ACEC8D@trammell.ch> <549365CF.7020604@isi.edu> <54CB6F1F.90507@tik.ee.ethz.ch>
In-Reply-To: <54CB6F1F.90507@tik.ee.ethz.ch>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <http://mailarchive.ietf.org/arch/msg/taps/ZdAH5VkN4Ey1Q6k65zsYa7Z4fIs>
Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Jan 2015 19:23:37 -0000

Hi, Mirja,

On 1/30/2015 3:46 AM, Mirja Kühlewind wrote:
> Hi Joe,
>
> I reply to the TCP part in this mail... see below.
>
> On 19.12.2014 00:39, Joe Touch wrote:
>> Some feedback below. Although I focus on some TCP and UDP specifics,
>> some observations apply to other transports as well.
>>
>> Joe
>>
>> -----
>>
>> 3.1.1
>>     TCP segments fit into IP packets, but those packets are not
>>     necessarily constrained to fit into a lower-layer frame.
>>     They can be source fragmented.
 >
> Yes, but this is handled by IP and not by the transport. Therefore I
> believe that does not need to be mention here...?

The problem is in the first sentence:

    TCP partitions a continuous stream of bytes into segments, sized to
    fit in IP packets, constrained by the maximum size of lower layer
    frame.

The first part is true (TCP fits into IP), but the second is not (IP is 
NOT constrained by the max size of the lower-layer frame). IP is 
constrained only by the ability of IP (i.e., of L3 to reassemble at the 
destination).

>>     PathMTU discovery is supported by TCP but may be inhibited
>>     by network conditions (ICMP blocking); PLMTUD is supposed
>>     to be supported as well.
 >
> I added PLMTUD separately as well as the respective RFCs for both.
> However, I'm not sure if we actually need to distinguish which mechanism
> is used than rather just saying TCP supports path MTU discovery. (The
> notation in the draft current is PathMTU discovery which references to a
> specific mechanism but that be changes...).

"Path MTU discovery" is ambiguous; it can refer to any mechanism that 
allows the path MTU to be known, or it can refer to the specific 
mechanism by that name in RFC 1191.

If you mean the more general concept, it would be better to use a term 
that is unambiguous in referring to both (e.g., discovery of the path 
MTU). Once you tie the words together as "path MTU discovery", it could 
be misinterpreted as meaning only RFC 1191.

However, IMO, in this doc it would be better to be more clear and 
explicit by naming both mechanisms.

...
>> 3.1.3
>>     TCP provides a byte-ordered reliable stream. How that
>>     is delivered - e.g., by segments - is irrelevant, if only
>>     because TCP can change those segment boundaries during
>>     operation (e.g., with path MTU updates).
 >
> Yes but it is still something that TCP implements as a component.

TCP definitely does not. There is no required correlation between SEND 
boundaries and segment boundaries.

Some TCP implementations do, but there is nothing to ensure that 
boundaries controlled by the sending application are exposed to the 
receiving application.

I don't think this doc should discuss how implementations go astray in 
this way.

...
>>     additionally, the ports ought to be discussed in more detail.
>>     ports in the SYN have a different meaning that ports in other
>>     segments. The SYN destination port indicates the receiving
>> `    service, which typically involves BOTH demuxing to a process
>>     within a host AND indicating the format of the stream. Ports
>>     there and in all other segments are only demultiplexing
>>     indicators.
 >
> Added one sentence in section 3.1.1. and extended the connection setup
> up point to
>
>      "connection setup with feature negotiation and application-to-port
> mapping"
>
> Does that make sense to you?

The sentence does, but that doesn't sufficiently (IMO) address the 
feedback I gave above.

TCP has two portions:
	- connection establishment
		feature negotiation
		service-to-port mapping
		connection identification

	- established connection data transfer
		which continues to use the connection identifier

Joe


From nobody Sat Jan 31 08:29:39 2015
Return-Path: <wolfgang.beck01@googlemail.com>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D01131A9080 for <taps@ietfa.amsl.com>; Fri, 30 Jan 2015 07:20:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.072
X-Spam-Level: *
X-Spam-Status: No, score=1.072 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1KryRIhIrmZ for <taps@ietfa.amsl.com>; Fri, 30 Jan 2015 07:20:01 -0800 (PST)
Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4DF11A9074 for <taps@ietf.org>; Fri, 30 Jan 2015 07:20:01 -0800 (PST)
Received: by mail-pa0-f54.google.com with SMTP id eu11so53462014pac.13 for <taps@ietf.org>; Fri, 30 Jan 2015 07:20:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=g/C5s26vTphojtsqSysq4r9dX02QgO4ndzSZvyMRkCw=; b=r+KLMR7ydu3gHkdk7Do9IbOOXnn9ANrZZs24sA09Jlde9eE0n8mmIDh+7YPw6n7e7/ LZmhd2frsVAz0g7UeLIs8dCLh22XX60DQrujHE9X8Ne66pddtKjsLTm4EjW1F16RWdSn Pi+oG9pGxHjHxmfvr4pcTP8+REQWccO4XC4Y3llbc9D69gQ0wRvlArIdPdzqEen7OFZL owJkfWA8EgyfRkd4juo/WeVDjubTGYbHue1F3FMlIck+7It+aQnbl80ukzSNi+pVkSgQ nQFcTyF+ub52DdX1g6VsFCGIdUF8cwsUETbPQuhNiFhdLncMw8F2or+uCVi9QAJT1Fzj 9BUw==
MIME-Version: 1.0
X-Received: by 10.70.44.132 with SMTP id e4mr9722585pdm.58.1422631200987; Fri, 30 Jan 2015 07:20:00 -0800 (PST)
Received: by 10.66.220.42 with HTTP; Fri, 30 Jan 2015 07:20:00 -0800 (PST)
Date: Fri, 30 Jan 2015 16:20:00 +0100
Message-ID: <CAAJUQMj5BSiygkuPZSBcbfSM_k3mrRG2C2ircXtbbX4MgDoPmQ@mail.gmail.com>
From: Wolfgang Beck <wolfgang.beck01@googlemail.com>
To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>
Content-Type: multipart/alternative; boundary=089e0103ecde61a0f3050de0233c
Archived-At: <http://mailarchive.ietf.org/arch/msg/taps/5abusyzgD1_sNBICeWEr25-1WP0>
X-Mailman-Approved-At: Sat, 31 Jan 2015 08:29:37 -0800
Cc: taps@ietf.org
Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Jan 2015 15:20:03 -0000

--089e0103ecde61a0f3050de0233c
Content-Type: text/plain; charset=UTF-8

Would it make sense to include statements about latency?

We recently had a discussion with one of our suppliers about application
layer timeouts that fired while the request was still stuck in the send
queue.

There were statements like 'UDP never queues' or 'we can't control the TCP
send buffer size'.

Maybe some general discussion of the interactions between application layer
timers and transport layer retransmission strategies (like Nagle) would be
useful.


Wolfgang Beck

--089e0103ecde61a0f3050de0233c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div>Would it make sense to include stateme=
nts about latency?<br></div><br>We recently had a discussion with one of ou=
r suppliers about application layer timeouts that fired while the request w=
as still stuck in the send queue.<br></div><br>There were statements like &=
#39;UDP never queues&#39; or &#39;we can&#39;t control the TCP send buffer =
size&#39;.<br></div><br></div>Maybe some general discussion of the interact=
ions between application layer timers and transport layer retransmission st=
rategies (like Nagle) would be useful.<br><div><div><br><br></div><div>Wolf=
gang Beck<br></div></div></div>

--089e0103ecde61a0f3050de0233c--


From nobody Sat Jan 31 23:52:04 2015
Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B8D1A8757 for <taps@ietfa.amsl.com>; Sat, 31 Jan 2015 23:52:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.789
X-Spam-Level: 
X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdnEUhNMltR7 for <taps@ietfa.amsl.com>; Sat, 31 Jan 2015 23:52:00 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id C3F1D1A8761 for <taps@ietf.org>; Sat, 31 Jan 2015 23:51:59 -0800 (PST)
Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id AA9731B0052A; Sun,  1 Feb 2015 07:52:24 +0000 (GMT)
Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Sun, 1 Feb 2015 07:51:48 -0000
Message-ID: <ed922317145419a9a873b30db8b60c8d.squirrel@erg.abdn.ac.uk>
In-Reply-To: <CAAJUQMj5BSiygkuPZSBcbfSM_k3mrRG2C2ircXtbbX4MgDoPmQ@mail.gmail.com>
References: <CAAJUQMj5BSiygkuPZSBcbfSM_k3mrRG2C2ircXtbbX4MgDoPmQ@mail.gmail.com>
Date: Sun, 1 Feb 2015 07:51:48 -0000
From: gorry@erg.abdn.ac.uk
To: "Wolfgang Beck" <wolfgang.beck01@googlemail.com>
User-Agent: SquirrelMail/1.4.23 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: <http://mailarchive.ietf.org/arch/msg/taps/IdB_lJKPtDS9-NoQ_Eg-FDbKhaQ>
Cc: =?iso-8859-1?Q?=22Mirja_K=C3=BChlewind=22?= <mirja.kuehlewind@tik.ee.ethz.ch>, taps@ietf.org
Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Feb 2015 07:52:02 -0000

> Would it make sense to include statements about latency?
>
I think if we come to think about the API that could be presented by TAPS
to the application, we'll need to focus on what characteristics the Apps
expect from the network. Low latency is clearly one service that many apps
will desire.

> We recently had a discussion with one of our suppliers about application
> layer timeouts that fired while the request was still stuck in the send
> queue.
>
> There were statements like 'UDP never queues' or 'we can't control the TCP
> send buffer size'.
>
> Maybe some general discussion of the interactions between application
> layer
> timers and transport layer retransmission strategies (like Nagle) would be
> useful.
>
I agree, some words on the Latency introduced by mechanisms would be good.

> Wolfgang Beck
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps
>
Gorry