From apopov@palermo.edu Thu Jan 2 11:39:18 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E29F01AD939 for ; Thu, 2 Jan 2014 11:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.372 X-Spam-Level: X-Spam-Status: No, score=0.372 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, T_DKIM_INVALID=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 8dHFk81qP_Fh for ; Thu, 2 Jan 2014 11:39:15 -0800 (PST) Received: from maxwell.palermo.edu (maxwell.palermo.edu [200.69.213.7]) by ietfa.amsl.com (Postfix) with ESMTP id D2F7B1AD8F1 for ; Thu, 2 Jan 2014 11:39:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=palermo.edu; s=default; t=1388691529; bh=CyckcyUo833BRK7qEHC9YT2bWv4JUpZvtweRtWSqmTs=; h=Date:From:To:References:In-Reply-To:Subject; b=PrcivF489u/vBmIK1c9ICe5XSMilOiiJ+5yeO9Wr7u3NaaJisPI5g0eSzl9Kz/Yyi dlruiSFp1NJldoiFlOEffkvZ0kTYAsQvS8C+06Cliulkm9eYF55RUIHPDIIkKeNyXF batkDWO7SY6eJibhy4wtje3oTYL6kzjMPMsQzfxE= Received: from maxwell.palermo.edu (localhost [127.0.0.1]) by maxwell.palermo.edu (8.14.4/8.13.8) with ESMTP id s02Jcme5005091; Thu, 2 Jan 2014 16:38:49 -0300 Received: from [10.30.0.3] ( [10.30.0.3]) by maxwell.palermo.edu with ESMTP id BVV41HIB.131332.0 Message-ID: <52C5C10E.7030703@palermo.edu> Date: Thu, 02 Jan 2014 16:42:06 -0300 From: Alejandro Popovsky User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Mark Lloyd , Joe Touch , "tcpm@ietf.org" References: <52B8829B.9050308@palermo.edu> <52B88AF6.5010808@isi.edu> <2A08B7ACA17C9F4BAA8D5395DF908D73A30FE932@SEAEMBX01.olympus.F5Net.com> In-Reply-To: <2A08B7ACA17C9F4BAA8D5395DF908D73A30FE932@SEAEMBX01.olympus.F5Net.com> Content-Type: multipart/alternative; boundary="------------090609050708020505040205" X-Authorization-Id: who=apopov X-Host: 10.30.0.3 Subject: Re: [tcpm] end of burst, delayed acks, and push flag X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 19:39:19 -0000 This is a multi-part message in MIME format. --------------090609050708020505040205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit As Joe mentioned, disabling the ack delay at the end of bursts, would make the senders grow the congestion window faster (when not in congestion avoidance). On the other side, one of the causes for spurious timeouts is the delay ack at the end of a burst, as Jerry Chu mentioned in the minimum RTO discussion , so it might be beneficial to reduce them. Some have proposed a sender modification to use an adaptive minimum RTO to handle the delayed acks at the end of bursts. Considering all these, may be a receiver modification based on push flags could lower the spurious timeouts if used only for bursts longer than a minimum? Alejandro. On 30/12/2013 07:24 p.m., Mark Lloyd wrote: > Is the RFC mandated super high Min-RTO time in play here? > > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Joe Touch > Sent: Monday, December 23, 2013 11:12 AM > To: Alejandro Popovsky; tcpm@ietf.org > Subject: Re: [tcpm] end of burst, delayed acks, and push flag > > > > On 12/23/2013 10:36 AM, Alejandro Popovsky wrote: >> The delayed ack generation may bother when applied to the last segment >> of a burst. > That's not clear at all - see below. > >> There is no 'end of burst indication' from regular senders, i.e. >> senders with no tail probing (TLP), nor end of burst reordering (Scheffenegger). >> >> But on many implementations, the operating system sets the push flag >> when sending the last byte of a write(...) function call. So push flag >> helps to identify the end of a burst. > It might want to set the PUSH flag on the last write in a sequence of > write() calls in a burst, but the PUSH flag applies to the last write() call, not to a byte within the write(). > >> So a way to prevent the problem, could be to disable the ack delay for >> a/'/push' data segment coming after at least one 'non-push' data >> segment. > First, let's assume Nagle is off, as it should be for bursty traffic. > > One side (named 'Alba') sends bursts packets to the other (named 'Nisar'). > > Let's further assume that the burst is an odd number of packets (if it's even, then delayed ACK will work fine). > > Alba sends 1 packet to Nisar (this is the degenerate case; if it works for 1, it'll work for larger numbers). > > Nisar waits to ACK. > > One of three things happens next: > > - a timeout (500 ms later), when Nisar sends the ACK > for the burst > > - Nisar has something to send to Alba, at which point > Nisar will include the most recent ACK anyway (AFAICT) > > - Alba has something to send to Nisar, at which point she > will send the first packet of it (because the window is > always at least 3 packets) > > at which point Nisar will ACK the last burst > and the new packet > > I.e., the only way this stalls is when Alba's window is smaller than 1 packet. Otherwise, not getting the ACK of the last bursts costs Alba at most one packet of capacity during the first round-trip of the next burst. > > I'm not sure that PUSH is the right way to fix this; just because it's the end of a burst doesn't mean there won't be another burst in much less than 500 ms, and using PUSH the way you describe could cause bursty sources to circumvent delayed ACK, in which case their window would grow faster than those that use delayed ACK today. > > I don't see how that's worth one packet. > > Joe > >> Best regards, Alejandro. >> >> >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --------------090609050708020505040205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
As Joe mentioned, disabling the ack delay at the end of bursts, would
make the senders grow the congestion window faster (when not in
congestion avoidance).

On the other side, one of the causes for spurious timeouts is the delay ack
at the end of a burst, as Jerry Chu mentioned in the minimum RTO discussion,
so it might be beneficial to reduce them. Some have proposed a
sender modification to use an adaptive minimum RTO to handle the
delayed acks at the end of bursts.

Considering all these, may be a receiver modification based on push flags
could lower the spurious timeouts if used only for bursts longer than a minimum?

Alejandro.



On 30/12/2013 07:24 p.m., Mark Lloyd wrote:
Is the RFC mandated super high Min-RTO time in play here? 

-----Original Message-----
From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Joe Touch
Sent: Monday, December 23, 2013 11:12 AM
To: Alejandro Popovsky; tcpm@ietf.org
Subject: Re: [tcpm] end of burst, delayed acks, and push flag



On 12/23/2013 10:36 AM, Alejandro Popovsky wrote:

The delayed ack generation may bother when applied to the last segment 
of a burst.

That's not clear at all - see below.


There is no 'end of burst indication' from regular senders, i.e. 
senders with no tail probing (TLP), nor end of burst reordering (Scheffenegger).

But on many implementations, the operating system sets the push flag 
when sending the last byte of a write(...) function call. So push flag 
helps to identify the end of a burst.

It might want to set the PUSH flag on the last write in a sequence of
write() calls in a burst, but the PUSH flag applies to the last write() call, not to a byte within the write().


So a way to prevent the problem, could be to disable the ack delay for 
a/'/push' data segment coming after at least one 'non-push' data 
segment.

First, let's assume Nagle is off, as it should be for bursty traffic.

One side (named 'Alba') sends bursts packets to the other (named 'Nisar').

Let's further assume that the burst is an odd number of packets (if it's even, then delayed ACK will work fine).

Alba sends 1 packet to Nisar (this is the degenerate case; if it works for 1, it'll work for larger numbers).

Nisar waits to ACK.

One of three things happens next:

	- a timeout (500 ms later), when Nisar sends the ACK
	for the burst

	- Nisar has something to send to Alba, at which point
	Nisar will include the most recent ACK anyway (AFAICT)

	- Alba has something to send to Nisar, at which point she
	will send the first packet of it (because the window is
	always at least 3 packets)

		at which point Nisar will ACK the last burst
		and the new packet

I.e., the only way this stalls is when Alba's window is smaller than 1 packet. Otherwise, not getting the ACK of the last bursts costs Alba at most one packet of capacity during the first round-trip of the next burst.

I'm not sure that PUSH is the right way to fix this; just because it's the end of a burst doesn't mean there won't be another burst in much less than 500 ms, and using PUSH the way you describe could cause bursty sources to circumvent delayed ACK, in which case their window would grow faster than those that use delayed ACK today.

I don't see how that's worth one packet.

Joe


Best regards, Alejandro.




_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm


_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

--------------090609050708020505040205-- From M.Lloyd@f5.com Thu Jan 2 12:30:39 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 116EB1ADFD7 for ; Thu, 2 Jan 2014 12:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.438 X-Spam-Level: X-Spam-Status: No, score=-7.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, 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 fFQfaujgaqDj for ; Thu, 2 Jan 2014 12:30:36 -0800 (PST) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id DEFBE1ADFC6 for ; Thu, 2 Jan 2014 12:30:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,592,1384300800"; d="scan'208,217";a="95748552" X-IPAS-Result: AqQEAA7LxVLAqArr/2dsb2JhbABOCg4IgjF8VbhvgSF0giUBAQEBAQIBAQEqQRcEAgEIDQEDBAEBCx0HJwsUCQgCBAESCAGICMMnF45BCwEBHi0KAQaDHYETBJ8DjhY/gXE5 Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 02 Jan 2014 20:30:28 +0000 Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by SEAECAS04.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Thu, 2 Jan 2014 12:30:28 -0800 From: Mark Lloyd To: Alejandro Popovsky , Joe Touch , "tcpm@ietf.org" Thread-Topic: [tcpm] end of burst, delayed acks, and push flag Thread-Index: AQHPAA1vZGK/TnAIP0y4eGuxr+zxJZpiq6sAgAqpVFCABRZxAP//hEUg Date: Thu, 2 Jan 2014 20:30:27 +0000 Message-ID: <2A08B7ACA17C9F4BAA8D5395DF908D73A30FF8D0@SEAEMBX01.olympus.F5Net.com> References: <52B8829B.9050308@palermo.edu> <52B88AF6.5010808@isi.edu> <2A08B7ACA17C9F4BAA8D5395DF908D73A30FE932@SEAEMBX01.olympus.F5Net.com> <52C5C10E.7030703@palermo.edu> In-Reply-To: <52C5C10E.7030703@palermo.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.236] Content-Type: multipart/alternative; boundary="_000_2A08B7ACA17C9F4BAA8D5395DF908D73A30FF8D0SEAEMBX01olympu_" MIME-Version: 1.0 Subject: Re: [tcpm] end of burst, delayed acks, and push flag X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 20:30:39 -0000 --_000_2A08B7ACA17C9F4BAA8D5395DF908D73A30FF8D0SEAEMBX01olympu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIN_RTO is worth revisiting IMHO. The 1 second RFC mandate is largely ign= ored, but implementations seem afraid to go just go all the way to an RTO b= ased on SRTT. A thorough examination and revision could provide substantial= benefits to users. From: Alejandro Popovsky [mailto:apopov@palermo.edu] Sent: Thursday, January 02, 2014 11:42 AM To: Mark Lloyd; Joe Touch; tcpm@ietf.org Subject: Re: [tcpm] end of burst, delayed acks, and push flag As Joe mentioned, disabling the ack delay at the end of bursts, would make the senders grow the congestion window faster (when not in congestion avoidance). On the other side, one of the causes for spurious timeouts is the delay ack at the end of a burst, as Jerry Chu mentioned in the minimum RTO discussion= , so it might be beneficial to reduce them. Some have proposed a sender modification to use an adaptive minimum RTO to handle the delayed acks at the end of bursts. Considering all these, may be a receiver modification based on push flags could lower the spurious timeouts if used only for bursts longer than a min= imum? Alejandro. On 30/12/2013 07:24 p.m., Mark Lloyd wrote: Is the RFC mandated super high Min-RTO time in play here? -----Original Message----- From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Joe Touch Sent: Monday, December 23, 2013 11:12 AM To: Alejandro Popovsky; tcpm@ietf.org Subject: Re: [tcpm] end of burst, delayed acks, and push flag On 12/23/2013 10:36 AM, Alejandro Popovsky wrote: The delayed ack generation may bother when applied to the last segment of a burst. That's not clear at all - see below. There is no 'end of burst indication' from regular senders, i.e. senders with no tail probing (TLP), nor end of burst reordering (Scheffeneg= ger). But on many implementations, the operating system sets the push flag when sending the last byte of a write(...) function call. So push flag helps to identify the end of a burst. It might want to set the PUSH flag on the last write in a sequence of write() calls in a burst, but the PUSH flag applies to the last write() cal= l, not to a byte within the write(). So a way to prevent the problem, could be to disable the ack delay for a/'/push' data segment coming after at least one 'non-push' data segment. First, let's assume Nagle is off, as it should be for bursty traffic. One side (named 'Alba') sends bursts packets to the other (named 'Nisar'). Let's further assume that the burst is an odd number of packets (if it's ev= en, then delayed ACK will work fine). Alba sends 1 packet to Nisar (this is the degenerate case; if it works for = 1, it'll work for larger numbers). Nisar waits to ACK. One of three things happens next: - a timeout (500 ms later), when Nisar sends the ACK for the burst - Nisar has something to send to Alba, at which point Nisar will include the most recent ACK anyway (AFAICT) - Alba has something to send to Nisar, at which point she will send the first packet of it (because the window is always at least 3 packets) at which point Nisar will ACK the last burst and the new packet I.e., the only way this stalls is when Alba's window is smaller than 1 pack= et. Otherwise, not getting the ACK of the last bursts costs Alba at most on= e packet of capacity during the first round-trip of the next burst. I'm not sure that PUSH is the right way to fix this; just because it's the = end of a burst doesn't mean there won't be another burst in much less than = 500 ms, and using PUSH the way you describe could cause bursty sources to c= ircumvent delayed ACK, in which case their window would grow faster than th= ose that use delayed ACK today. I don't see how that's worth one packet. Joe Best regards, Alejandro. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --_000_2A08B7ACA17C9F4BAA8D5395DF908D73A30FF8D0SEAEMBX01olympu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MIN_RTO is worth revisiting IMHO.  The &nb= sp;1 second RFC mandate is largely ignored, but implementations seem afraid to go just go all the way to an RTO based on SRTT. A thorough exami= nation and revision could provide substantial benefits to users.

 

 

From: Alejandro Popovsky [mailto:apopov@palermo.edu]
Sent: Thursday, January 02, 2014 11:42 AM
To: Mark Lloyd; Joe Touch; tcpm@ietf.org
Subject: Re: [tcpm] end of burst, delayed acks, and push flag

 

As Joe mentioned, disabling the ack delay at the end= of bursts, would
make the senders grow the congestion window faster (when not in
congestion avoidance).

On the other side, one of the causes for spurious timeouts is the delay ack=
at the end of a burst, as Jerry Chu mentioned in the minimum RTO discussion,
so it might be beneficial to reduce them. Some have proposed a
sender modification to use an adaptive minimum RTO to handle the
delayed acks at the end of bursts.

Considering all these, may be a receiver modification based on push flags could lower the spurious timeouts if used only for bursts longer than a min= imum?

Alejandro.



On 30/12/2013 07:24 p.m., Mark Lloyd wrote:

Is the RFC mandated super high Min-RTO time in play here? <=
/pre>

 


-----Original Message-----


From: tcpm [mailto:tcpm-bounc=
es@ietf.org] On Behalf Of Joe Touch


Sent: Monday, December 23, 2013 11:12 AM


To: Alejandro Popovsky; tcpm@ietf.org=



Subject: Re: [tcpm] end of burst, delayed acks, and push flag


 


 


 


On 12/23/2013 10:36 AM, Alejandro Popovsky wrote:




The delayed ack generation may bother when applied to the last segment=
 


of a burst.




 


That's not clear at all - see below.


 




There is no 'end of burst indication' from regular senders, i.e. =



senders with no tail probing (TLP), nor end of burst reordering (Schef=
fenegger).


 


But on many implementations, the operating system sets the push flag <=
o:p>


when sending the last byte of a write(...) function call. So push flag=
 


helps to identify the end of a burst.




 


It might want to set the PUSH flag on the last write in a sequence of<=
o:p>


write() calls in a burst, but the PUSH flag applies to the last write(=
) call, not to a byte within the write().


 




So a way to prevent the problem, could be to disable the ack delay for=
 


a/'/push' data segment coming after at least one 'non-push' data =



segment.




 


First, let's assume Nagle is off, as it should be for bursty traffic.<=
o:p>


 


One side (named 'Alba') sends bursts packets to the other (named 'Nisa=
r').


 


Let's further assume that the burst is an odd number of packets (if it=
's even, then delayed ACK will work fine).


 


Alba sends 1 packet to Nisar (this is the degenerate case; if it works=
 for 1, it'll work for larger numbers).


 


Nisar waits to ACK.


 


One of three things happens next:


 


  - a timeout (500 ms later), when Nisar sends the ACK=



  for the burst


 


  - Nisar has something to send to Alba, at which point


  Nisar will include the most recent ACK anyway (AFAICT)


 


  - Alba has something to send to Nisar, at which point she<=
/o:p>


  will send the first packet of it (because the window is


  always at least 3 packets)


 


         at which point Nisar =
will ACK the last burst


         and the new packet


 


I.e., the only way this stalls is when Alba's window is smaller than 1=
 packet. Otherwise, not getting the ACK of the last bursts costs Alba at mo=
st one packet of capacity during the first round-trip of the next burst.


 


I'm not sure that PUSH is the right way to fix this; just because it's=
 the end of a burst doesn't mean there won't be another burst in much less =
than 500 ms, and using PUSH the way you describe could cause bursty sources=
 to circumvent delayed ACK, in which case their window would grow faster th=
an those that use delayed ACK today.


 


I don't see how that's worth one packet.


 


Joe


 




Best regards, Alejandro.


 


 


 


 


_______________________________________________


tcpm mailing list


tcpm@ietf.org


https://www.iet=
f.org/mailman/listinfo/tcpm


 




_______________________________________________


tcpm mailing list


tcpm@ietf.org


https://www.iet=
f.org/mailman/listinfo/tcpm

 

--_000_2A08B7ACA17C9F4BAA8D5395DF908D73A30FF8D0SEAEMBX01olympu_-- From touch@isi.edu Thu Jan 2 12:57:06 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E62A1A1F63 for ; Thu, 2 Jan 2014 12:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538] 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 fOFaCacDfYot for ; Thu, 2 Jan 2014 12:57:04 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3471A1F5F for ; Thu, 2 Jan 2014 12:57:04 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s02KuULU020659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Jan 2014 12:56:30 -0800 (PST) Message-ID: <52C5D27E.4050205@isi.edu> Date: Thu, 02 Jan 2014 12:56:30 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Alejandro Popovsky , Mark Lloyd , "tcpm@ietf.org" References: <52B8829B.9050308@palermo.edu> <52B88AF6.5010808@isi.edu> <2A08B7ACA17C9F4BAA8D5395DF908D73A30FE932@SEAEMBX01.olympus.F5Net.com> <52C5C10E.7030703@palermo.edu> In-Reply-To: <52C5C10E.7030703@palermo.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [tcpm] end of burst, delayed acks, and push flag X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 20:57:06 -0000 As I noted, the benefit is one packet per burst. And you have to assume that the push flag isn't already being used for other purposes. IMO, this isn't worth the complexity. Joe On 1/2/2014 11:42 AM, Alejandro Popovsky wrote: > As Joe mentioned, disabling the ack delay at the end of bursts, would > make the senders grow the congestion window faster (when not in > congestion avoidance). > > On the other side, one of the causes for spurious timeouts is the delay ack > at the end of a burst, as Jerry Chu mentioned in the minimum RTO > discussion > , > so it might be beneficial to reduce them. Some have proposed a > sender modification > to > use an adaptive minimum RTO to handle the > delayed acks at the end of bursts. > > Considering all these, may be a receiver modification based on push flags > could lower the spurious timeouts if used only for bursts longer than a > minimum? > > Alejandro. > > > > On 30/12/2013 07:24 p.m., Mark Lloyd wrote: >> Is the RFC mandated super high Min-RTO time in play here? >> >> -----Original Message----- >> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Joe Touch >> Sent: Monday, December 23, 2013 11:12 AM >> To: Alejandro Popovsky;tcpm@ietf.org >> Subject: Re: [tcpm] end of burst, delayed acks, and push flag >> >> >> >> On 12/23/2013 10:36 AM, Alejandro Popovsky wrote: >>> The delayed ack generation may bother when applied to the last segment >>> of a burst. >> That's not clear at all - see below. >> >>> There is no 'end of burst indication' from regular senders, i.e. >>> senders with no tail probing (TLP), nor end of burst reordering (Scheffenegger). >>> >>> But on many implementations, the operating system sets the push flag >>> when sending the last byte of a write(...) function call. So push flag >>> helps to identify the end of a burst. >> It might want to set the PUSH flag on the last write in a sequence of >> write() calls in a burst, but the PUSH flag applies to the last write() call, not to a byte within the write(). >> >>> So a way to prevent the problem, could be to disable the ack delay for >>> a/'/push' data segment coming after at least one 'non-push' data >>> segment. >> First, let's assume Nagle is off, as it should be for bursty traffic. >> >> One side (named 'Alba') sends bursts packets to the other (named 'Nisar'). >> >> Let's further assume that the burst is an odd number of packets (if it's even, then delayed ACK will work fine). >> >> Alba sends 1 packet to Nisar (this is the degenerate case; if it works for 1, it'll work for larger numbers). >> >> Nisar waits to ACK. >> >> One of three things happens next: >> >> - a timeout (500 ms later), when Nisar sends the ACK >> for the burst >> >> - Nisar has something to send to Alba, at which point >> Nisar will include the most recent ACK anyway (AFAICT) >> >> - Alba has something to send to Nisar, at which point she >> will send the first packet of it (because the window is >> always at least 3 packets) >> >> at which point Nisar will ACK the last burst >> and the new packet >> >> I.e., the only way this stalls is when Alba's window is smaller than 1 packet. Otherwise, not getting the ACK of the last bursts costs Alba at most one packet of capacity during the first round-trip of the next burst. >> >> I'm not sure that PUSH is the right way to fix this; just because it's the end of a burst doesn't mean there won't be another burst in much less than 500 ms, and using PUSH the way you describe could cause bursty sources to circumvent delayed ACK, in which case their window would grow faster than those that use delayed ACK today. >> >> I don't see how that's worth one packet. >> >> Joe >> >>> Best regards, Alejandro. >>> >>> >>> >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > From brandon.williams@akamai.com Fri Jan 10 08:35:52 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA6441AE0DE for ; Fri, 10 Jan 2014 08:35:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538] 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 xaxjsI-rkp5a for ; Fri, 10 Jan 2014 08:35:49 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id D8C921AE11D for ; Fri, 10 Jan 2014 08:35:49 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D5261284CA for ; Fri, 10 Jan 2014 16:35:39 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id C31BA284C8 for ; Fri, 10 Jan 2014 16:35:39 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 8C6D8202A for ; Fri, 10 Jan 2014 16:35:39 +0000 (GMT) Message-ID: <52D0215B.6050101@akamai.com> Date: Fri, 10 Jan 2014 11:35:39 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "tcpm@ietf.org" References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> In-Reply-To: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [tcpm] Fwd: New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 16:35:52 -0000 -------- Original Message -------- Subject: New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt Date: Fri, 10 Jan 2014 11:29:11 -0500 From: internet-drafts@ietf.org To: Williams, Brandon , Dan Wing , Mohamed Boucadair A new version of I-D, draft-williams-exp-tcp-host-id-opt-00.txt has been successfully submitted by Brandon Williams and posted to the IETF repository. Name: draft-williams-exp-tcp-host-id-opt Revision: 00 Title: Experimental Option for TCP Host Identification Document date: 2014-01-10 Group: Individual Submission Pages: 8 URL: http://www.ietf.org/internet-drafts/draft-williams-exp-tcp-host-id-opt-00.txt Status: https://datatracker.ietf.org/doc/draft-williams-exp-tcp-host-id-opt/ Htmlized: http://tools.ietf.org/html/draft-williams-exp-tcp-host-id-opt-00 Abstract: Recent IETF proposals have identified benefits to more distinctly identifying the hosts that are hidden behind a shared address/prefix sharing device or application-layer proxy. Analysis indicates that the use of a TCP option for this purpose can be successfully applied to a broad range of use cases. This document describes a common experimental TCP option format for host identification. 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. The IETF Secretariat From michael.scharf@alcatel-lucent.com Tue Jan 14 04:11:57 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 911221AE04D for ; Tue, 14 Jan 2014 04:11:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 dDTj8h34J2Lw for ; Tue, 14 Jan 2014 04:11:55 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9261ADED5 for ; Tue, 14 Jan 2014 04:11:55 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s0ECBdd2004923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Jan 2014 06:11:40 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s0ECBc01007822 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Jan 2014 13:11:38 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.112]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 14 Jan 2014 13:11:38 +0100 From: "Scharf, Michael (Michael)" To: Brandon Williams Thread-Topic: [tcpm] Fwd: New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt Thread-Index: AQHPDiIR5zP4HirH2E6x3q9neHzQ7pqEJIQQ Date: Tue, 14 Jan 2014 12:11:37 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> In-Reply-To: <52D0215B.6050101@akamai.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 12:11:57 -0000 Hi Brandon, Thanks for this heads up. One specific question related to the IANA section= : This document specifies a new TCP option that uses the shared experimental options format [RFC6994], with ExID=3D0x0348 (840) in network-standard byte order. This ExID has already been registered with IANA. However, I don't find that ExID in the IANA registry so far. Has this ExID = indeed been registered? During publication of RFC 6994, I've been told that IANA would process such= requests fast - and this is why I am curious whether this is true. Apart from that, do the authors have any plans how to proceed? Given the dr= aft name, I assume that you don't plan to ask for WG adoption in TCPM, righ= t? Thanks Michael > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Brandon Williams > Sent: Friday, January 10, 2014 5:36 PM > To: tcpm@ietf.org > Subject: [tcpm] Fwd: New Version Notification for draft-williams-exp- > tcp-host-id-opt-00.txt >=20 > -------- Original Message -------- > Subject: New Version Notification for > draft-williams-exp-tcp-host-id-opt-00.txt > Date: Fri, 10 Jan 2014 11:29:11 -0500 > From: internet-drafts@ietf.org > To: Williams, Brandon , Dan Wing > , Mohamed Boucadair >=20 >=20 > A new version of I-D, draft-williams-exp-tcp-host-id-opt-00.txt > has been successfully submitted by Brandon Williams and posted to the > IETF repository. >=20 > Name: draft-williams-exp-tcp-host-id-opt > Revision: 00 > Title: Experimental Option for TCP Host Identification > Document date: 2014-01-10 > Group: Individual Submission > Pages: 8 > URL: > http://www.ietf.org/internet-drafts/draft-williams-exp-tcp-host-id-opt- > 00.txt > Status: > https://datatracker.ietf.org/doc/draft-williams-exp-tcp-host-id-opt/ > Htmlized: > http://tools.ietf.org/html/draft-williams-exp-tcp-host-id-opt-00 >=20 >=20 > Abstract: > Recent IETF proposals have identified benefits to more distinctly > identifying the hosts that are hidden behind a shared > address/prefix > sharing device or application-layer proxy. Analysis indicates that > the use of a TCP option for this purpose can be successfully > applied > to a broad range of use cases. This document describes a common > experimental TCP option format for host identification. >=20 >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From mohamed.boucadair@orange.com Tue Jan 14 05:40:51 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0651F1AE0E4 for ; Tue, 14 Jan 2014 05:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 koErSzUuyB7L for ; Tue, 14 Jan 2014 05:40:49 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id C98D41AE0D6 for ; Tue, 14 Jan 2014 05:40:48 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 90A03324019; Tue, 14 Jan 2014 14:40:36 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 72E694C015; Tue, 14 Jan 2014 14:40:36 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Tue, 14 Jan 2014 14:40:36 +0100 From: To: "Scharf, Michael (Michael)" , Brandon Williams Date: Tue, 14 Jan 2014 14:40:34 +0100 Thread-Topic: [tcpm] Fwd: New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt Thread-Index: AQHPDiIR5zP4HirH2E6x3q9neHzQ7pqEJIQQgAAXBNA= Message-ID: <94C682931C08B048B7A8645303FDC9F36F45EC3EBF@PUEXCB1B.nanterre.francetelecom.fr> References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.14.55715 Cc: "tcpm@ietf.org" , "Dan Wing \(dwing@cisco.com\)" Subject: Re: [tcpm] Fwd: New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 13:40:51 -0000 Dear Michael, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de Scharf, Michael >(Michael) >Envoy=E9=A0: mardi 14 janvier 2014 13:12 >=C0=A0: Brandon Williams >Cc=A0: tcpm@ietf.org >Objet=A0: Re: [tcpm] Fwd: New Version Notification for draft-williams-exp- >tcp-host-id-opt-00.txt > >Hi Brandon, > >Thanks for this heads up. One specific question related to the IANA >section: > > This document specifies a new TCP option that uses the shared > experimental options format [RFC6994], with ExID=3D0x0348 (840) in > network-standard byte order. This ExID has already been registered > with IANA. > >However, I don't find that ExID in the IANA registry so far. Has this ExID >indeed been registered? [Med] It is registered. Please see: http://www.iana.org/assignments/tcp-par= ameters/tcp-parameters.txt=20 Value Description = Reference 0x0348 Host ID [draft-willi= ams-exp-tcp-host-id-opt] > >During publication of RFC 6994, I've been told that IANA would process suc= h >requests fast - and this is why I am curious whether this is true. > >Apart from that, do the authors have any plans how to proceed? [Med] We would like to see this experimental option published as an RFC. If= tcpm accepts to take this work, this would work for us.=20 Given the >draft name, I assume that you don't plan to ask for WG adoption in TCPM, >right? [Med] We would appreciate if a call for adoption is issued in tcpm. Thanks.= =20 > >Thanks > >Michael > > >> -----Original Message----- >> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Brandon Williams >> Sent: Friday, January 10, 2014 5:36 PM >> To: tcpm@ietf.org >> Subject: [tcpm] Fwd: New Version Notification for draft-williams-exp- >> tcp-host-id-opt-00.txt >> >> -------- Original Message -------- >> Subject: New Version Notification for >> draft-williams-exp-tcp-host-id-opt-00.txt >> Date: Fri, 10 Jan 2014 11:29:11 -0500 >> From: internet-drafts@ietf.org >> To: Williams, Brandon , Dan Wing >> , Mohamed Boucadair >> >> >> A new version of I-D, draft-williams-exp-tcp-host-id-opt-00.txt >> has been successfully submitted by Brandon Williams and posted to the >> IETF repository. >> >> Name: draft-williams-exp-tcp-host-id-opt >> Revision: 00 >> Title: Experimental Option for TCP Host Identification >> Document date: 2014-01-10 >> Group: Individual Submission >> Pages: 8 >> URL: >> http://www.ietf.org/internet-drafts/draft-williams-exp-tcp-host-id-opt- >> 00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-williams-exp-tcp-host-id-opt/ >> Htmlized: >> http://tools.ietf.org/html/draft-williams-exp-tcp-host-id-opt-00 >> >> >> Abstract: >> Recent IETF proposals have identified benefits to more distinctly >> identifying the hosts that are hidden behind a shared >> address/prefix >> sharing device or application-layer proxy. Analysis indicates that >> the use of a TCP option for this purpose can be successfully >> applied >> to a broad range of use cases. This document describes a common >> experimental TCP option format for host identification. >> >> >> >> >> >> 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. >> >> The IETF Secretariat >> >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www.ietf.org/mailman/listinfo/tcpm From michael.scharf@alcatel-lucent.com Tue Jan 14 05:55:09 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF811AE0CF for ; Tue, 14 Jan 2014 05:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 dOA6cK1isT-o for ; Tue, 14 Jan 2014 05:55:07 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 189081ADFF8 for ; Tue, 14 Jan 2014 05:55:07 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s0EDsq33014571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Jan 2014 07:54:53 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s0EDspOd027868 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Jan 2014 14:54:51 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.112]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 14 Jan 2014 14:54:51 +0100 From: "Scharf, Michael (Michael)" To: "mohamed.boucadair@orange.com" , "Brandon Williams" Thread-Topic: [tcpm] Fwd: New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt Thread-Index: AQHPES44ydCjfWXrmECen9wuIypYQ5qEO9tQ Date: Tue, 14 Jan 2014 13:54:50 +0000 Message-ID: <655C07320163294895BBADA28372AF5D184423@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <94C682931C08B048B7A8645303FDC9F36F45EC3EBF@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F45EC3EBF@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" , "Dan Wing \(dwing@cisco.com\)" Subject: Re: [tcpm] Fwd: New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 13:55:09 -0000 > >However, I don't find that ExID in the IANA registry so far. Has this > ExID > >indeed been registered? >=20 > [Med] It is registered. Please see: > http://www.iana.org/assignments/tcp-parameters/tcp-parameters.txt >=20 > Value Description > Reference > 0x0348 Host ID [draft- > williams-exp-tcp-host-id-opt] I checked out this site: http://www.iana.org/assignments/tcp-parameters/tcp= -parameters.xhtml Apparently, that site is not up to date. Sorry for my confusion. > >During publication of RFC 6994, I've been told that IANA would process > such > >requests fast - and this is why I am curious whether this is true. > > > >Apart from that, do the authors have any plans how to proceed? >=20 > [Med] We would like to see this experimental option published as an > RFC. If tcpm accepts to take this work, this would work for us. >=20 > Given the > >draft name, I assume that you don't plan to ask for WG adoption in > TCPM, > >right? >=20 > [Med] We would appreciate if a call for adoption is issued in tcpm. Thanks for the information. It is not clear to me whether the overall topic= would be within the current TCPM charter, and IMHO this will require discu= ssion. Anyway, thoughts from the community would be highly appreciated. Michael > Thanks. >=20 > > > >Thanks > > > >Michael > > > > > >> -----Original Message----- > >> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Brandon > Williams > >> Sent: Friday, January 10, 2014 5:36 PM > >> To: tcpm@ietf.org > >> Subject: [tcpm] Fwd: New Version Notification for draft-williams- > exp- > >> tcp-host-id-opt-00.txt > >> > >> -------- Original Message -------- > >> Subject: New Version Notification for > >> draft-williams-exp-tcp-host-id-opt-00.txt > >> Date: Fri, 10 Jan 2014 11:29:11 -0500 > >> From: internet-drafts@ietf.org > >> To: Williams, Brandon , Dan Wing > >> , Mohamed Boucadair > >> > >> > >> A new version of I-D, draft-williams-exp-tcp-host-id-opt-00.txt > >> has been successfully submitted by Brandon Williams and posted to > the > >> IETF repository. > >> > >> Name: draft-williams-exp-tcp-host-id-opt > >> Revision: 00 > >> Title: Experimental Option for TCP Host Identification > >> Document date: 2014-01-10 > >> Group: Individual Submission > >> Pages: 8 > >> URL: > >> http://www.ietf.org/internet-drafts/draft-williams-exp-tcp-host-id- > opt- > >> 00.txt > >> Status: > >> https://datatracker.ietf.org/doc/draft-williams-exp-tcp-host-id-opt/ > >> Htmlized: > >> http://tools.ietf.org/html/draft-williams-exp-tcp-host-id-opt-00 > >> > >> > >> Abstract: > >> Recent IETF proposals have identified benefits to more > distinctly > >> identifying the hosts that are hidden behind a shared > >> address/prefix > >> sharing device or application-layer proxy. Analysis indicates > that > >> the use of a TCP option for this purpose can be successfully > >> applied > >> to a broad range of use cases. This document describes a common > >> experimental TCP option format for host identification. > >> > >> > >> > >> > >> > >> 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. > >> > >> The IETF Secretariat > >> > >> > >> > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcpm > >_______________________________________________ > >tcpm mailing list > >tcpm@ietf.org > >https://www.ietf.org/mailman/listinfo/tcpm From wes@mti-systems.com Tue Jan 14 05:55:21 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4C21AE0E4 for ; Tue, 14 Jan 2014 05:55:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 IYSFzA9Cp1pq for ; Tue, 14 Jan 2014 05:55:19 -0800 (PST) Received: from atl4mhob11.myregisteredsite.com (atl4mhob11.myregisteredsite.com [209.17.115.49]) by ietfa.amsl.com (Postfix) with ESMTP id 4261D1AE0E2 for ; Tue, 14 Jan 2014 05:55:19 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.206]) by atl4mhob11.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s0EDt6GW009990 for ; Tue, 14 Jan 2014 08:55:06 -0500 Received: (qmail 28429 invoked by uid 0); 14 Jan 2014 13:55:06 -0000 X-TCPREMOTEIP: 108.98.44.187 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@108.98.44.187) by 0 with ESMTPA; 14 Jan 2014 13:55:05 -0000 Message-ID: <52D541B3.7000606@mti-systems.com> Date: Tue, 14 Jan 2014 08:54:59 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" , Brandon Williams References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 13:55:21 -0000 On 1/14/2014 7:11 AM, Scharf, Michael (Michael) wrote: > > Apart from that, do the authors have any plans how to proceed? Given the draft name, I assume that you don't plan to ask for WG adoption in TCPM, right? > I think we should not proceed at all on this. Intermediate devices shouldn't play with TCP options. My guess is that there may even be strong consensus on this. -- Wes Eddy MTI Systems From brandon.williams@akamai.com Tue Jan 14 06:43:32 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A2E1ADF7F for ; Tue, 14 Jan 2014 06:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538] 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 zecdQK5xBy_5 for ; Tue, 14 Jan 2014 06:43:31 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 643A21AC82B for ; Tue, 14 Jan 2014 06:43:31 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id F2797284E8; Tue, 14 Jan 2014 14:43:19 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id DDE8A284C8; Tue, 14 Jan 2014 14:43:19 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id B61BA2029; Tue, 14 Jan 2014 14:43:19 +0000 (GMT) Message-ID: <52D54D07.8070907@akamai.com> Date: Tue, 14 Jan 2014 09:43:19 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Wesley Eddy , "Scharf, Michael (Michael)" References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52D541B3.7000606@mti-systems.com> In-Reply-To: <52D541B3.7000606@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 14:43:32 -0000 Hi Wes, I think you may be making assumptions about the nature of the intermediate devices. While there are some use cases where the option would be inserted into packets as they traverse an intermediate device, there are also cases where the TCP connections on both sides of the device are distinct (i.e. the intermediate device is the endpoint for both connections). An application proxy would be one common example of the later. If I've misunderstood your objection, please provide further elaboration. Thanks, --Brandon On 01/14/2014 08:54 AM, Wesley Eddy wrote: > On 1/14/2014 7:11 AM, Scharf, Michael (Michael) wrote: >> >> Apart from that, do the authors have any plans how to proceed? Given the draft name, I assume that you don't plan to ask for WG adoption in TCPM, right? >> > > > I think we should not proceed at all on this. > > Intermediate devices shouldn't play with TCP options. > > My guess is that there may even be strong consensus on this. > > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From wes@mti-systems.com Tue Jan 14 07:09:06 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C19F91A1F3F for ; Tue, 14 Jan 2014 07:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 t8CKh18KqSXt for ; Tue, 14 Jan 2014 07:09:05 -0800 (PST) Received: from atl4mhob03.myregisteredsite.com (atl4mhob03.myregisteredsite.com [209.17.115.41]) by ietfa.amsl.com (Postfix) with ESMTP id F37501AE08B for ; Tue, 14 Jan 2014 07:09:04 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.204]) by atl4mhob03.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s0EF8p4l017450 for ; Tue, 14 Jan 2014 10:08:51 -0500 Received: (qmail 14947 invoked by uid 0); 14 Jan 2014 15:08:51 -0000 X-TCPREMOTEIP: 108.98.44.187 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@108.98.44.187) by 0 with ESMTPA; 14 Jan 2014 15:08:51 -0000 Message-ID: <52D552FD.2070909@mti-systems.com> Date: Tue, 14 Jan 2014 10:08:45 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Brandon Williams , "Scharf, Michael (Michael)" References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52D541B3.7000606@mti-systems.com> <52D54D07.8070907@akamai.com> In-Reply-To: <52D54D07.8070907@akamai.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 15:09:07 -0000 On 1/14/2014 9:43 AM, Brandon Williams wrote: > Hi Wes, > > I think you may be making assumptions about the nature of the > intermediate devices. While there are some use cases where the option > would be inserted into packets as they traverse an intermediate device, > there are also cases where the TCP connections on both sides of the > device are distinct (i.e. the intermediate device is the endpoint for > both connections). An application proxy would be one common example of > the later. > > If I've misunderstood your objection, please provide further elaboration. > Hi Brandon, I think your understand it. If the use-cases are divided into: 1) use by application proxies that terminate the TCP connections 2) use by invisible middleboxes that tamper with TCP flows that path through them Then, number 2 is what I think there should be no support or encouragement for at the moment. In my opinion, it would seem that enhanced signalling for number 1 is better done at the application layer, and that it's awkward to do via TCP, since it would require application changes anyways to set and make use of the information (i.e. it's not a part of the socket API). So, while I wouldn't feel strongly against number 1, it's just not good architecture. -- Wes Eddy MTI Systems From lars@netapp.com Tue Jan 14 07:34:51 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBDD1AE0EA for ; Tue, 14 Jan 2014 07:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-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 NOMzDkw1Fw9v for ; Tue, 14 Jan 2014 07:34:49 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id BB7551AE09C for ; Tue, 14 Jan 2014 07:34:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,658,1384329600"; d="asc'?scan'208";a="95979308" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx11-out.netapp.com with ESMTP; 14 Jan 2014 07:34:38 -0800 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Tue, 14 Jan 2014 07:34:38 -0800 From: "Eggert, Lars" To: Wesley Eddy Thread-Topic: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt Thread-Index: AQHPET4imRfdQ7VzKUWouncVWOAxUw== Date: Tue, 14 Jan 2014 15:34:37 +0000 Message-ID: <98531DC4-272A-4110-A676-8613521E3FB7@netapp.com> References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52D541B3.7000606@mti-systems.com> In-Reply-To: <52D541B3.7000606@mti-systems.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_C41C1C2F-1B37-4E4C-A17B-E8745F46A9C1"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 15:34:51 -0000 --Apple-Mail=_C41C1C2F-1B37-4E4C-A17B-E8745F46A9C1 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 2014-1-14, at 14:54, Wesley Eddy wrote: > I think we should not proceed at all on this. > Intermediate devices shouldn't play with TCP options. > My guess is that there may even be strong consensus on this. Fully agreed. Lars --Apple-Mail=_C41C1C2F-1B37-4E4C-A17B-E8745F46A9C1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBUtVZCtZcnpRveo1xAQJ9TwP+IHQdQN/CUP4ZPsUqrSCud6VUJv9Pwo0H +MxL192NSRx4iMUh8ayeUhw4/bFITmnX/m74BAGMQ2W0f/mufKu0hPJmmTKP+f71 ffpQFWLquBwBZ8lfsuKyMlN9VKJGfPDZLnAVmAJO711cIh0nJXXzLx3U0SEgmTCn EMRJQXHRU8g= =kuSB -----END PGP SIGNATURE----- --Apple-Mail=_C41C1C2F-1B37-4E4C-A17B-E8745F46A9C1-- From touch@isi.edu Tue Jan 14 14:47:14 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93D21AE1DA for ; Tue, 14 Jan 2014 14:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538] 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 eTS4WRoXEZ1Q for ; Tue, 14 Jan 2014 14:47:13 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id EEADC1AE1BB for ; Tue, 14 Jan 2014 14:47:12 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s0EMkHHf012129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 14 Jan 2014 14:46:17 -0800 (PST) Message-ID: <52D5BE3B.2050608@isi.edu> Date: Tue, 14 Jan 2014 14:46:19 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" , "mohamed.boucadair@orange.com" , Brandon Williams References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <94C682931C08B048B7A8645303FDC9F36F45EC3EBF@PUEXCB1B.nanterre.francetelecom.fr> <655C07320163294895BBADA28372AF5D184423@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D184423@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" , "Dan Wing \(dwing@cisco.com\)" Subject: Re: [tcpm] Fwd: New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 22:47:15 -0000 On 1/14/2014 5:54 AM, Scharf, Michael (Michael) wrote: >>> However, I don't find that ExID in the IANA registry so far. Has this >> ExID >>> indeed been registered? >> >> [Med] It is registered. Please see: >> http://www.iana.org/assignments/tcp-parameters/tcp-parameters.txt >> >> Value Description >> Reference >> 0x0348 Host ID [draft- >> williams-exp-tcp-host-id-opt] > > I checked out this site: http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml > > Apparently, that site is not up to date. Sorry for my confusion. It was correct when I looked at both URLs. Joe From touch@isi.edu Tue Jan 14 14:57:40 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9648D1AE2D0 for ; Tue, 14 Jan 2014 14:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538] 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 9FMQoQRZlCOE for ; Tue, 14 Jan 2014 14:57:39 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 340C81AE2AB for ; Tue, 14 Jan 2014 14:57:39 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s0EMugFw013723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 14 Jan 2014 14:56:42 -0800 (PST) Message-ID: <52D5C0AC.4080604@isi.edu> Date: Tue, 14 Jan 2014 14:56:44 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Eggert, Lars" , Wesley Eddy References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52D541B3.7000606@mti-systems.com> <98531DC4-272A-4110-A676-8613521E3FB7@netapp.com> In-Reply-To: <98531DC4-272A-4110-A676-8613521E3FB7@netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 22:57:40 -0000 On 1/14/2014 7:34 AM, Eggert, Lars wrote: > On 2014-1-14, at 14:54, Wesley Eddy wrote: >> I think we should not proceed at all on this. >> Intermediate devices shouldn't play with TCP options. >> My guess is that there may even be strong consensus on this. > > Fully agreed. > > Lars I'm confused about the concern. Although I completely agree that intermediate devices shouldn't play with TCP options, they already DO play with TCP fields that they shouldn't - e.g., NATs change IP source address and port numbers. AFAICT, this document's intent in using intermediate devices is to have the NAT preserve some variant/derivative of the origin IP address/port info, i.e., so the receiving system can (if it wants) determine the difference between different origin hosts vs. different connections from the same origin host, even when all are behind a NAT. I agree it's ugly, but it seems that having NATs is what creates the ugliness. NATs need to do one of two things, and neither one is architecturally more corrrect: 1. enforce the notion that they are the single address for all hosts behind them 2. allow different hosts behind them to be exposed as such So while I agree that a generic intermediate device should NEVER do this, IMO a NAT doing this is different - it's more like cleaning up a problem it creates, vs. making things worse. My conclusion is that ONLY devices that change IP source addresses and/or ports MAY do this (and only devices that add the option should ever remove it, e.g. in the reverse direction), but other intermediate devices MUST NOT change these values. I don't agree that this is either an elegant, appropriate, or necessary solution. But it's not 'evil' for the reasons presented thus far. There are other issues, e.g., TCP-AO includes an experimental NAT variant that this is incompatible with, but we can discuss those if this becomes a WG doc. Joe PS - IMO, this document misrepresents the contents of RFC6967 in its intro: [RFC6967] provides analysis of various solutions to the problem of revealing the sending hosts's identifier (HOST_ID) information to the receiver, which indicates that a solution using a TCP [RFC0793] option for this purpose can be successfully applied to a broad range of use cases with limited performance impact. RFC6967 never says that the TCP solution can be successful in the way claimed; in fact, it lists a large number of issues with a TCP solution. RFC6967 didn't recommend a solution: This document analyzes a set of potential solutions for revealing a host identifier and does not recommend a particular solution, although it does highlight the hazards of some approaches. From michael.scharf@alcatel-lucent.com Wed Jan 15 00:25:50 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00BB71A8032 for ; Wed, 15 Jan 2014 00:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 ADiDCjMvpZdx for ; Wed, 15 Jan 2014 00:25:47 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id D8F861AE1EC for ; Wed, 15 Jan 2014 00:25:46 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s0F8PWl2027116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 Jan 2014 02:25:33 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s0F8PVVJ024062 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Jan 2014 09:25:32 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.112]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 15 Jan 2014 09:25:31 +0100 From: "Scharf, Michael (Michael)" To: Joe Touch , "mohamed.boucadair@orange.com" , Brandon Williams Thread-Topic: [tcpm] Fwd: New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt Thread-Index: AQHPES44ydCjfWXrmECen9wuIypYQ5qEO9tQgACF5oCAALIHIA== Date: Wed, 15 Jan 2014 08:25:30 +0000 Message-ID: <655C07320163294895BBADA28372AF5D187070@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <94C682931C08B048B7A8645303FDC9F36F45EC3EBF@PUEXCB1B.nanterre.francetelecom.fr> <655C07320163294895BBADA28372AF5D184423@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52D5BE3B.2050608@isi.edu> In-Reply-To: <52D5BE3B.2050608@isi.edu> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" , "Dan Wing \(dwing@cisco.com\)" Subject: Re: [tcpm] Fwd: New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 08:25:50 -0000 > On 1/14/2014 5:54 AM, Scharf, Michael (Michael) wrote: > >>> However, I don't find that ExID in the IANA registry so far. Has > this > >> ExID > >>> indeed been registered? > >> > >> [Med] It is registered. Please see: > >> http://www.iana.org/assignments/tcp-parameters/tcp-parameters.txt > >> > >> Value Description > >> Reference > >> 0x0348 Host ID > [draft- > >> williams-exp-tcp-host-id-opt] > > > > I checked out this site: http://www.iana.org/assignments/tcp- > parameters/tcp-parameters.xhtml > > > > Apparently, that site is not up to date. Sorry for my confusion. >=20 > It was correct when I looked at both URLs. Indeed, I checked the xhtml site several times yesterday and it was finally= updated in the late evening. Michael From mohamed.boucadair@orange.com Wed Jan 15 05:06:38 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B121AE20F for ; Wed, 15 Jan 2014 05:06:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 k3XT3PBxAfHX for ; Wed, 15 Jan 2014 05:06:37 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id B30171AE1CF for ; Wed, 15 Jan 2014 05:06:36 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 09E8418C33D; Wed, 15 Jan 2014 14:06:24 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id DE3BA35C058; Wed, 15 Jan 2014 14:06:23 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Wed, 15 Jan 2014 14:06:23 +0100 From: To: Wesley Eddy , Brandon Williams , "Scharf, Michael (Michael)" Date: Wed, 15 Jan 2014 14:06:22 +0100 Thread-Topic: [tcpm] Fwd: New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt Thread-Index: Ac8ROo4kdqoXRBQGTjCZ2tkGpL9uIgAtmV7g Message-ID: <94C682931C08B048B7A8645303FDC9F36F45EC4291@PUEXCB1B.nanterre.francetelecom.fr> References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52D541B3.7000606@mti-systems.com> <52D54D07.8070907@akamai.com> <52D552FD.2070909@mti-systems.com> In-Reply-To: <52D552FD.2070909@mti-systems.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.14.224215 Cc: "tcpm@ietf.org" , "Dan Wing \(dwing@cisco.com\)" Subject: Re: [tcpm] Fwd: New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 13:06:38 -0000 Dear Wes,=20 An additional deployment model, in addition to the ones you mentioned, is t= o set the option by the end host or the CPE while the address sharing devic= e in the network would be configured to check the value included in such op= tion. This model is suitable for DS-Lite deployments (RFC6333) where there = is no NAT anymore in the CPE side, but a CGN function in the network side. = An IPv4-in-IPv6 encapsulation scheme is used to between the host/CPE and th= e CGN. The HOST_ID as defined in the draft can be used by the host/CPE to i= nject some bits of the IPv6 address assigned to the CPE, this bits will be = used to distinguish hosts serviced behind the same CGN device. Is there som= ething harmful in this deployment model? Note, that a similar approach would be adopted for A+P schemes (see draft-i= etf-softwire-map) One additional observation: * This option is trying to solve some of the issues raised by NATs. We can = ignore that NATs are there, but this does not solve real problems encounter= ed in operational networks.=20 Cheers, Med >-----Message d'origine----- >De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de Wesley Eddy >Envoy=E9=A0: mardi 14 janvier 2014 16:09 >=C0=A0: Brandon Williams; Scharf, Michael (Michael) >Cc=A0: tcpm@ietf.org >Objet=A0: Re: [tcpm] Fwd: New Version Notification for draft-williams-exp- >tcp-host-id-opt-00.txt > >On 1/14/2014 9:43 AM, Brandon Williams wrote: >> Hi Wes, >> >> I think you may be making assumptions about the nature of the >> intermediate devices. While there are some use cases where the option >> would be inserted into packets as they traverse an intermediate device, >> there are also cases where the TCP connections on both sides of the >> device are distinct (i.e. the intermediate device is the endpoint for >> both connections). An application proxy would be one common example of >> the later. >> >> If I've misunderstood your objection, please provide further elaboration= . >> > > >Hi Brandon, I think your understand it. > >If the use-cases are divided into: > >1) use by application proxies that terminate the TCP connections > >2) use by invisible middleboxes that tamper with TCP flows that > path through them > >Then, number 2 is what I think there should be no support or >encouragement for at the moment. > >In my opinion, it would seem that enhanced signalling for number 1 >is better done at the application layer, and that it's awkward to >do via TCP, since it would require application changes anyways to >set and make use of the information (i.e. it's not a part of the >socket API). So, while I wouldn't feel strongly against number 1, >it's just not good architecture. > >-- >Wes Eddy >MTI Systems >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www.ietf.org/mailman/listinfo/tcpm From brandon.williams@akamai.com Wed Jan 15 07:27:53 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C4F1AE0A0 for ; Wed, 15 Jan 2014 07:27:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 H_jUf1LJNcVB for ; Wed, 15 Jan 2014 07:27:50 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id EFA9E1ADFA9 for ; Wed, 15 Jan 2014 07:27:49 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 05E8047377; Wed, 15 Jan 2014 15:27:38 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id E2A6C47373; Wed, 15 Jan 2014 15:27:37 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id BE9BAFE066; Wed, 15 Jan 2014 15:27:37 +0000 (GMT) Message-ID: <52D6A8E8.6050307@akamai.com> Date: Wed, 15 Jan 2014 10:27:36 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Joe Touch , "Eggert, Lars" , Wesley Eddy References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52D541B3.7000606@mti-systems.com> <98531DC4-272A-4110-A676-8613521E3FB7@netapp.com> <52D5C0AC.4080604@isi.edu> In-Reply-To: <52D5C0AC.4080604@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 15:27:53 -0000 I think you've captured our intent fairly well. This is an attempt to solve a problem introduced by the use of address sharing. We have no illusion that the proposed solution is elegant. There certainly are issues associated with the approach, especially when applied by an in-path NAT device. That said, all potential solutions to this problem set have issues. The purpose of the I.D. is to help us better evaluate this specific proposed solution. Regarding the representation of RFC6967, it was not our intent to indicate that the RFC "recommends" the TCP option over other options, nor to minimize the concerns raised about the approach in that RFC. I do think that "can be successfully applied to a broad range of use cases with limited performance impact" is a fair representation of the tcp option solution analysis in section 5 of RFC6967. All we're really trying to indicate is that the RFC seems to justify continued experimentation in order to better evaluate whether this approach adds enough value to outweigh the shortcomings. We'll attempt to clarify our intent in the next revision. --Brandon On 01/14/2014 05:56 PM, Joe Touch wrote: > > > On 1/14/2014 7:34 AM, Eggert, Lars wrote: >> On 2014-1-14, at 14:54, Wesley Eddy wrote: >>> I think we should not proceed at all on this. >>> Intermediate devices shouldn't play with TCP options. >>> My guess is that there may even be strong consensus on this. >> >> Fully agreed. >> >> Lars > > I'm confused about the concern. > > Although I completely agree that intermediate devices shouldn't play > with TCP options, they already DO play with TCP fields that they > shouldn't - e.g., NATs change IP source address and port numbers. > > AFAICT, this document's intent in using intermediate devices is to have > the NAT preserve some variant/derivative of the origin IP address/port > info, i.e., so the receiving system can (if it wants) determine the > difference between different origin hosts vs. different connections from > the same origin host, even when all are behind a NAT. > > I agree it's ugly, but it seems that having NATs is what creates the > ugliness. NATs need to do one of two things, and neither one is > architecturally more corrrect: > > 1. enforce the notion that they are the single address for > all hosts behind them > > 2. allow different hosts behind them to be exposed as such > > So while I agree that a generic intermediate device should NEVER do > this, IMO a NAT doing this is different - it's more like cleaning up a > problem it creates, vs. making things worse. > > My conclusion is that ONLY devices that change IP source addresses > and/or ports MAY do this (and only devices that add the option should > ever remove it, e.g. in the reverse direction), but other intermediate > devices MUST NOT change these values. > > I don't agree that this is either an elegant, appropriate, or necessary > solution. But it's not 'evil' for the reasons presented thus far. > > There are other issues, e.g., TCP-AO includes an experimental NAT > variant that this is incompatible with, but we can discuss those if this > becomes a WG doc. > > Joe > > PS - IMO, this document misrepresents the contents of RFC6967 in its intro: > > [RFC6967] provides analysis of various solutions to the problem of > revealing the sending hosts's identifier (HOST_ID) information to the > receiver, which indicates that a solution using a TCP [RFC0793] > option for this purpose can be successfully applied to a broad range > of use cases with limited performance impact. > > RFC6967 never says that the TCP solution can be successful in the way > claimed; in fact, it lists a large number of issues with a TCP solution. > > RFC6967 didn't recommend a solution: > > This document analyzes a set of potential solutions for revealing a > host identifier and does not recommend a particular solution, > although it does highlight the hazards of some approaches. > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From michael.scharf@alcatel-lucent.com Wed Jan 15 14:37:48 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5421AE2AF for ; Wed, 15 Jan 2014 14:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 F7ODbzZieTZA for ; Wed, 15 Jan 2014 14:37:46 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 309B01AE2AC for ; Wed, 15 Jan 2014 14:37:45 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s0FMbVme015944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 Jan 2014 16:37:32 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s0FMbUq6016415 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Jan 2014 23:37:31 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.112]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 15 Jan 2014 23:37:30 +0100 From: "Scharf, Michael (Michael)" To: Brandon Williams Thread-Topic: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt Thread-Index: AQHPEXwEeBQtYG7q1EycAOSCPsrL35qF2OcAgACBUI4= Date: Wed, 15 Jan 2014 22:37:30 +0000 Message-ID: <655C07320163294895BBADA28372AF5D18AF3B@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52D541B3.7000606@mti-systems.com> <98531DC4-272A-4110-A676-8613521E3FB7@netapp.com> <52D5C0AC.4080604@isi.edu>,<52D6A8E8.6050307@akamai.com> In-Reply-To: <52D6A8E8.6050307@akamai.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.132.188.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 22:37:49 -0000 Could the authors perhaps provide some additional explanation about this "c= ontinued experimentation" that is apparently planned with draft-williams-ex= p-tcp-host-id-opt? Personally, I do not follow any NAT work in the IETF, an= d this may apply to other TCPM contributors as well. So it seems to me like= a valid question that could facilitate the discussion.=0A= =0A= Regarding the overlay use case, I recall some explanation of draft-williams= -overlaypath-ip-tcp-rfc on this list, but the option format now changed, an= d I wonder whether this change would affect experiments. (Also, enabling in= teroperable implementations in the Internet could require a specification o= f the content, which only draft-williams-overlaypath-ip-tcp-rfc provides.) = =0A= =0A= Other potential use cases are apparently documented e.g. in draft-boucadair= -intarea-host-identifier-scenarios-03, but this draft has expired, and it i= s basically a survey.=0A= =0A= Given that all these topics are outside the typical focus of TCPM, I think = it could be useful to provide some background to this group. Specifically, = I wonder about pointers to running code and details regarding planned use o= f draft-williams-exp-tcp-host-id-opt in real-world experiments.=0A= =0A= Thanks=0A= =0A= Michael=0A= =0A= ________________________________________=0A= Von: tcpm [tcpm-bounces@ietf.org]" im Auftrag von "Brandon Willia= ms [brandon.williams@akamai.com]=0A= Gesendet: Mittwoch, 15. Januar 2014 16:27=0A= An: Joe Touch; Eggert, Lars; Wesley Eddy=0A= Cc: tcpm@ietf.org=0A= Betreff: Re: [tcpm] New Version Notification for draft-williams-exp-= tcp-host-id-opt-00.txt=0A= =0A= I think you've captured our intent fairly well. This is an attempt to=0A= solve a problem introduced by the use of address sharing. We have no=0A= illusion that the proposed solution is elegant. There certainly are=0A= issues associated with the approach, especially when applied by an=0A= in-path NAT device. That said, all potential solutions to this problem=0A= set have issues. The purpose of the I.D. is to help us better evaluate=0A= this specific proposed solution.=0A= =0A= Regarding the representation of RFC6967, it was not our intent to=0A= indicate that the RFC "recommends" the TCP option over other options,=0A= nor to minimize the concerns raised about the approach in that RFC. I do=0A= think that "can be successfully applied to a broad range of use cases=0A= with limited performance impact" is a fair representation of the tcp=0A= option solution analysis in section 5 of RFC6967. All we're really=0A= trying to indicate is that the RFC seems to justify continued=0A= experimentation in order to better evaluate whether this approach adds=0A= enough value to outweigh the shortcomings. We'll attempt to clarify our=0A= intent in the next revision.=0A= =0A= --Brandon=0A= =0A= On 01/14/2014 05:56 PM, Joe Touch wrote:=0A= >=0A= >=0A= > On 1/14/2014 7:34 AM, Eggert, Lars wrote:=0A= >> On 2014-1-14, at 14:54, Wesley Eddy wrote:=0A= >>> I think we should not proceed at all on this.=0A= >>> Intermediate devices shouldn't play with TCP options.=0A= >>> My guess is that there may even be strong consensus on this.=0A= >>=0A= >> Fully agreed.=0A= >>=0A= >> Lars=0A= >=0A= > I'm confused about the concern.=0A= >=0A= > Although I completely agree that intermediate devices shouldn't play=0A= > with TCP options, they already DO play with TCP fields that they=0A= > shouldn't - e.g., NATs change IP source address and port numbers.=0A= >=0A= > AFAICT, this document's intent in using intermediate devices is to have= =0A= > the NAT preserve some variant/derivative of the origin IP address/port=0A= > info, i.e., so the receiving system can (if it wants) determine the=0A= > difference between different origin hosts vs. different connections from= =0A= > the same origin host, even when all are behind a NAT.=0A= >=0A= > I agree it's ugly, but it seems that having NATs is what creates the=0A= > ugliness. NATs need to do one of two things, and neither one is=0A= > architecturally more corrrect:=0A= >=0A= > 1. enforce the notion that they are the single address for=0A= > all hosts behind them=0A= >=0A= > 2. allow different hosts behind them to be exposed as such=0A= >=0A= > So while I agree that a generic intermediate device should NEVER do=0A= > this, IMO a NAT doing this is different - it's more like cleaning up a=0A= > problem it creates, vs. making things worse.=0A= >=0A= > My conclusion is that ONLY devices that change IP source addresses=0A= > and/or ports MAY do this (and only devices that add the option should=0A= > ever remove it, e.g. in the reverse direction), but other intermediate=0A= > devices MUST NOT change these values.=0A= >=0A= > I don't agree that this is either an elegant, appropriate, or necessary= =0A= > solution. But it's not 'evil' for the reasons presented thus far.=0A= >=0A= > There are other issues, e.g., TCP-AO includes an experimental NAT=0A= > variant that this is incompatible with, but we can discuss those if this= =0A= > becomes a WG doc.=0A= >=0A= > Joe=0A= >=0A= > PS - IMO, this document misrepresents the contents of RFC6967 in its intr= o:=0A= >=0A= > [RFC6967] provides analysis of various solutions to the problem of= =0A= > revealing the sending hosts's identifier (HOST_ID) information to th= e=0A= > receiver, which indicates that a solution using a TCP [RFC0793]=0A= > option for this purpose can be successfully applied to a broad range= =0A= > of use cases with limited performance impact.=0A= >=0A= > RFC6967 never says that the TCP solution can be successful in the way=0A= > claimed; in fact, it lists a large number of issues with a TCP solution.= =0A= >=0A= > RFC6967 didn't recommend a solution:=0A= >=0A= > This document analyzes a set of potential solutions for revealing a= =0A= > host identifier and does not recommend a particular solution,=0A= > although it does highlight the hazards of some approaches.=0A= >=0A= >=0A= >=0A= >=0A= > _______________________________________________=0A= > tcpm mailing list=0A= > tcpm@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/tcpm=0A= >=0A= =0A= --=0A= Brandon Williams; Senior Principal Software Engineer=0A= Emerging Products Engineering; Akamai Technologies Inc.=0A= _______________________________________________=0A= tcpm mailing list=0A= tcpm@ietf.org=0A= https://www.ietf.org/mailman/listinfo/tcpm=0A= From touch@isi.edu Fri Jan 17 15:02:33 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237F41AD66E for ; Fri, 17 Jan 2014 15:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 3qbjcqF0uHQo for ; Fri, 17 Jan 2014 15:02:30 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id D22E81AD190 for ; Fri, 17 Jan 2014 15:02:30 -0800 (PST) Received: from [128.9.184.151] ([128.9.184.151]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s0HN1wvi025952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Jan 2014 15:01:58 -0800 (PST) Message-ID: <52D9B667.2060000@isi.edu> Date: Fri, 17 Jan 2014 15:01:59 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Brandon Williams , "Eggert, Lars" , Wesley Eddy References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52D541B3.7000606@mti-systems.com> <98531DC4-272A-4110-A676-8613521E3FB7@netapp.com> <52D5C0AC.4080604@isi.edu> <52D6A8E8.6050307@akamai.com> In-Reply-To: <52D6A8E8.6050307@akamai.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 23:02:33 -0000 FWIW, some other suggestions: - the info should only be added by a party that changes the IP header anyway, e.g., a NAT, or by the origin host it MUST NOT be added or modified en-route by a party that does not modify the IP header - the info SHOULD correlate to the IP header change - the info MUST be advisory only; e.g., as an optimization this is because the info isn't authenticated or protected from other on-path modification Joe On 1/15/2014 7:27 AM, Brandon Williams wrote: > I think you've captured our intent fairly well. This is an attempt to > solve a problem introduced by the use of address sharing. We have no > illusion that the proposed solution is elegant. There certainly are > issues associated with the approach, especially when applied by an > in-path NAT device. That said, all potential solutions to this problem > set have issues. The purpose of the I.D. is to help us better evaluate > this specific proposed solution. > > Regarding the representation of RFC6967, it was not our intent to > indicate that the RFC "recommends" the TCP option over other options, > nor to minimize the concerns raised about the approach in that RFC. I do > think that "can be successfully applied to a broad range of use cases > with limited performance impact" is a fair representation of the tcp > option solution analysis in section 5 of RFC6967. All we're really > trying to indicate is that the RFC seems to justify continued > experimentation in order to better evaluate whether this approach adds > enough value to outweigh the shortcomings. We'll attempt to clarify our > intent in the next revision. > > --Brandon > > On 01/14/2014 05:56 PM, Joe Touch wrote: >> >> >> On 1/14/2014 7:34 AM, Eggert, Lars wrote: >>> On 2014-1-14, at 14:54, Wesley Eddy wrote: >>>> I think we should not proceed at all on this. >>>> Intermediate devices shouldn't play with TCP options. >>>> My guess is that there may even be strong consensus on this. >>> >>> Fully agreed. >>> >>> Lars >> >> I'm confused about the concern. >> >> Although I completely agree that intermediate devices shouldn't play >> with TCP options, they already DO play with TCP fields that they >> shouldn't - e.g., NATs change IP source address and port numbers. >> >> AFAICT, this document's intent in using intermediate devices is to have >> the NAT preserve some variant/derivative of the origin IP address/port >> info, i.e., so the receiving system can (if it wants) determine the >> difference between different origin hosts vs. different connections from >> the same origin host, even when all are behind a NAT. >> >> I agree it's ugly, but it seems that having NATs is what creates the >> ugliness. NATs need to do one of two things, and neither one is >> architecturally more corrrect: >> >> 1. enforce the notion that they are the single address for >> all hosts behind them >> >> 2. allow different hosts behind them to be exposed as such >> >> So while I agree that a generic intermediate device should NEVER do >> this, IMO a NAT doing this is different - it's more like cleaning up a >> problem it creates, vs. making things worse. >> >> My conclusion is that ONLY devices that change IP source addresses >> and/or ports MAY do this (and only devices that add the option should >> ever remove it, e.g. in the reverse direction), but other intermediate >> devices MUST NOT change these values. >> >> I don't agree that this is either an elegant, appropriate, or necessary >> solution. But it's not 'evil' for the reasons presented thus far. >> >> There are other issues, e.g., TCP-AO includes an experimental NAT >> variant that this is incompatible with, but we can discuss those if this >> becomes a WG doc. >> >> Joe >> >> PS - IMO, this document misrepresents the contents of RFC6967 in its >> intro: >> >> [RFC6967] provides analysis of various solutions to the problem of >> revealing the sending hosts's identifier (HOST_ID) information to >> the >> receiver, which indicates that a solution using a TCP [RFC0793] >> option for this purpose can be successfully applied to a broad range >> of use cases with limited performance impact. >> >> RFC6967 never says that the TCP solution can be successful in the way >> claimed; in fact, it lists a large number of issues with a TCP solution. >> >> RFC6967 didn't recommend a solution: >> >> This document analyzes a set of potential solutions for revealing a >> host identifier and does not recommend a particular solution, >> although it does highlight the hazards of some approaches. >> >> >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > From wes@mti-systems.com Sat Jan 18 20:05:08 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52AAE1AD986 for ; Sat, 18 Jan 2014 20:05:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 trvvylhZ9bui for ; Sat, 18 Jan 2014 20:05:06 -0800 (PST) Received: from atl4mhob07.myregisteredsite.com (atl4mhob07.myregisteredsite.com [209.17.115.45]) by ietfa.amsl.com (Postfix) with ESMTP id C83171AD942 for ; Sat, 18 Jan 2014 20:05:06 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.206]) by atl4mhob07.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s0J44q6J023306 for ; Sat, 18 Jan 2014 23:04:52 -0500 Received: (qmail 11603 invoked by uid 0); 19 Jan 2014 04:04:52 -0000 X-TCPREMOTEIP: 69.81.143.143 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.107?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 19 Jan 2014 04:04:52 -0000 Message-ID: <52DB4EDB.4050208@mti-systems.com> Date: Sat, 18 Jan 2014 23:04:43 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Joe Touch , Brandon Williams , "Eggert, Lars" References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52D541B3.7000606@mti-systems.com> <98531DC4-272A-4110-A676-8613521E3FB7@netapp.com> <52D5C0AC.4080604@isi.edu> <52D6A8E8.6050307@akamai.com> <52D9B667.2060000@isi.edu> In-Reply-To: <52D9B667.2060000@isi.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2014 04:05:08 -0000 On 1/17/2014 6:01 PM, Joe Touch wrote: > FWIW, some other suggestions: > > - the info should only be added by a party that changes the > IP header anyway, e.g., a NAT, or by the origin host > > it MUST NOT be added or modified en-route by a party that does > not modify the IP header > > - the info SHOULD correlate to the IP header change > > - the info MUST be advisory only; e.g., as an optimization > > this is because the info isn't authenticated or protected > from other on-path modification > I could almost agree to that, except I think this is a bit beyond the typical NAT behavior (and potential harmfulness) because it's assuming: - there is actually room to add the option without impacting later use during the connection of other options - adding this option doesn't conflict with any other options Those points, I think, are troublesome for the general approach, and in my opinion, make it difficult to get right such that it won't ultimately create a headache N years later. -- Wes Eddy MTI Systems From brandon.williams@akamai.com Tue Jan 21 06:50:47 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045BE1A010E for ; Tue, 21 Jan 2014 06:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 wtWxzInAwlC2 for ; Tue, 21 Jan 2014 06:50:44 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 7911F1A010D for ; Tue, 21 Jan 2014 06:50:44 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 2CE8B47364; Tue, 21 Jan 2014 14:50:44 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 2063247363; Tue, 21 Jan 2014 14:50:44 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id EE2DD1FF9; Tue, 21 Jan 2014 14:50:43 +0000 (GMT) Message-ID: <52DE8943.3090205@akamai.com> Date: Tue, 21 Jan 2014 09:50:43 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52D541B3.7000606@mti-systems.com> <98531DC4-272A-4110-A676-8613521E3FB7@netapp.com> <52D5C0AC.4080604@isi.edu>, <52D6A8E8.6050307@akamai.com> <655C07320163294895BBADA28372AF5D18AF3B@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D18AF3B@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 14:50:47 -0000 Yes, both the topics of continued experimentation and important use cases clearly need some discussion in the document. We will attempt to clarify both of these in the next version of the document. Since this option format is meant to be a unified replacement for the three previous independent specifications, it would probably also be good for us to add a section that describes how this option could be used to get the functionality of each of the three options that it replaces. --Brandon On 01/15/2014 05:37 PM, Scharf, Michael (Michael) wrote: > Could the authors perhaps provide some additional explanation about this "continued experimentation" that is apparently planned with draft-williams-exp-tcp-host-id-opt? Personally, I do not follow any NAT work in the IETF, and this may apply to other TCPM contributors as well. So it seems to me like a valid question that could facilitate the discussion. > > Regarding the overlay use case, I recall some explanation of draft-williams-overlaypath-ip-tcp-rfc on this list, but the option format now changed, and I wonder whether this change would affect experiments. (Also, enabling interoperable implementations in the Internet could require a specification of the content, which only draft-williams-overlaypath-ip-tcp-rfc provides.) > > Other potential use cases are apparently documented e.g. in draft-boucadair-intarea-host-identifier-scenarios-03, but this draft has expired, and it is basically a survey. > > Given that all these topics are outside the typical focus of TCPM, I think it could be useful to provide some background to this group. Specifically, I wonder about pointers to running code and details regarding planned use of draft-williams-exp-tcp-host-id-opt in real-world experiments. > > Thanks > > Michael > > ________________________________________ > Von: tcpm [tcpm-bounces@ietf.org]" im Auftrag von "Brandon Williams [brandon.williams@akamai.com] > Gesendet: Mittwoch, 15. Januar 2014 16:27 > An: Joe Touch; Eggert, Lars; Wesley Eddy > Cc: tcpm@ietf.org > Betreff: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt > > I think you've captured our intent fairly well. This is an attempt to > solve a problem introduced by the use of address sharing. We have no > illusion that the proposed solution is elegant. There certainly are > issues associated with the approach, especially when applied by an > in-path NAT device. That said, all potential solutions to this problem > set have issues. The purpose of the I.D. is to help us better evaluate > this specific proposed solution. > > Regarding the representation of RFC6967, it was not our intent to > indicate that the RFC "recommends" the TCP option over other options, > nor to minimize the concerns raised about the approach in that RFC. I do > think that "can be successfully applied to a broad range of use cases > with limited performance impact" is a fair representation of the tcp > option solution analysis in section 5 of RFC6967. All we're really > trying to indicate is that the RFC seems to justify continued > experimentation in order to better evaluate whether this approach adds > enough value to outweigh the shortcomings. We'll attempt to clarify our > intent in the next revision. > > --Brandon > > On 01/14/2014 05:56 PM, Joe Touch wrote: >> >> >> On 1/14/2014 7:34 AM, Eggert, Lars wrote: >>> On 2014-1-14, at 14:54, Wesley Eddy wrote: >>>> I think we should not proceed at all on this. >>>> Intermediate devices shouldn't play with TCP options. >>>> My guess is that there may even be strong consensus on this. >>> >>> Fully agreed. >>> >>> Lars >> >> I'm confused about the concern. >> >> Although I completely agree that intermediate devices shouldn't play >> with TCP options, they already DO play with TCP fields that they >> shouldn't - e.g., NATs change IP source address and port numbers. >> >> AFAICT, this document's intent in using intermediate devices is to have >> the NAT preserve some variant/derivative of the origin IP address/port >> info, i.e., so the receiving system can (if it wants) determine the >> difference between different origin hosts vs. different connections from >> the same origin host, even when all are behind a NAT. >> >> I agree it's ugly, but it seems that having NATs is what creates the >> ugliness. NATs need to do one of two things, and neither one is >> architecturally more corrrect: >> >> 1. enforce the notion that they are the single address for >> all hosts behind them >> >> 2. allow different hosts behind them to be exposed as such >> >> So while I agree that a generic intermediate device should NEVER do >> this, IMO a NAT doing this is different - it's more like cleaning up a >> problem it creates, vs. making things worse. >> >> My conclusion is that ONLY devices that change IP source addresses >> and/or ports MAY do this (and only devices that add the option should >> ever remove it, e.g. in the reverse direction), but other intermediate >> devices MUST NOT change these values. >> >> I don't agree that this is either an elegant, appropriate, or necessary >> solution. But it's not 'evil' for the reasons presented thus far. >> >> There are other issues, e.g., TCP-AO includes an experimental NAT >> variant that this is incompatible with, but we can discuss those if this >> becomes a WG doc. >> >> Joe >> >> PS - IMO, this document misrepresents the contents of RFC6967 in its intro: >> >> [RFC6967] provides analysis of various solutions to the problem of >> revealing the sending hosts's identifier (HOST_ID) information to the >> receiver, which indicates that a solution using a TCP [RFC0793] >> option for this purpose can be successfully applied to a broad range >> of use cases with limited performance impact. >> >> RFC6967 never says that the TCP solution can be successful in the way >> claimed; in fact, it lists a large number of issues with a TCP solution. >> >> RFC6967 didn't recommend a solution: >> >> This document analyzes a set of potential solutions for revealing a >> host identifier and does not recommend a particular solution, >> although it does highlight the hazards of some approaches. >> >> >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > > -- > Brandon Williams; Senior Principal Software Engineer > Emerging Products Engineering; Akamai Technologies Inc. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From brandon.williams@akamai.com Tue Jan 21 07:02:57 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2751A0167 for ; Tue, 21 Jan 2014 07:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 Yzr1liV5iafk for ; Tue, 21 Jan 2014 07:02:55 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6761A017E for ; Tue, 21 Jan 2014 07:02:55 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 0D3B547370; Tue, 21 Jan 2014 15:02:55 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id F2EC44736D; Tue, 21 Jan 2014 15:02:54 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id B1ACBFE054; Tue, 21 Jan 2014 15:02:54 +0000 (GMT) Message-ID: <52DE8C1E.2090707@akamai.com> Date: Tue, 21 Jan 2014 10:02:54 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Joe Touch , "Eggert, Lars" , Wesley Eddy References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52D541B3.7000606@mti-systems.com> <98531DC4-272A-4110-A676-8613521E3FB7@netapp.com> <52D5C0AC.4080604@isi.edu> <52D6A8E8.6050307@akamai.com> <52D9B667.2060000@isi.edu> In-Reply-To: <52D9B667.2060000@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 15:02:57 -0000 These points describe the intended use and add some needed clarity. Thanks for the suggestions. We already intend to flesh out the security consideration section a bit, especially around the trust relationship between the sender and receiver (i.e. there is none, unless it's provided by a method outside of this I.D.) and the advisory nature of the option when used outside a context that provides trust guarantees. I'm not completely certain what you mean by "SHOULD correlate to the IP header change". One of the options being replaced by this uses a 16-bit identifier instead of carrying the hidden info directly over from the ingress packets. The identifier would represent a NAT connection mapping for the life of the connection, but would not directly provide the client's address or port. Would this fit what you think of as correlating with the IP header change? --Brandon On 01/17/2014 06:01 PM, Joe Touch wrote: > FWIW, some other suggestions: > > - the info should only be added by a party that changes the > IP header anyway, e.g., a NAT, or by the origin host > > it MUST NOT be added or modified en-route by a party that does > not modify the IP header > > - the info SHOULD correlate to the IP header change > > - the info MUST be advisory only; e.g., as an optimization > > this is because the info isn't authenticated or protected > from other on-path modification > > Joe > > On 1/15/2014 7:27 AM, Brandon Williams wrote: >> I think you've captured our intent fairly well. This is an attempt to >> solve a problem introduced by the use of address sharing. We have no >> illusion that the proposed solution is elegant. There certainly are >> issues associated with the approach, especially when applied by an >> in-path NAT device. That said, all potential solutions to this problem >> set have issues. The purpose of the I.D. is to help us better evaluate >> this specific proposed solution. >> >> Regarding the representation of RFC6967, it was not our intent to >> indicate that the RFC "recommends" the TCP option over other options, >> nor to minimize the concerns raised about the approach in that RFC. I do >> think that "can be successfully applied to a broad range of use cases >> with limited performance impact" is a fair representation of the tcp >> option solution analysis in section 5 of RFC6967. All we're really >> trying to indicate is that the RFC seems to justify continued >> experimentation in order to better evaluate whether this approach adds >> enough value to outweigh the shortcomings. We'll attempt to clarify our >> intent in the next revision. >> >> --Brandon >> >> On 01/14/2014 05:56 PM, Joe Touch wrote: >>> >>> >>> On 1/14/2014 7:34 AM, Eggert, Lars wrote: >>>> On 2014-1-14, at 14:54, Wesley Eddy wrote: >>>>> I think we should not proceed at all on this. >>>>> Intermediate devices shouldn't play with TCP options. >>>>> My guess is that there may even be strong consensus on this. >>>> >>>> Fully agreed. >>>> >>>> Lars >>> >>> I'm confused about the concern. >>> >>> Although I completely agree that intermediate devices shouldn't play >>> with TCP options, they already DO play with TCP fields that they >>> shouldn't - e.g., NATs change IP source address and port numbers. >>> >>> AFAICT, this document's intent in using intermediate devices is to have >>> the NAT preserve some variant/derivative of the origin IP address/port >>> info, i.e., so the receiving system can (if it wants) determine the >>> difference between different origin hosts vs. different connections from >>> the same origin host, even when all are behind a NAT. >>> >>> I agree it's ugly, but it seems that having NATs is what creates the >>> ugliness. NATs need to do one of two things, and neither one is >>> architecturally more corrrect: >>> >>> 1. enforce the notion that they are the single address for >>> all hosts behind them >>> >>> 2. allow different hosts behind them to be exposed as such >>> >>> So while I agree that a generic intermediate device should NEVER do >>> this, IMO a NAT doing this is different - it's more like cleaning up a >>> problem it creates, vs. making things worse. >>> >>> My conclusion is that ONLY devices that change IP source addresses >>> and/or ports MAY do this (and only devices that add the option should >>> ever remove it, e.g. in the reverse direction), but other intermediate >>> devices MUST NOT change these values. >>> >>> I don't agree that this is either an elegant, appropriate, or necessary >>> solution. But it's not 'evil' for the reasons presented thus far. >>> >>> There are other issues, e.g., TCP-AO includes an experimental NAT >>> variant that this is incompatible with, but we can discuss those if this >>> becomes a WG doc. >>> >>> Joe >>> >>> PS - IMO, this document misrepresents the contents of RFC6967 in its >>> intro: >>> >>> [RFC6967] provides analysis of various solutions to the problem of >>> revealing the sending hosts's identifier (HOST_ID) information to >>> the >>> receiver, which indicates that a solution using a TCP [RFC0793] >>> option for this purpose can be successfully applied to a broad range >>> of use cases with limited performance impact. >>> >>> RFC6967 never says that the TCP solution can be successful in the way >>> claimed; in fact, it lists a large number of issues with a TCP solution. >>> >>> RFC6967 didn't recommend a solution: >>> >>> This document analyzes a set of potential solutions for revealing a >>> host identifier and does not recommend a particular solution, >>> although it does highlight the hazards of some approaches. >>> >>> >>> >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>> >> -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From michael.scharf@alcatel-lucent.com Tue Jan 21 07:29:12 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B791A02D9 for ; Tue, 21 Jan 2014 07:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 GchIWNCysHOk for ; Tue, 21 Jan 2014 07:29:08 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 291991A02E7 for ; Tue, 21 Jan 2014 07:29:07 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s0LFT4g1017603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 Jan 2014 09:29:06 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s0LFT4fK009513 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jan 2014 16:29:04 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.112]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 21 Jan 2014 16:29:04 +0100 From: "Scharf, Michael (Michael)" To: Brandon Williams Thread-Topic: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt Thread-Index: AQHPFrg4mqpeUwKEFEKsb8LgwNGt4ZqPTDHw Date: Tue, 21 Jan 2014 15:29:03 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1922CA@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52D541B3.7000606@mti-systems.com> <98531DC4-272A-4110-A676-8613521E3FB7@netapp.com> <52D5C0AC.4080604@isi.edu>,<52D6A8E8.6050307@akamai.com> <655C07320163294895BBADA28372AF5D18AF3B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52DE8943.3090205@akamai.com> In-Reply-To: <52DE8943.3090205@akamai.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 15:29:12 -0000 As a side note, you may also want to consider what happens if the same pack= et hits two of the intended use cases at the same time. For instance, what = happens if a residential NAT adds a host ID and the packet then gets routed= over an overlay? Then the same option could appear twice in the packet, ri= ght? (If option space permits this.) Michael > -----Original Message----- > From: Brandon Williams [mailto:brandon.williams@akamai.com] > Sent: Tuesday, January 21, 2014 3:51 PM > To: Scharf, Michael (Michael) > Cc: tcpm@ietf.org > Subject: Re: [tcpm] New Version Notification for draft-williams-exp- > tcp-host-id-opt-00.txt >=20 > Yes, both the topics of continued experimentation and important use > cases clearly need some discussion in the document. We will attempt to > clarify both of these in the next version of the document. Since this > option format is meant to be a unified replacement for the three > previous independent specifications, it would probably also be good for > us to add a section that describes how this option could be used to get > the functionality of each of the three options that it replaces. >=20 > --Brandon >=20 > On 01/15/2014 05:37 PM, Scharf, Michael (Michael) wrote: > > Could the authors perhaps provide some additional explanation about > this "continued experimentation" that is apparently planned with draft- > williams-exp-tcp-host-id-opt? Personally, I do not follow any NAT work > in the IETF, and this may apply to other TCPM contributors as well. So > it seems to me like a valid question that could facilitate the > discussion. > > > > Regarding the overlay use case, I recall some explanation of draft- > williams-overlaypath-ip-tcp-rfc on this list, but the option format now > changed, and I wonder whether this change would affect experiments. > (Also, enabling interoperable implementations in the Internet could > require a specification of the content, which only draft-williams- > overlaypath-ip-tcp-rfc provides.) > > > > Other potential use cases are apparently documented e.g. in draft- > boucadair-intarea-host-identifier-scenarios-03, but this draft has > expired, and it is basically a survey. > > > > Given that all these topics are outside the typical focus of TCPM, I > think it could be useful to provide some background to this group. > Specifically, I wonder about pointers to running code and details > regarding planned use of draft-williams-exp-tcp-host-id-opt in real- > world experiments. > > > > Thanks > > > > Michael > > > > ________________________________________ > > Von: tcpm [tcpm-bounces@ietf.org]" im Auftrag von "Brandon > Williams [brandon.williams@akamai.com] > > Gesendet: Mittwoch, 15. Januar 2014 16:27 > > An: Joe Touch; Eggert, Lars; Wesley Eddy > > Cc: tcpm@ietf.org > > Betreff: Re: [tcpm] New Version Notification for draft- > williams-exp-tcp-host-id-opt-00.txt > > > > I think you've captured our intent fairly well. This is an attempt to > > solve a problem introduced by the use of address sharing. We have no > > illusion that the proposed solution is elegant. There certainly are > > issues associated with the approach, especially when applied by an > > in-path NAT device. That said, all potential solutions to this > problem > > set have issues. The purpose of the I.D. is to help us better > evaluate > > this specific proposed solution. > > > > Regarding the representation of RFC6967, it was not our intent to > > indicate that the RFC "recommends" the TCP option over other options, > > nor to minimize the concerns raised about the approach in that RFC. I > do > > think that "can be successfully applied to a broad range of use cases > > with limited performance impact" is a fair representation of the tcp > > option solution analysis in section 5 of RFC6967. All we're really > > trying to indicate is that the RFC seems to justify continued > > experimentation in order to better evaluate whether this approach > adds > > enough value to outweigh the shortcomings. We'll attempt to clarify > our > > intent in the next revision. > > > > --Brandon > > > > On 01/14/2014 05:56 PM, Joe Touch wrote: > >> > >> > >> On 1/14/2014 7:34 AM, Eggert, Lars wrote: > >>> On 2014-1-14, at 14:54, Wesley Eddy wrote: > >>>> I think we should not proceed at all on this. > >>>> Intermediate devices shouldn't play with TCP options. > >>>> My guess is that there may even be strong consensus on this. > >>> > >>> Fully agreed. > >>> > >>> Lars > >> > >> I'm confused about the concern. > >> > >> Although I completely agree that intermediate devices shouldn't play > >> with TCP options, they already DO play with TCP fields that they > >> shouldn't - e.g., NATs change IP source address and port numbers. > >> > >> AFAICT, this document's intent in using intermediate devices is to > have > >> the NAT preserve some variant/derivative of the origin IP > address/port > >> info, i.e., so the receiving system can (if it wants) determine the > >> difference between different origin hosts vs. different connections > from > >> the same origin host, even when all are behind a NAT. > >> > >> I agree it's ugly, but it seems that having NATs is what creates the > >> ugliness. NATs need to do one of two things, and neither one is > >> architecturally more corrrect: > >> > >> 1. enforce the notion that they are the single address for > >> all hosts behind them > >> > >> 2. allow different hosts behind them to be exposed as such > >> > >> So while I agree that a generic intermediate device should NEVER do > >> this, IMO a NAT doing this is different - it's more like cleaning up > a > >> problem it creates, vs. making things worse. > >> > >> My conclusion is that ONLY devices that change IP source addresses > >> and/or ports MAY do this (and only devices that add the option > should > >> ever remove it, e.g. in the reverse direction), but other > intermediate > >> devices MUST NOT change these values. > >> > >> I don't agree that this is either an elegant, appropriate, or > necessary > >> solution. But it's not 'evil' for the reasons presented thus far. > >> > >> There are other issues, e.g., TCP-AO includes an experimental NAT > >> variant that this is incompatible with, but we can discuss those if > this > >> becomes a WG doc. > >> > >> Joe > >> > >> PS - IMO, this document misrepresents the contents of RFC6967 in its > intro: > >> > >> [RFC6967] provides analysis of various solutions to the > problem of > >> revealing the sending hosts's identifier (HOST_ID) information > to the > >> receiver, which indicates that a solution using a TCP > [RFC0793] > >> option for this purpose can be successfully applied to a broad > range > >> of use cases with limited performance impact. > >> > >> RFC6967 never says that the TCP solution can be successful in the > way > >> claimed; in fact, it lists a large number of issues with a TCP > solution. > >> > >> RFC6967 didn't recommend a solution: > >> > >> This document analyzes a set of potential solutions for > revealing a > >> host identifier and does not recommend a particular solution, > >> although it does highlight the hazards of some approaches. > >> > >> > >> > >> > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcpm > >> > > > > -- > > Brandon Williams; Senior Principal Software Engineer > > Emerging Products Engineering; Akamai Technologies Inc. > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > >=20 > -- > Brandon Williams; Senior Principal Software Engineer > Emerging Products Engineering; Akamai Technologies Inc. From brandon.williams@akamai.com Tue Jan 21 07:51:30 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF291A0368 for ; Tue, 21 Jan 2014 07:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 3dmnKqC52ISq for ; Tue, 21 Jan 2014 07:51:29 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 299C91A0362 for ; Tue, 21 Jan 2014 07:51:25 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id F1C734736A; Tue, 21 Jan 2014 15:51:24 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id E4E6247366; Tue, 21 Jan 2014 15:51:24 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id C831E2027; Tue, 21 Jan 2014 15:51:24 +0000 (GMT) Message-ID: <52DE977C.4060005@akamai.com> Date: Tue, 21 Jan 2014 10:51:24 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Wesley Eddy , Joe Touch , "Eggert, Lars" References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52D541B3.7000606@mti-systems.com> <98531DC4-272A-4110-A676-8613521E3FB7@netapp.com> <52D5C0AC.4080604@isi.edu> <52D6A8E8.6050307@akamai.com> <52D9B667.2060000@isi.edu> <52DB4EDB.4050208@mti-systems.com> In-Reply-To: <52DB4EDB.4050208@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 15:51:30 -0000 I think we're in agreement about how difficult it may be to get this right in a NAT environment. The spec already attempts to call out some of the issues related to packet sizes and conflicts with other options, and we would be happy to get some feedback about those parts of the document, since improving the discussion of potential problems will be critical to further assessment of the effectiveness (or lack thereof) of the solution. --Brandon On 01/18/2014 11:04 PM, Wesley Eddy wrote: > On 1/17/2014 6:01 PM, Joe Touch wrote: >> FWIW, some other suggestions: >> >> - the info should only be added by a party that changes the >> IP header anyway, e.g., a NAT, or by the origin host >> >> it MUST NOT be added or modified en-route by a party that does >> not modify the IP header >> >> - the info SHOULD correlate to the IP header change >> >> - the info MUST be advisory only; e.g., as an optimization >> >> this is because the info isn't authenticated or protected >> from other on-path modification >> > > > I could almost agree to that, except I think this is a bit > beyond the typical NAT behavior (and potential harmfulness) > because it's assuming: > > - there is actually room to add the option without impacting > later use during the connection of other options > - adding this option doesn't conflict with any other options > > Those points, I think, are troublesome for the general > approach, and in my opinion, make it difficult to get right > such that it won't ultimately create a headache N years later. > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From touch@isi.edu Tue Jan 21 09:25:30 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EEFD1A03E3 for ; Tue, 21 Jan 2014 09:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 SbKvnY40TyvJ for ; Tue, 21 Jan 2014 09:25:27 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id D9D4B1A0176 for ; Tue, 21 Jan 2014 09:25:27 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s0LHMhSD029614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Jan 2014 09:22:43 -0800 (PST) Message-ID: <52DEACE5.7090202@isi.edu> Date: Tue, 21 Jan 2014 09:22:45 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Wesley Eddy , Brandon Williams , "Eggert, Lars" References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52D541B3.7000606@mti-systems.com> <98531DC4-272A-4110-A676-8613521E3FB7@netapp.com> <52D5C0AC.4080604@isi.edu> <52D6A8E8.6050307@akamai.com> <52D9B667.2060000@isi.edu> <52DB4EDB.4050208@mti-systems.com> In-Reply-To: <52DB4EDB.4050208@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 17:25:30 -0000 Hi, Wes (et al.), Agreed - I'll go back to my first observation, though: >>> I agree it's ugly, but it seems that having NATs is >>> what creates the ugliness. I.e., I appreciate the concern about on-path devices inserting/removing TCP options, but I'm sorry if I can't get all worked up about that compared to what NATs do. IMO, if this is done in the same spirit as NATs, it could be as (un)safe. E.g., one view of a NAT is that it completely violates E2E identities. A different view is that a NAT is really the true Internet endpoint, and it's providing a proxy function for devices behind it. I would say that the NAT is on the Internet, and the devices behind it have some access to some Internet services, but they're definitely NOT on the Internet. So yes, this will be difficult to get right, but IMO if this is restricted to being manipulated by devices we *already* allow to modify IP addresses (e.g., sources and NATs), then it could be *as (un)safe* as NATs. Joe On 1/18/2014 8:04 PM, Wesley Eddy wrote: > On 1/17/2014 6:01 PM, Joe Touch wrote: >> FWIW, some other suggestions: >> >> - the info should only be added by a party that changes the >> IP header anyway, e.g., a NAT, or by the origin host >> >> it MUST NOT be added or modified en-route by a party that does >> not modify the IP header >> >> - the info SHOULD correlate to the IP header change >> >> - the info MUST be advisory only; e.g., as an optimization >> >> this is because the info isn't authenticated or protected >> from other on-path modification >> > > > I could almost agree to that, except I think this is a bit > beyond the typical NAT behavior (and potential harmfulness) > because it's assuming: > > - there is actually room to add the option without impacting > later use during the connection of other options > - adding this option doesn't conflict with any other options > > Those points, I think, are troublesome for the general > approach, and in my opinion, make it difficult to get right > such that it won't ultimately create a headache N years later. > From touch@isi.edu Tue Jan 21 09:40:44 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 452A51A018E for ; Tue, 21 Jan 2014 09:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 dmCPCXNp5596 for ; Tue, 21 Jan 2014 09:40:41 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9BEAF1A01B1 for ; Tue, 21 Jan 2014 09:40:41 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s0LHb90N002995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Jan 2014 09:37:09 -0800 (PST) Message-ID: <52DEB045.2020201@isi.edu> Date: Tue, 21 Jan 2014 09:37:09 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" , Brandon Williams References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52D541B3.7000606@mti-systems.com> <98531DC4-272A-4110-A676-8613521E3FB7@netapp.com> <52D5C0AC.4080604@isi.edu>, <52D6A8E8.6050307@akamai.com> <655C07320163294895BBADA28372AF5D18AF3B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52DE8943.3090205@akamai.com> <655C07320163294895BBADA28372AF5D1922CA@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D1922CA@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 17:40:44 -0000 Interactions with other options needs to be discussed, esp. impact on option order, processing order, and whether multiples of the same option are even permitted. Joe On 1/21/2014 7:29 AM, Scharf, Michael (Michael) wrote: > As a side note, you may also want to consider what happens if the same packet hits two of the intended use cases at the same time. For instance, what happens if a residential NAT adds a host ID and the packet then gets routed over an overlay? Then the same option could appear twice in the packet, right? (If option space permits this.) > > Michael > > > >> -----Original Message----- >> From: Brandon Williams [mailto:brandon.williams@akamai.com] >> Sent: Tuesday, January 21, 2014 3:51 PM >> To: Scharf, Michael (Michael) >> Cc: tcpm@ietf.org >> Subject: Re: [tcpm] New Version Notification for draft-williams-exp- >> tcp-host-id-opt-00.txt >> >> Yes, both the topics of continued experimentation and important use >> cases clearly need some discussion in the document. We will attempt to >> clarify both of these in the next version of the document. Since this >> option format is meant to be a unified replacement for the three >> previous independent specifications, it would probably also be good for >> us to add a section that describes how this option could be used to get >> the functionality of each of the three options that it replaces. >> >> --Brandon >> >> On 01/15/2014 05:37 PM, Scharf, Michael (Michael) wrote: >>> Could the authors perhaps provide some additional explanation about >> this "continued experimentation" that is apparently planned with draft- >> williams-exp-tcp-host-id-opt? Personally, I do not follow any NAT work >> in the IETF, and this may apply to other TCPM contributors as well. So >> it seems to me like a valid question that could facilitate the >> discussion. >>> >>> Regarding the overlay use case, I recall some explanation of draft- >> williams-overlaypath-ip-tcp-rfc on this list, but the option format now >> changed, and I wonder whether this change would affect experiments. >> (Also, enabling interoperable implementations in the Internet could >> require a specification of the content, which only draft-williams- >> overlaypath-ip-tcp-rfc provides.) >>> >>> Other potential use cases are apparently documented e.g. in draft- >> boucadair-intarea-host-identifier-scenarios-03, but this draft has >> expired, and it is basically a survey. >>> >>> Given that all these topics are outside the typical focus of TCPM, I >> think it could be useful to provide some background to this group. >> Specifically, I wonder about pointers to running code and details >> regarding planned use of draft-williams-exp-tcp-host-id-opt in real- >> world experiments. >>> >>> Thanks >>> >>> Michael >>> >>> ________________________________________ >>> Von: tcpm [tcpm-bounces@ietf.org]" im Auftrag von "Brandon >> Williams [brandon.williams@akamai.com] >>> Gesendet: Mittwoch, 15. Januar 2014 16:27 >>> An: Joe Touch; Eggert, Lars; Wesley Eddy >>> Cc: tcpm@ietf.org >>> Betreff: Re: [tcpm] New Version Notification for draft- >> williams-exp-tcp-host-id-opt-00.txt >>> >>> I think you've captured our intent fairly well. This is an attempt to >>> solve a problem introduced by the use of address sharing. We have no >>> illusion that the proposed solution is elegant. There certainly are >>> issues associated with the approach, especially when applied by an >>> in-path NAT device. That said, all potential solutions to this >> problem >>> set have issues. The purpose of the I.D. is to help us better >> evaluate >>> this specific proposed solution. >>> >>> Regarding the representation of RFC6967, it was not our intent to >>> indicate that the RFC "recommends" the TCP option over other options, >>> nor to minimize the concerns raised about the approach in that RFC. I >> do >>> think that "can be successfully applied to a broad range of use cases >>> with limited performance impact" is a fair representation of the tcp >>> option solution analysis in section 5 of RFC6967. All we're really >>> trying to indicate is that the RFC seems to justify continued >>> experimentation in order to better evaluate whether this approach >> adds >>> enough value to outweigh the shortcomings. We'll attempt to clarify >> our >>> intent in the next revision. >>> >>> --Brandon >>> >>> On 01/14/2014 05:56 PM, Joe Touch wrote: >>>> >>>> >>>> On 1/14/2014 7:34 AM, Eggert, Lars wrote: >>>>> On 2014-1-14, at 14:54, Wesley Eddy wrote: >>>>>> I think we should not proceed at all on this. >>>>>> Intermediate devices shouldn't play with TCP options. >>>>>> My guess is that there may even be strong consensus on this. >>>>> >>>>> Fully agreed. >>>>> >>>>> Lars >>>> >>>> I'm confused about the concern. >>>> >>>> Although I completely agree that intermediate devices shouldn't play >>>> with TCP options, they already DO play with TCP fields that they >>>> shouldn't - e.g., NATs change IP source address and port numbers. >>>> >>>> AFAICT, this document's intent in using intermediate devices is to >> have >>>> the NAT preserve some variant/derivative of the origin IP >> address/port >>>> info, i.e., so the receiving system can (if it wants) determine the >>>> difference between different origin hosts vs. different connections >> from >>>> the same origin host, even when all are behind a NAT. >>>> >>>> I agree it's ugly, but it seems that having NATs is what creates the >>>> ugliness. NATs need to do one of two things, and neither one is >>>> architecturally more corrrect: >>>> >>>> 1. enforce the notion that they are the single address for >>>> all hosts behind them >>>> >>>> 2. allow different hosts behind them to be exposed as such >>>> >>>> So while I agree that a generic intermediate device should NEVER do >>>> this, IMO a NAT doing this is different - it's more like cleaning up >> a >>>> problem it creates, vs. making things worse. >>>> >>>> My conclusion is that ONLY devices that change IP source addresses >>>> and/or ports MAY do this (and only devices that add the option >> should >>>> ever remove it, e.g. in the reverse direction), but other >> intermediate >>>> devices MUST NOT change these values. >>>> >>>> I don't agree that this is either an elegant, appropriate, or >> necessary >>>> solution. But it's not 'evil' for the reasons presented thus far. >>>> >>>> There are other issues, e.g., TCP-AO includes an experimental NAT >>>> variant that this is incompatible with, but we can discuss those if >> this >>>> becomes a WG doc. >>>> >>>> Joe >>>> >>>> PS - IMO, this document misrepresents the contents of RFC6967 in its >> intro: >>>> >>>> [RFC6967] provides analysis of various solutions to the >> problem of >>>> revealing the sending hosts's identifier (HOST_ID) information >> to the >>>> receiver, which indicates that a solution using a TCP >> [RFC0793] >>>> option for this purpose can be successfully applied to a broad >> range >>>> of use cases with limited performance impact. >>>> >>>> RFC6967 never says that the TCP solution can be successful in the >> way >>>> claimed; in fact, it lists a large number of issues with a TCP >> solution. >>>> >>>> RFC6967 didn't recommend a solution: >>>> >>>> This document analyzes a set of potential solutions for >> revealing a >>>> host identifier and does not recommend a particular solution, >>>> although it does highlight the hazards of some approaches. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >>>> >>> >>> -- >>> Brandon Williams; Senior Principal Software Engineer >>> Emerging Products Engineering; Akamai Technologies Inc. >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>> >> >> -- >> Brandon Williams; Senior Principal Software Engineer >> Emerging Products Engineering; Akamai Technologies Inc. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nishida@sfc.wide.ad.jp Wed Jan 22 00:49:24 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D711A03DE for ; Wed, 22 Jan 2014 00:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.476 X-Spam-Level: * X-Spam-Status: No, score=1.476 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_NEUTRAL=0.779] 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 70UO9kepBUR4 for ; Wed, 22 Jan 2014 00:49:22 -0800 (PST) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id C20621A0379 for ; Wed, 22 Jan 2014 00:49:20 -0800 (PST) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 82E9E2781F3 for ; Wed, 22 Jan 2014 17:49:18 +0900 (JST) Received: by mail-la0-f42.google.com with SMTP id hr13so71193lab.15 for ; Wed, 22 Jan 2014 00:49:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cCfIDX8QOn+KpoC/h4EJ23cMgeEGzG2SJgbfnx0KLM8=; b=g9m7yLejnWxZ8zQSiJ1jrECpY+qZA002/WMmz/13G4GujIWUvNGk+8w3m5pn2kedeL qJvX3z4SDShzlvf5HBUJ9440TSDXr9H+IwhX2J4KuJVagKSt5yNFnk9O/UCrY8L4Vh9Y DshhuvLJSftB1dYCgza5qMYS26jGD2VVu6ySizrxZk2I2NU4snlqsVkao3JZIJCNMu/7 HGzXWNErkEJxH5v0/cTgKltaX/bc3KiyAaDLJxah5UaZamSK364f0+OQ6oMvh01TlFll THCJqd3XWbzjHJt8dfRXcxkleGxi8nmHZ9Gk81R11Yvy4S0pVw0YiCbc6/FF4bZVPjSG Kajg== MIME-Version: 1.0 X-Received: by 10.112.63.40 with SMTP id d8mr138433lbs.35.1390380555495; Wed, 22 Jan 2014 00:49:15 -0800 (PST) Received: by 10.114.93.198 with HTTP; Wed, 22 Jan 2014 00:49:15 -0800 (PST) In-Reply-To: <52DE977C.4060005@akamai.com> References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52D541B3.7000606@mti-systems.com> <98531DC4-272A-4110-A676-8613521E3FB7@netapp.com> <52D5C0AC.4080604@isi.edu> <52D6A8E8.6050307@akamai.com> <52D9B667.2060000@isi.edu> <52DB4EDB.4050208@mti-systems.com> <52DE977C.4060005@akamai.com> Date: Wed, 22 Jan 2014 00:49:15 -0800 Message-ID: From: Yoshifumi Nishida To: Brandon Williams Content-Type: multipart/alternative; boundary=001a11c3eee61cef6004f08b33a8 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 08:49:24 -0000 --001a11c3eee61cef6004f08b33a8 Content-Type: text/plain; charset=ISO-8859-1 Hi Brandon, I personally have the following comments on the draft. 1: It seems to me that the option format might be too simple to accommodate multiple proposals. I'm not very sure how the receiver can identify which proposal has been used. 2: Section 4 seems to contain similar information on option usages which described in other detailed proposals. Isn't it a bit redundant? Or, is there any conflicts between the usages in the draft and other proposals? 3: It seems to me that this draft describe basic framework and more detailed behavior and usages are described in each proposal. Can we proceed this draft without checking detailed behavior in other drafts? Thanks, -- Yoshifumi On Tue, Jan 21, 2014 at 7:51 AM, Brandon Williams < brandon.williams@akamai.com> wrote: > I think we're in agreement about how difficult it may be to get this right > in a NAT environment. The spec already attempts to call out some of the > issues related to packet sizes and conflicts with other options, and we > would be happy to get some feedback about those parts of the document, > since improving the discussion of potential problems will be critical to > further assessment of the effectiveness (or lack thereof) of the solution. > > --Brandon > > > On 01/18/2014 11:04 PM, Wesley Eddy wrote: > >> On 1/17/2014 6:01 PM, Joe Touch wrote: >> >>> FWIW, some other suggestions: >>> >>> - the info should only be added by a party that changes the >>> IP header anyway, e.g., a NAT, or by the origin host >>> >>> it MUST NOT be added or modified en-route by a party that does >>> not modify the IP header >>> >>> - the info SHOULD correlate to the IP header change >>> >>> - the info MUST be advisory only; e.g., as an optimization >>> >>> this is because the info isn't authenticated or protected >>> from other on-path modification >>> >>> >> >> I could almost agree to that, except I think this is a bit >> beyond the typical NAT behavior (and potential harmfulness) >> because it's assuming: >> >> - there is actually room to add the option without impacting >> later use during the connection of other options >> - adding this option doesn't conflict with any other options >> >> Those points, I think, are troublesome for the general >> approach, and in my opinion, make it difficult to get right >> such that it won't ultimately create a headache N years later. >> >> > -- > Brandon Williams; Senior Principal Software Engineer > Emerging Products Engineering; Akamai Technologies Inc. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --001a11c3eee61cef6004f08b33a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Brandon,

I personally have the follo= wing comments on the draft.

1: It seems to me that= the option format might be too simple to accommodate multiple proposals.= =A0
=A0 =A0 I'm not very sure how the receiver can identify which prop= osal has been used.=A0
=A0 =A0=A0
2: Section 4 seems to contain similar information= on option usages which described in other detailed proposals.
= =A0 =A0 Isn't it a bit redundant? Or, is there any conflicts between th= e usages in the draft and other proposals?
=A0 =A0=A0
3: It seems to me that this draft describe basic = framework and more detailed behavior and usages are described in each propo= sal. Can we proceed this draft without checking detailed behavior in other = drafts?

Thanks,
--
Yoshifumi

=


O= n Tue, Jan 21, 2014 at 7:51 AM, Brandon Williams <brandon.willia= ms@akamai.com> wrote:
I think we're in agreement about how dif= ficult it may be to get this right in a NAT environment. The spec already a= ttempts to call out some of the issues related to packet sizes and conflict= s with other options, and we would be happy to get some feedback about thos= e parts of the document, since improving the discussion of potential proble= ms will be critical to further assessment of the effectiveness (or lack the= reof) of the solution.

--Brandon


On 01/18/2014 11:04 PM, Wesley Eddy wrote:
On 1/17/2014 6:01 PM, Joe Touch wrote:
FWIW, some other suggestions:

=A0 =A0 =A0- the info should only be added by a party that changes the
=A0 =A0 =A0IP header anyway, e.g., a NAT, or by the origin host

=A0 =A0 =A0it MUST NOT be added or modified en-route by a party that does =A0 =A0 =A0not modify the IP header

=A0 =A0 =A0- the info SHOULD correlate to the IP header change

=A0 =A0 =A0- the info MUST be advisory only; e.g., as an optimization

=A0 =A0 =A0this is because the info isn't authenticated or protected =A0 =A0 =A0from other on-path modification



I could almost agree to that, except I think this is a bit
beyond the typical NAT behavior (and potential harmfulness)
because it's assuming:

- there is actually room to add the option without impacting
=A0 =A0later use during the connection of other options
- adding this option doesn't conflict with any other options

Those points, I think, are troublesome for the general
approach, and in my opinion, make it difficult to get right
such that it won't ultimately create a headache N years later.


--
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.
_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--001a11c3eee61cef6004f08b33a8-- From michael.scharf@alcatel-lucent.com Wed Jan 22 01:56:57 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E053A1A041E for ; Wed, 22 Jan 2014 01:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 lbqDjJ-WxAkv for ; Wed, 22 Jan 2014 01:56:56 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 6C93F1A041B for ; Wed, 22 Jan 2014 01:56:56 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s0M9urqV006300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 22 Jan 2014 03:56:55 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s0M9uqB0029278 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jan 2014 10:56:53 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.112]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 22 Jan 2014 10:56:53 +0100 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Thread-Topic: TCPM agenda requests for IETF 89 Thread-Index: Ac8XWEWPkKAwesuwTqafeAKa+5wujA== Date: Wed, 22 Jan 2014 09:56:52 +0000 Message-ID: <655C07320163294895BBADA28372AF5D193CE3@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm-chairs@tools.ietf.org" Subject: [tcpm] TCPM agenda requests for IETF 89 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 09:56:58 -0000 Hi, As usual, we plan have a 2.5 hour TCPM meeting in London. If you want to pr= esent a draft, please send the following information to the chairs: * Title / name of draft * Speaker * Requested time The presentation slots are primarily given to working group drafts, and dra= fts that are discussed on the list prior to the meeting. The deadline for s= ending the agenda requests is February 14. As a heads-up, we would really appreciate comments on draft-ietf-tcpm-accec= n-reqs and draft-ietf-tcpm-rtorestart. In absence of feedback the chairs pl= an to move forward these documents to WGLC, e.g., after the London meeting.= Obviously, further reviews of our other documents would be very welcome as= well. Thanks Pasi, Yoshifumi, Michael From internet-drafts@ietf.org Fri Jan 24 14:11:09 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA2C1A013C; Fri, 24 Jan 2014 14:11:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 yp7y2YKeiHiZ; Fri, 24 Jan 2014 14:11:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6310C1A001A; Fri, 24 Jan 2014 14:11:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140124221107.26633.68541.idtracker@ietfa.amsl.com> Date: Fri, 24 Jan 2014 14:11:07 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-19.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 22:11:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions Work= ing Group of the IETF. Title : TCP Extensions for High Performance Authors : David Borman Bob Braden Van Jacobson Richard Scheffenegger Filename : draft-ietf-tcpm-1323bis-19.txt Pages : 48 Date : 2014-01-24 Abstract: This document specifies a set of TCP extensions to improve performance over paths with a large bandwidth * delay product and to provide reliable operation over very high-speed paths. It defines the TCP Window Scale (WS) option and the TCP Timestamps (TS) option and their semantics. The Window Scale option is used to support larger receive windows, while the Timestamps option can be used for at least two distinct mechanisms, PAWS (Protection Against Wrapped Sequences) and RTTM (Round Trip Time Measurement), that are also described herein. This document obsoletes RFC1323 and describes changes from it. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-1323bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-19 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-1323bis-19 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/ From rs@netapp.com Fri Jan 24 14:17:53 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F701A0197; Fri, 24 Jan 2014 14:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-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 IQKIlL1cxxId; Fri, 24 Jan 2014 14:17:50 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 97E9D1A0185; Fri, 24 Jan 2014 14:17:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,715,1384329600"; d="scan'208";a="97979106" Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx11-out.netapp.com with ESMTP; 24 Jan 2014 14:17:49 -0800 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.147]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Fri, 24 Jan 2014 14:17:49 -0800 From: "Scheffenegger, Richard" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-19.txt Thread-Index: AQHPGVFM3686iQGV2Uyqx0WfZwajLpqUcXVw Date: Fri, 24 Jan 2014 22:17:48 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F25FD09E7@SACEXCMBX02-PRD.hq.netapp.com> References: <20140124221107.26633.68541.idtracker@ietfa.amsl.com> In-Reply-To: <20140124221107.26633.68541.idtracker@ietfa.amsl.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.117] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-19.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 22:17:54 -0000 For your information, during the AD review to minor issues were found; One = poor use of RFC2119 wording, and an update to the IANA actions to update th= e TCP options list to reference this too-be-RFC. Best regards, Richard Scheffenegger > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Freitag, 24. J=E4nner 2014 23:11 > To: i-d-announce@ietf.org > Cc: tcpm@ietf.org > Subject: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-19.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the TCP Maintenance and Minor Extensions > Working Group of the IETF. >=20 > Title : TCP Extensions for High Performance > Authors : David Borman > Bob Braden > Van Jacobson > Richard Scheffenegger > Filename : draft-ietf-tcpm-1323bis-19.txt > Pages : 48 > Date : 2014-01-24 >=20 > Abstract: > This document specifies a set of TCP extensions to improve > performance over paths with a large bandwidth * delay product and to > provide reliable operation over very high-speed paths. It defines > the TCP Window Scale (WS) option and the TCP Timestamps (TS) option > and their semantics. The Window Scale option is used to support > larger receive windows, while the Timestamps option can be used for > at least two distinct mechanisms, PAWS (Protection Against Wrapped > Sequences) and RTTM (Round Trip Time Measurement), that are also > described herein. >=20 > This document obsoletes RFC1323 and describes changes from it. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-1323bis/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-19 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-1323bis-19 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From internet-drafts@ietf.org Sun Jan 26 21:45:24 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296001A01C1; Sun, 26 Jan 2014 21:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 tfp-MrdRCNoO; Sun, 26 Jan 2014 21:45:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23EF61A01C2; Sun, 26 Jan 2014 21:45:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140127054522.14889.8967.idtracker@ietfa.amsl.com> Date: Sun, 26 Jan 2014 21:45:22 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-fastopen-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 05:45:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions Work= ing Group of the IETF. Title : TCP Fast Open Authors : Yuchung Cheng Jerry Chu Sivasankar Radhakrishnan Arvind Jain Filename : draft-ietf-tcpm-fastopen-06.txt Pages : 24 Date : 2014-01-26 Abstract: TCP Fast Open (TFO) allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, thus saving up to one full round trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged. However TFO deviates from the standard TCP semantics the data in the SYN could be replayed to an application in some rare circumstances. Applications should not use TFO unless they can tolerate this issue detailed in the Applicability section. Terminology The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-fastopen-06 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/ From pasi.sarolahti@iki.fi Wed Jan 29 15:08:34 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEB61A03F0 for ; Wed, 29 Jan 2014 15:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 AD8_8JAsgTN5 for ; Wed, 29 Jan 2014 15:08:32 -0800 (PST) Received: from kirsi1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8B81A03B7 for ; Wed, 29 Jan 2014 15:08:31 -0800 (PST) Received: from pasisarahtismbp.lan (80.223.92.46) by kirsi1.inet.fi (8.5.140.03) (authenticated as saropa-1) id 529734CF0515193A; Thu, 30 Jan 2014 01:08:28 +0200 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Pasi Sarolahti In-Reply-To: <21491_1390601885_52E2E69D_21491_2072_1_012C3117EDDB3C4781FD802A8C27DD4F25FD09E7@SACEXCMBX02-PRD.hq.netapp.com> Date: Thu, 30 Jan 2014 01:08:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <61411FE7-6C89-4862-B570-B6E3BAC33BE2@iki.fi> References: <20140124221107.26633.68541.idtracker@ietfa.amsl.com> <21491_1390601885_52E2E69D_21491_2072_1_012C3117EDDB3C4781FD802A8C27DD4F25FD09E7@SACEXCMBX02-PRD.hq.netapp.com> To: "tcpm@ietf.org" X-Mailer: Apple Mail (2.1827) Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-19.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 23:08:34 -0000 On 25 Jan 2014, at 00:17, Scheffenegger, Richard wrote: > For your information, during the AD review to minor issues were found; = One poor use of RFC2119 wording, and an update to the IANA actions to = update the TCP options list to reference this too-be-RFC. Specifically, the wording change was about Windows Scale option (sec = 2.2) OLD: "This option MAY be sent in an initial segment (i.e., a segment with the SYN bit on and the ACK bit off). It MAY also be sent in a segment, but only if a Window Scale option was received in the initial segment." NEW: "This option MAY be sent in an initial segment (i.e., a segment with the SYN bit on and the ACK bit off). If a Window Scale option was received in the initial segment, then this option MAY be sent in the segment." We (authors, AD, doc shepherd) believe the new text better captures the = right intent. Unless someone objects this change (if so, let us know = soon), the document should be ready to move forward. - Pasi From mohamed.boucadair@orange.com Thu Jan 30 23:13:43 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9FA1A0566 for ; Thu, 30 Jan 2014 23:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 GxUFLeI3laIv for ; Thu, 30 Jan 2014 23:13:41 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id D44E21A0553 for ; Thu, 30 Jan 2014 23:13:40 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 6C85D1904A0; Fri, 31 Jan 2014 08:13:36 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 503693840FE; Fri, 31 Jan 2014 08:13:36 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Fri, 31 Jan 2014 08:13:36 +0100 From: To: "Scharf, Michael (Michael)" , Brandon Williams Date: Fri, 31 Jan 2014 08:13:34 +0100 Thread-Topic: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt Thread-Index: AQHPFrg4mqpeUwKEFEKsb8LgwNGt4ZqPTDHwgA8trBA= Message-ID: <94C682931C08B048B7A8645303FDC9F36F4863501F@PUEXCB1B.nanterre.francetelecom.fr> References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52D541B3.7000606@mti-systems.com> <98531DC4-272A-4110-A676-8613521E3FB7@netapp.com> <52D5C0AC.4080604@isi.edu>,<52D6A8E8.6050307@akamai.com> <655C07320163294895BBADA28372AF5D18AF3B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52DE8943.3090205@akamai.com> <655C07320163294895BBADA28372AF5D1922CA@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D1922CA@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.31.31214 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 07:13:43 -0000 Dear Michael, Good point.=20 We had some text in the draft that governs that case:=20 o The device may be configured to maintain any existing HOST_ID TCP option(s) in the received message, the device MUST NOT remove those instances of the option. Furthermore, it MUST add a new HOST_ID TCP option while preserving the order of appearance in the message. In particular, the local HOST_ID TCP option MUST appear as the last occurrence of the HOST_ID TCP option in the message. We may consider adding an example to illustrate how it works (e.g., CGN + C= DN use case). Cheers, Med >-----Message d'origine----- >De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de Scharf, Michael >(Michael) >Envoy=E9=A0: mardi 21 janvier 2014 16:29 >=C0=A0: Brandon Williams >Cc=A0: tcpm@ietf.org >Objet=A0: Re: [tcpm] New Version Notification for draft-williams-exp-tcp- >host-id-opt-00.txt > >As a side note, you may also want to consider what happens if the same >packet hits two of the intended use cases at the same time. For instance, >what happens if a residential NAT adds a host ID and the packet then gets >routed over an overlay? Then the same option could appear twice in the >packet, right? (If option space permits this.) > >Michael > > > >> -----Original Message----- >> From: Brandon Williams [mailto:brandon.williams@akamai.com] >> Sent: Tuesday, January 21, 2014 3:51 PM >> To: Scharf, Michael (Michael) >> Cc: tcpm@ietf.org >> Subject: Re: [tcpm] New Version Notification for draft-williams-exp- >> tcp-host-id-opt-00.txt >> >> Yes, both the topics of continued experimentation and important use >> cases clearly need some discussion in the document. We will attempt to >> clarify both of these in the next version of the document. Since this >> option format is meant to be a unified replacement for the three >> previous independent specifications, it would probably also be good for >> us to add a section that describes how this option could be used to get >> the functionality of each of the three options that it replaces. >> >> --Brandon >> >> On 01/15/2014 05:37 PM, Scharf, Michael (Michael) wrote: >> > Could the authors perhaps provide some additional explanation about >> this "continued experimentation" that is apparently planned with draft- >> williams-exp-tcp-host-id-opt? Personally, I do not follow any NAT work >> in the IETF, and this may apply to other TCPM contributors as well. So >> it seems to me like a valid question that could facilitate the >> discussion. >> > >> > Regarding the overlay use case, I recall some explanation of draft- >> williams-overlaypath-ip-tcp-rfc on this list, but the option format now >> changed, and I wonder whether this change would affect experiments. >> (Also, enabling interoperable implementations in the Internet could >> require a specification of the content, which only draft-williams- >> overlaypath-ip-tcp-rfc provides.) >> > >> > Other potential use cases are apparently documented e.g. in draft- >> boucadair-intarea-host-identifier-scenarios-03, but this draft has >> expired, and it is basically a survey. >> > >> > Given that all these topics are outside the typical focus of TCPM, I >> think it could be useful to provide some background to this group. >> Specifically, I wonder about pointers to running code and details >> regarding planned use of draft-williams-exp-tcp-host-id-opt in real- >> world experiments. >> > >> > Thanks >> > >> > Michael >> > >> > ________________________________________ >> > Von: tcpm [tcpm-bounces@ietf.org]" im Auftrag von "Brandon >> Williams [brandon.williams@akamai.com] >> > Gesendet: Mittwoch, 15. Januar 2014 16:27 >> > An: Joe Touch; Eggert, Lars; Wesley Eddy >> > Cc: tcpm@ietf.org >> > Betreff: Re: [tcpm] New Version Notification for draft- >> williams-exp-tcp-host-id-opt-00.txt >> > >> > I think you've captured our intent fairly well. This is an attempt to >> > solve a problem introduced by the use of address sharing. We have no >> > illusion that the proposed solution is elegant. There certainly are >> > issues associated with the approach, especially when applied by an >> > in-path NAT device. That said, all potential solutions to this >> problem >> > set have issues. The purpose of the I.D. is to help us better >> evaluate >> > this specific proposed solution. >> > >> > Regarding the representation of RFC6967, it was not our intent to >> > indicate that the RFC "recommends" the TCP option over other options, >> > nor to minimize the concerns raised about the approach in that RFC. I >> do >> > think that "can be successfully applied to a broad range of use cases >> > with limited performance impact" is a fair representation of the tcp >> > option solution analysis in section 5 of RFC6967. All we're really >> > trying to indicate is that the RFC seems to justify continued >> > experimentation in order to better evaluate whether this approach >> adds >> > enough value to outweigh the shortcomings. We'll attempt to clarify >> our >> > intent in the next revision. >> > >> > --Brandon >> > >> > On 01/14/2014 05:56 PM, Joe Touch wrote: >> >> >> >> >> >> On 1/14/2014 7:34 AM, Eggert, Lars wrote: >> >>> On 2014-1-14, at 14:54, Wesley Eddy wrote: >> >>>> I think we should not proceed at all on this. >> >>>> Intermediate devices shouldn't play with TCP options. >> >>>> My guess is that there may even be strong consensus on this. >> >>> >> >>> Fully agreed. >> >>> >> >>> Lars >> >> >> >> I'm confused about the concern. >> >> >> >> Although I completely agree that intermediate devices shouldn't play >> >> with TCP options, they already DO play with TCP fields that they >> >> shouldn't - e.g., NATs change IP source address and port numbers. >> >> >> >> AFAICT, this document's intent in using intermediate devices is to >> have >> >> the NAT preserve some variant/derivative of the origin IP >> address/port >> >> info, i.e., so the receiving system can (if it wants) determine the >> >> difference between different origin hosts vs. different connections >> from >> >> the same origin host, even when all are behind a NAT. >> >> >> >> I agree it's ugly, but it seems that having NATs is what creates the >> >> ugliness. NATs need to do one of two things, and neither one is >> >> architecturally more corrrect: >> >> >> >> 1. enforce the notion that they are the single address for >> >> all hosts behind them >> >> >> >> 2. allow different hosts behind them to be exposed as such >> >> >> >> So while I agree that a generic intermediate device should NEVER do >> >> this, IMO a NAT doing this is different - it's more like cleaning up >> a >> >> problem it creates, vs. making things worse. >> >> >> >> My conclusion is that ONLY devices that change IP source addresses >> >> and/or ports MAY do this (and only devices that add the option >> should >> >> ever remove it, e.g. in the reverse direction), but other >> intermediate >> >> devices MUST NOT change these values. >> >> >> >> I don't agree that this is either an elegant, appropriate, or >> necessary >> >> solution. But it's not 'evil' for the reasons presented thus far. >> >> >> >> There are other issues, e.g., TCP-AO includes an experimental NAT >> >> variant that this is incompatible with, but we can discuss those if >> this >> >> becomes a WG doc. >> >> >> >> Joe >> >> >> >> PS - IMO, this document misrepresents the contents of RFC6967 in its >> intro: >> >> >> >> [RFC6967] provides analysis of various solutions to the >> problem of >> >> revealing the sending hosts's identifier (HOST_ID) information >> to the >> >> receiver, which indicates that a solution using a TCP >> [RFC0793] >> >> option for this purpose can be successfully applied to a broad >> range >> >> of use cases with limited performance impact. >> >> >> >> RFC6967 never says that the TCP solution can be successful in the >> way >> >> claimed; in fact, it lists a large number of issues with a TCP >> solution. >> >> >> >> RFC6967 didn't recommend a solution: >> >> >> >> This document analyzes a set of potential solutions for >> revealing a >> >> host identifier and does not recommend a particular solution, >> >> although it does highlight the hazards of some approaches. >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> tcpm mailing list >> >> tcpm@ietf.org >> >> https://www.ietf.org/mailman/listinfo/tcpm >> >> >> > >> > -- >> > Brandon Williams; Senior Principal Software Engineer >> > Emerging Products Engineering; Akamai Technologies Inc. >> > _______________________________________________ >> > tcpm mailing list >> > tcpm@ietf.org >> > https://www.ietf.org/mailman/listinfo/tcpm >> > >> >> -- >> Brandon Williams; Senior Principal Software Engineer >> Emerging Products Engineering; Akamai Technologies Inc. >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www.ietf.org/mailman/listinfo/tcpm From mohamed.boucadair@orange.com Thu Jan 30 23:15:46 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8921A0566 for ; Thu, 30 Jan 2014 23:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 zl2PM7oRU6Rw for ; Thu, 30 Jan 2014 23:15:44 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id E31561A0559 for ; Thu, 30 Jan 2014 23:15:43 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 829A91B83C4; Fri, 31 Jan 2014 08:15:39 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 5AC831580FC; Fri, 31 Jan 2014 08:15:39 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Fri, 31 Jan 2014 08:15:39 +0100 From: To: Joe Touch , "Scharf, Michael (Michael)" , Brandon Williams Date: Fri, 31 Jan 2014 08:15:37 +0100 Thread-Topic: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt Thread-Index: Ac8Wz+xJqN44KnypSnS3n6oKh/papgHhCQPw Message-ID: <94C682931C08B048B7A8645303FDC9F36F48635022@PUEXCB1B.nanterre.francetelecom.fr> References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52D541B3.7000606@mti-systems.com> <98531DC4-272A-4110-A676-8613521E3FB7@netapp.com> <52D5C0AC.4080604@isi.edu>, <52D6A8E8.6050307@akamai.com> <655C07320163294895BBADA28372AF5D18AF3B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52DE8943.3090205@akamai.com> <655C07320163294895BBADA28372AF5D1922CA@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52DEB045.2020201@isi.edu> In-Reply-To: <52DEB045.2020201@isi.edu> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.19.63615 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 07:15:46 -0000 Hi Joe, FWIW, the draft already include some text to discuss the interaction with o= ther options: http://tools.ietf.org/html/draft-williams-exp-tcp-host-id-opt= -00#section-5=20 Comments and suggestions to enrich that section are more than welcome. Cheers, Med >-----Message d'origine----- >De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de Joe Touch >Envoy=E9=A0: mardi 21 janvier 2014 18:37 >=C0=A0: Scharf, Michael (Michael); Brandon Williams >Cc=A0: tcpm@ietf.org >Objet=A0: Re: [tcpm] New Version Notification for draft-williams-exp-tcp- >host-id-opt-00.txt > >Interactions with other options needs to be discussed, esp. impact on >option order, processing order, and whether multiples of the same option >are even permitted. > >Joe > >On 1/21/2014 7:29 AM, Scharf, Michael (Michael) wrote: >> As a side note, you may also want to consider what happens if the same >packet hits two of the intended use cases at the same time. For instance, >what happens if a residential NAT adds a host ID and the packet then gets >routed over an overlay? Then the same option could appear twice in the >packet, right? (If option space permits this.) >> >> Michael >> >> >> >>> -----Original Message----- >>> From: Brandon Williams [mailto:brandon.williams@akamai.com] >>> Sent: Tuesday, January 21, 2014 3:51 PM >>> To: Scharf, Michael (Michael) >>> Cc: tcpm@ietf.org >>> Subject: Re: [tcpm] New Version Notification for draft-williams-exp- >>> tcp-host-id-opt-00.txt >>> >>> Yes, both the topics of continued experimentation and important use >>> cases clearly need some discussion in the document. We will attempt to >>> clarify both of these in the next version of the document. Since this >>> option format is meant to be a unified replacement for the three >>> previous independent specifications, it would probably also be good for >>> us to add a section that describes how this option could be used to get >>> the functionality of each of the three options that it replaces. >>> >>> --Brandon >>> >>> On 01/15/2014 05:37 PM, Scharf, Michael (Michael) wrote: >>>> Could the authors perhaps provide some additional explanation about >>> this "continued experimentation" that is apparently planned with draft- >>> williams-exp-tcp-host-id-opt? Personally, I do not follow any NAT work >>> in the IETF, and this may apply to other TCPM contributors as well. So >>> it seems to me like a valid question that could facilitate the >>> discussion. >>>> >>>> Regarding the overlay use case, I recall some explanation of draft- >>> williams-overlaypath-ip-tcp-rfc on this list, but the option format now >>> changed, and I wonder whether this change would affect experiments. >>> (Also, enabling interoperable implementations in the Internet could >>> require a specification of the content, which only draft-williams- >>> overlaypath-ip-tcp-rfc provides.) >>>> >>>> Other potential use cases are apparently documented e.g. in draft- >>> boucadair-intarea-host-identifier-scenarios-03, but this draft has >>> expired, and it is basically a survey. >>>> >>>> Given that all these topics are outside the typical focus of TCPM, I >>> think it could be useful to provide some background to this group. >>> Specifically, I wonder about pointers to running code and details >>> regarding planned use of draft-williams-exp-tcp-host-id-opt in real- >>> world experiments. >>>> >>>> Thanks >>>> >>>> Michael >>>> >>>> ________________________________________ >>>> Von: tcpm [tcpm-bounces@ietf.org]" im Auftrag von "Brandon >>> Williams [brandon.williams@akamai.com] >>>> Gesendet: Mittwoch, 15. Januar 2014 16:27 >>>> An: Joe Touch; Eggert, Lars; Wesley Eddy >>>> Cc: tcpm@ietf.org >>>> Betreff: Re: [tcpm] New Version Notification for draft- >>> williams-exp-tcp-host-id-opt-00.txt >>>> >>>> I think you've captured our intent fairly well. This is an attempt to >>>> solve a problem introduced by the use of address sharing. We have no >>>> illusion that the proposed solution is elegant. There certainly are >>>> issues associated with the approach, especially when applied by an >>>> in-path NAT device. That said, all potential solutions to this >>> problem >>>> set have issues. The purpose of the I.D. is to help us better >>> evaluate >>>> this specific proposed solution. >>>> >>>> Regarding the representation of RFC6967, it was not our intent to >>>> indicate that the RFC "recommends" the TCP option over other options, >>>> nor to minimize the concerns raised about the approach in that RFC. I >>> do >>>> think that "can be successfully applied to a broad range of use cases >>>> with limited performance impact" is a fair representation of the tcp >>>> option solution analysis in section 5 of RFC6967. All we're really >>>> trying to indicate is that the RFC seems to justify continued >>>> experimentation in order to better evaluate whether this approach >>> adds >>>> enough value to outweigh the shortcomings. We'll attempt to clarify >>> our >>>> intent in the next revision. >>>> >>>> --Brandon >>>> >>>> On 01/14/2014 05:56 PM, Joe Touch wrote: >>>>> >>>>> >>>>> On 1/14/2014 7:34 AM, Eggert, Lars wrote: >>>>>> On 2014-1-14, at 14:54, Wesley Eddy wrote: >>>>>>> I think we should not proceed at all on this. >>>>>>> Intermediate devices shouldn't play with TCP options. >>>>>>> My guess is that there may even be strong consensus on this. >>>>>> >>>>>> Fully agreed. >>>>>> >>>>>> Lars >>>>> >>>>> I'm confused about the concern. >>>>> >>>>> Although I completely agree that intermediate devices shouldn't play >>>>> with TCP options, they already DO play with TCP fields that they >>>>> shouldn't - e.g., NATs change IP source address and port numbers. >>>>> >>>>> AFAICT, this document's intent in using intermediate devices is to >>> have >>>>> the NAT preserve some variant/derivative of the origin IP >>> address/port >>>>> info, i.e., so the receiving system can (if it wants) determine the >>>>> difference between different origin hosts vs. different connections >>> from >>>>> the same origin host, even when all are behind a NAT. >>>>> >>>>> I agree it's ugly, but it seems that having NATs is what creates the >>>>> ugliness. NATs need to do one of two things, and neither one is >>>>> architecturally more corrrect: >>>>> >>>>> 1. enforce the notion that they are the single address for >>>>> all hosts behind them >>>>> >>>>> 2. allow different hosts behind them to be exposed as such >>>>> >>>>> So while I agree that a generic intermediate device should NEVER do >>>>> this, IMO a NAT doing this is different - it's more like cleaning up >>> a >>>>> problem it creates, vs. making things worse. >>>>> >>>>> My conclusion is that ONLY devices that change IP source addresses >>>>> and/or ports MAY do this (and only devices that add the option >>> should >>>>> ever remove it, e.g. in the reverse direction), but other >>> intermediate >>>>> devices MUST NOT change these values. >>>>> >>>>> I don't agree that this is either an elegant, appropriate, or >>> necessary >>>>> solution. But it's not 'evil' for the reasons presented thus far. >>>>> >>>>> There are other issues, e.g., TCP-AO includes an experimental NAT >>>>> variant that this is incompatible with, but we can discuss those if >>> this >>>>> becomes a WG doc. >>>>> >>>>> Joe >>>>> >>>>> PS - IMO, this document misrepresents the contents of RFC6967 in its >>> intro: >>>>> >>>>> [RFC6967] provides analysis of various solutions to the >>> problem of >>>>> revealing the sending hosts's identifier (HOST_ID) information >>> to the >>>>> receiver, which indicates that a solution using a TCP >>> [RFC0793] >>>>> option for this purpose can be successfully applied to a broad >>> range >>>>> of use cases with limited performance impact. >>>>> >>>>> RFC6967 never says that the TCP solution can be successful in the >>> way >>>>> claimed; in fact, it lists a large number of issues with a TCP >>> solution. >>>>> >>>>> RFC6967 didn't recommend a solution: >>>>> >>>>> This document analyzes a set of potential solutions for >>> revealing a >>>>> host identifier and does not recommend a particular solution, >>>>> although it does highlight the hazards of some approaches. >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> tcpm mailing list >>>>> tcpm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tcpm >>>>> >>>> >>>> -- >>>> Brandon Williams; Senior Principal Software Engineer >>>> Emerging Products Engineering; Akamai Technologies Inc. >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >>>> >>> >>> -- >>> Brandon Williams; Senior Principal Software Engineer >>> Emerging Products Engineering; Akamai Technologies Inc. >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www.ietf.org/mailman/listinfo/tcpm From mohamed.boucadair@orange.com Thu Jan 30 23:34:19 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6D11A04FA for ; Thu, 30 Jan 2014 23:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.548 X-Spam-Level: X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 KhmaW6ENul3r for ; Thu, 30 Jan 2014 23:34:17 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 61F3E1A0569 for ; Thu, 30 Jan 2014 23:34:16 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 730933B472A; Fri, 31 Jan 2014 08:34:12 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 54BF34C06B; Fri, 31 Jan 2014 08:34:12 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Fri, 31 Jan 2014 08:34:12 +0100 From: To: Yoshifumi Nishida , Brandon Williams Date: Fri, 31 Jan 2014 08:34:10 +0100 Thread-Topic: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt Thread-Index: Ac8XTt1rS6M5AygAQW6fJl2g2+2i+gHBZRjA Message-ID: <94C682931C08B048B7A8645303FDC9F36F48635038@PUEXCB1B.nanterre.francetelecom.fr> References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52D541B3.7000606@mti-systems.com> <98531DC4-272A-4110-A676-8613521E3FB7@netapp.com> <52D5C0AC.4080604@isi.edu> <52D6A8E8.6050307@akamai.com> <52D9B667.2060000@isi.edu> <52DB4EDB.4050208@mti-systems.com> <52DE977C.4060005@akamai.com> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36F48635038PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 07:34:20 -0000 --_000_94C682931C08B048B7A8645303FDC9F36F48635038PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Yoshifumi, Thank you for the comments. Please see inline. Cheers, Med De : tcpm [mailto:tcpm-bounces@ietf.org] De la part de Yoshifumi Nishida Envoy=E9 : mercredi 22 janvier 2014 09:49 =C0 : Brandon Williams Cc : tcpm@ietf.org Objet : Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host= -id-opt-00.txt Hi Brandon, I personally have the following comments on the draft. 1: It seems to me that the option format might be too simple to accommodate= multiple proposals. I'm not very sure how the receiver can identify which proposal has been= used. [Med] We have discussed that point among authors and we decided to not incl= ude a field to indicate what information is carried in the HOST_ID field (e= .g., IP address, port number, etc.) for following reasons: =B7 Cases where only a single identifier is required are more commo= n (i.e., the default behavior is to inject some bits of the internal IP add= ress in the HOST_ID field). =B7 Cases that require multiple identifiers to be included (e.g., s= ource IP address:source port number, or a list of IP addresses) are those w= here the same administrative entity is managing the entity that injects the= HOST_ID option and the one server that will make use of that option. A typ= ical use case is the load-balancing scenario. This point was recorded in the draft: "Note, there is no need to signal the semantic of the included data as this specification assumes the service is aware of that information by out of band means (e.g. both the service and the address sharing device are managed by the same administrative entity). " The beauty of advancing this effort in the experimental track is to assess = whether these assumptions are valid ones, identify whether there are use ca= ses which require a means to explicitly indicate the semantic of the includ= ed data, etc. 2: Section 4 seems to contain similar information on option usages which de= scribed in other detailed proposals. Isn't it a bit redundant? Or, is there any conflicts between the usages= in the draft and other proposals? [Med] One of the goals of this document is to have a unified specification = that would cover the use cases we have on the table. As such, this document= is self-contained. An implementor can develop the option specified in this= draft without reading the other proposals. 3: It seems to me that this draft describe basic framework and more detaile= d behavior and usages are described in each proposal. Can we proceed this d= raft without checking detailed behavior in other drafts? [Med] See above. Thanks, -- Yoshifumi On Tue, Jan 21, 2014 at 7:51 AM, Brandon Williams > wrote: I think we're in agreement about how difficult it may be to get this right = in a NAT environment. The spec already attempts to call out some of the iss= ues related to packet sizes and conflicts with other options, and we would = be happy to get some feedback about those parts of the document, since impr= oving the discussion of potential problems will be critical to further asse= ssment of the effectiveness (or lack thereof) of the solution. --Brandon On 01/18/2014 11:04 PM, Wesley Eddy wrote: On 1/17/2014 6:01 PM, Joe Touch wrote: FWIW, some other suggestions: - the info should only be added by a party that changes the IP header anyway, e.g., a NAT, or by the origin host it MUST NOT be added or modified en-route by a party that does not modify the IP header - the info SHOULD correlate to the IP header change - the info MUST be advisory only; e.g., as an optimization this is because the info isn't authenticated or protected from other on-path modification I could almost agree to that, except I think this is a bit beyond the typical NAT behavior (and potential harmfulness) because it's assuming: - there is actually room to add the option without impacting later use during the connection of other options - adding this option doesn't conflict with any other options Those points, I think, are troublesome for the general approach, and in my opinion, make it difficult to get right such that it won't ultimately create a headache N years later. -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --_000_94C682931C08B048B7A8645303FDC9F36F48635038PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Yos= hifumi,

 =

Thank you for the comments.

 

Plea= se see inline.

Cheers,

Med

<= span style=3D'font-size:10.0pt;font-family:"Courier New";color:#1F497D'> 

De&= nbsp;: tcpm [mailto:tcpm-bounces@ietf.org] De la part de Yoshifumi Nishida
Envoy=E9 : mercredi 22 janvier 2014 09:4= 9
=C0 : Brandon Williams
Cc : tcpm@ietf.orgObjet : Re: [tcpm] New Version Notification for draft-william= s-exp-tcp-host-id-opt-00.txt

 

Hi Brandon,

 

I personally have the following comments on the draft.=

 

1: It seems to me that the option format might be too simple = to accommodate multiple proposals. 

    I'm not very sure how the receiver can identify = which proposal has been used. 

<= span style=3D'font-size:10.0pt;font-family:"Courier New";color:#1F497D'>[Me= d] We have discussed that point among authors and we decided to not include= a field to indicate what information is carried in the HOST_ID field (e.g.= , IP address, port number, etc.) for following reasons:

=B7       &nb= sp; Cases where only a single identifier is= required are more common (i.e., the default behavior is to inject some bit= s of the internal IP address in the HOST_ID field). <= /p>

=B7        = Cases that require multiple identifiers to= be included (e.g., source IP address:source port number, or a list of IP a= ddresses) are those where the same administrative entity is managing the en= tity that injects the HOST_ID option and the one server that will make use = of that option. A typical use case is the load-balancing scenario.

This point was recorded in the draf= t:

 = 

“Note, there is =
no need

=A0=A0 to signal the semantic of the in= cluded data as this specification

=A0=A0 a= ssumes the service is aware of that information by out of band means

=A0=A0 (e.g. both the service and the address sh= aring device are managed by

<= b>=A0=A0 the sam= e administrative entity).

=  

“

The beauty of advancing this ef= fort in the experimental track is to assess whether these assumptions are v= alid ones, identify whether there are use cases which require a means to ex= plicitly indicate the semantic of the included data, etc. =A0  =   

 

2: Secti= on 4 seems to contain similar information on option usages which described = in other detailed proposals.

=     Isn't it a bit redundant? Or, is there any conflicts between = the usages in the draft and other proposals?

[Med] One of the goals of this document is to have a unified speci= fication that would cover the use cases we have on the table. As such, this= document is self-contained. An implementor can develop the option specifie= d in this draft without reading the other proposals.

    <= /p>

3: It seems to me that this draft descri= be basic framework and more detailed behavior and usages are described in e= ach proposal. Can we proceed this draft without checking detailed behavior = in other drafts?

[Med] See above.

 = ;

Thanks,

--

Yosh= ifumi

 

&nb= sp;

On Tue, Jan 21, 2014 at 7:51 AM, Bra= ndon Williams <brandon.williams@akamai.com> wrote:

I think we're in agreement about how difficult it may be to ge= t this right in a NAT environment. The spec already attempts to call out so= me of the issues related to packet sizes and conflicts with other options, = and we would be happy to get some feedback about those parts of the documen= t, since improving the discussion of potential problems will be critical to= further assessment of the effectiveness (or lack thereof) of the solution.=

--Brandon=



On 01/18/2014 11:04= PM, Wesley Eddy wrote:

On 1/17/2014 6:0= 1 PM, Joe Touch wrote:

FWIW, some other suggestions:

     - th= e info should only be added by a party that changes the
    &n= bsp;IP header anyway, e.g., a NAT, or by the origin host

  &nbs= p;  it MUST NOT be added or modified en-route by a party that does
=      not modify the IP header

     - t= he info SHOULD correlate to the IP header change

     = ;- the info MUST be advisory only; e.g., as an optimization

  &= nbsp;  this is because the info isn't authenticated or protected
&n= bsp;    from other on-path modification



I could almost agree to th= at, except I think this is a bit
beyond the typical NAT behavior (and po= tential harmfulness)
because it's assuming:

- there is actually r= oom to add the option without impacting
   later use during th= e connection of other options
- adding this option doesn't conflict with= any other options

Those points, I think, are troublesome for the ge= neral
approach, and in my opinion, make it difficult to get right
suc= h that it won't ultimately create a headache N years later.

<= p class=3DMsoNormal>
--

B= randon Williams; Senior Principal Software Engineer
Emerging Products En= gineering; Akamai Technologies Inc.

_______________________________________________
tcpm mailin= g list
tcpm@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/tcpm

 

= --_000_94C682931C08B048B7A8645303FDC9F36F48635038PUEXCB1Bnante_-- From martin.winbjork@ericsson.com Fri Jan 31 01:54:12 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13CC1A0388 for ; Fri, 31 Jan 2014 01:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.55 X-Spam-Level: X-Spam-Status: No, score=-3.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 TggLsFHHpF0Q for ; Fri, 31 Jan 2014 01:54:09 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1623F1A041B for ; Fri, 31 Jan 2014 01:54:08 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-ae-52eb72bcc8ca Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 97.E7.23809.CB27BE25; Fri, 31 Jan 2014 10:54:04 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.236]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0387.000; Fri, 31 Jan 2014 10:54:04 +0100 From: =?iso-8859-1?Q?Martin_Winbj=F6rk?= To: "tcpm@ietf.org" , "gorry@erg.abdn.ac.uk" , "arjuna@erg.abdn.ac.uk" , "raffaello@erg.abdn.ac.uk" Thread-Topic: Congestion Window Validation Thread-Index: Ac8eZm0Qam/kfKvTSX2+sAFlUYrUCA== Date: Fri, 31 Jan 2014 09:54:03 +0000 Message-ID: <7FD625EF1E1B1D4586EEAB7471ECDC0A1F85CA@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_7FD625EF1E1B1D4586EEAB7471ECDC0A1F85CAESESSMB109ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvje6eotdBBnuuWFs8uzCL2eJ122xG i7nvX7FYbDs5n8mBxaPn8wsmjyVLfjIFMEVx2aSk5mSWpRbp2yVwZTw+KlawWrNiw7xZTA2M Z5S7GDk5JARMJL6+62eGsMUkLtxbz9bFyMUhJHCIUeLKwUZmCGcJo8S50zfYQKrYBNwltqzo YwRJiAjsY5TY+eQzI0hCWEBV4tT31ewgtoiAlsTye5NZIGw9iVlLV7CC2CxANX86toLV8wp4 Szxu/wpWzwi0+vupNUwgNrOAuMStJ/OZIE4SkFiy5zzUeaISLx//A5rDAWQrSUzbmgZRni9x fNladoiRghInZz5hmcAoNAvJpFlIymYhKYOI60ncmDqFDcLWlli28DUzhK0rMePfIRZk8QWM 7KsY2XMTM3PSy402MQLj4+CW36o7GO+cEznEKM3BoiTO++Gtc5CQQHpiSWp2ampBalF8UWlO avEhRiYOTqkGxobJyb911bs7uXjUOYLznrN9XhFqznr++be9G6+ui9M8fC26Ma+Tb3Y59y6u VzkyJ7k/WoVw1Fosup0wMzyM/dhKp+TuufMCL+w4+Gmz+ceIib/ut7XP5BBLUfgYLdb+RqYt LnRFXY3No0dn9uh23tf3vchde8t7/rvJQQK6PJumVPKfKbssr8RSnJFoqMVcVJwIAL9ZGlVd AgAA Subject: [tcpm] Congestion Window Validation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 09:54:12 -0000 --_000_7FD625EF1E1B1D4586EEAB7471ECDC0A1F85CAESESSMB109ericsso_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello My name is Martin Winbj=F6rk and I am a student at Lule=E5 University of Te= chnology. I am currently writing my master thesis "TCP Optimized for Wirele= ss Access" at Ericsson in Sweden, Lule=E5. In the thesis I am evaluating di= fferent TCP enhancements and Congestion Window Validation is one of them. I have a question regarding section 4.4 on page 9 where it is stated "A cwn= d-limited sender uses the standard TCP method to increase cwnd (i.e. a TCP = sender that fully utilises the cwnd is permitted to increase cwnd each rece= ived ACK)." I don't fully understand when this scenario can occur in the no= n-validated phase? On the same page I found what appears to be two typos. "reducing the cwnd as defined in section 4.3.1" should be "reducing the cwn= d as defined in section 4.4.1"? "The resulting reduction of cwnd described in section 4.3.2 is appropriate,= since any accumulated path history is considered unreliable" should be "Th= e resulting reduction of cwnd described in section 4.4.2 is appropriate, si= nce any accumulated path history is considered unreliable"? I also have a request regarding an equation on page 11. May "cwnd =3D max(1/2*cwnd, IW)" have parentheses added around 1 / 2 for ad= ded clarity? Regards Martin Winbj=F6rk --_000_7FD625EF1E1B1D4586EEAB7471ECDC0A1F85CAESESSMB109ericsso_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello

 

My name is Martin Winbj=F6rk and I am a student at L= ule=E5 University of Technology. I am currently writing my master thesis &#= 8220;TCP Optimized for Wireless Access” at Ericsson in Sweden, Lule= =E5. In the thesis I am evaluating different TCP enhancements and Congestion Window Validation is one of them.

 

I have a question regarding section 4.4 on page 9 wh= ere it is stated “A cwnd-limited sender uses the standard TCP method = to increase cwnd (i.e. a TCP sender that fully utilises the cwnd is permitt= ed to increase cwnd each received ACK).” I don’t fully understand when this scenario can occur in the non-val= idated phase?

 

On the same page I found what appears to be two typo= s.

“reducing the cwnd as defined in section 4.3.1= ” should be “reducing the cwnd as defined in section 4.4.1̶= 1;?

“The resulting reduction of cwnd described in = section 4.3.2 is appropriate, since any accumulated path history is conside= red unreliable” should be “The resulting reduction of cwnd desc= ribed in section 4.4.2 is appropriate, since any accumulated path history is considered unreliable”?

 

I also have a request regarding an equation on page = 11.

May “cwnd =3D max(1/2*cwnd, IW)” have pa= rentheses added around 1 / 2 for added clarity?

 

Regards

Martin Winbj=F6rk

--_000_7FD625EF1E1B1D4586EEAB7471ECDC0A1F85CAESESSMB109ericsso_-- From tjw.ietf@gmail.com Fri Jan 31 03:20:53 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE101A0587 for ; Fri, 31 Jan 2014 03:20:53 -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 j2IfkGObu18c for ; Fri, 31 Jan 2014 03:20:49 -0800 (PST) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5A76B1A0586 for ; Fri, 31 Jan 2014 03:20:49 -0800 (PST) Received: by mail-qa0-f41.google.com with SMTP id w8so6070059qac.28 for ; Fri, 31 Jan 2014 03:20:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=aZz5JWLzTMa8JMo+skEKFUCxTm7vCYbJBiUcNVnSOPM=; b=EWKFwZrwsvmaSOQrQiVaAUK7dM5aylNckM2+RCWXcvZYZwciOVqM0I27T6ubIXH0tZ 7CJeLO6KUBvul+fDzPfsaXaZp1KA0N3JLXOSXpvkMzPlIwiOQA6k/fSXZKg/jYPi51e6 X6HFPzc113r/ot97Pd4ewHr7IzeEhmAz2zmXh779ZK7w+Bjiz6DmU7UeBL1Ow8ljZSLT K2jJaMmVJAM7PbR81ncEgyZzHaJJ8iIsKiAQ3yrvVwFA5DW1p5EpZSncupLjVeBZfRKo gE2xUswp7ikMOgbNYeTGQYXBuVz1QU0NDjyJK6a8aWo1bTGdiV6dyJEL7clCjgweW0mi FROQ== X-Received: by 10.229.7.133 with SMTP id d5mr30461605qcd.10.1391167245494; Fri, 31 Jan 2014 03:20:45 -0800 (PST) Received: from [10.33.0.160] ([204.14.236.215]) by mx.google.com with ESMTPSA id g52sm13075127qgg.9.2014.01.31.03.20.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Jan 2014 03:20:44 -0800 (PST) Message-ID: <52EB870C.1080100@gmail.com> Date: Fri, 31 Jan 2014 06:20:44 -0500 From: Tim Wicinski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: tcpm@ietf.org References: <7FD625EF1E1B1D4586EEAB7471ECDC0A1F85CA@ESESSMB109.ericsson.se> In-Reply-To: <7FD625EF1E1B1D4586EEAB7471ECDC0A1F85CA@ESESSMB109.ericsson.se> Content-Type: multipart/alternative; boundary="------------050603080301000303030502" Subject: Re: [tcpm] Congestion Window Validation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 11:20:53 -0000 This is a multi-part message in MIME format. --------------050603080301000303030502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit I contacted Martin, who confirmed he is referring to version 04 of the document: http://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv/ Comments inline: On 1/31/14, 4:54 AM, Martin Winbjörk wrote: > > Hello > > My name is Martin Winbjörk and I am a student at Luleå University of > Technology. I am currently writing my master thesis "TCP Optimized for > Wireless Access" at Ericsson in Sweden, Luleå. In the thesis I am > evaluating different TCP enhancements and Congestion Window Validation > is one of them. > > I have a question regarding section 4.4 on page 9 where it is stated > "A cwnd-limited sender uses the standard TCP method to increase cwnd > (i.e. a TCP sender that fully utilises the cwnd is permitted to > increase cwnd each received ACK)." I don't fully understand when this > scenario can occur in the non-validated phase? > > On the same page I found what appears to be two typos. > > "reducing the cwnd as defined in section 4.3.1" should be "reducing > the cwnd as defined in section 4.4.1"? > > "The resulting reduction of cwnd described in section 4.3.2 is > appropriate, since any accumulated path history is considered > unreliable" should be "The resulting reduction of cwnd described in > section 4.4.2 is appropriate, since any accumulated path history is > considered unreliable"? > I agree with Martin, it appears the sections were altered between draft-02 and draft-03 but the changes were not passed through the entire document. Additionally, at the bottom of Page 12 has a similar mention to section 4.3.2 which should be changed to 4.4.2 > I also have a request regarding an equation on page 11. > > May "cwnd = max(1/2*cwnd, IW)" have parentheses added around 1 / 2 for > added clarity? > I agree with his comments on the parentheses added around (1/2) in section 4.4.3, as this seems to be done elsewhere in the document as such. > Regards > > Martin Winbjörk > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --------------050603080301000303030502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I contacted Martin, who confirmed he is referring to version 04 of the document:
    http://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv/

Comments inline:

On 1/31/14, 4:54 AM, Martin Winbjörk wrote:

Hello

 

My name is Martin Winbjörk and I am a student at Luleå University of Technology. I am currently writing my master thesis “TCP Optimized for Wireless Access” at Ericsson in Sweden, Luleå. In the thesis I am evaluating different TCP enhancements and Congestion Window Validation is one of them.

 

I have a question regarding section 4.4 on page 9 where it is stated “A cwnd-limited sender uses the standard TCP method to increase cwnd (i.e. a TCP sender that fully utilises the cwnd is permitted to increase cwnd each received ACK).” I don’t fully understand when this scenario can occur in the non-validated phase?

 

On the same page I found what appears to be two typos.

“reducing the cwnd as defined in section 4.3.1” should be “reducing the cwnd as defined in section 4.4.1”?

“The resulting reduction of cwnd described in section 4.3.2 is appropriate, since any accumulated path history is considered unreliable” should be “The resulting reduction of cwnd described in section 4.4.2 is appropriate, since any accumulated path history is considered unreliable”?

 

I agree with Martin, it appears the sections were altered between draft-02 and draft-03 but the changes were not passed through the entire document.

Additionally, at the bottom of Page 12 has a similar mention to section 4.3.2 which should be changed to 4.4.2

I also have a request regarding an equation on page 11.

May “cwnd = max(1/2*cwnd, IW)” have parentheses added around 1 / 2 for added clarity?

 


I agree with his comments on the parentheses added around (1/2) in section 4.4.3, as this seems to be done elsewhere in the document as such.



Regards

Martin Winbjörk



_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

--------------050603080301000303030502--