Subject: [tcpm] Aid passive estimate of tcp performance

From: Ángel Bartomeu Bonillo <[email-masked]>
Date: Wed, 8 Feb 2012 13:15:32 +0100

Hello,

I recently faced the problem of passively estimating the packet loss of TCP connection. After a bit of investigating the literature I found that there are tens of papers addressing this issue but I couldn't find any perfect solution. 
Since this is an important issue for network operators I have been thinking that there would be a very easy solution by just making the two TCP connection end points to account for its sent segments and report it to the other end point in the FIN segment.
This approach could be used as well for other measurable parameters along the TCP session without the need for any other offline method and It would be very helpful for detecting failures along networks. 

Any comments?

Thanks for your time.

---

From: rick jones <[email-masked]>
Date: Wed, 08 Feb 2012 08:32:54 -0800

> This approach could be used as well for other measurable parameters along the TCP session without the need for any other offline method and It would be very helpful for detecting failures along net…

If the count is reported in a FIN segment, isn't that rather like closing the barn door after the horses have left?  At least as far as doing anything for that connection is concerned.  So, already we are talking about operating on timescales larger than connection lifetimes.  And what would the side receiving the count-containing FIN do with this information? Sure, now it is known on both ends, but the problem still lies somewhere in the middle (not always, but often).  Is it expected that points along the middle will be sniffing this?  What would they do in response?  What could they (reasonably) do in response with that information just from TCP vs any other transports?

When a sending TCP sends the first FIN with a count at the end of a MB window would it retransmit the FIN, even if the first was received, to include retransmissions in that last window's-worth of data?  How long would the receiving TCP wait for this "final tally, really" FIN to arrive after it sent the ACK to SEQfin to then pass-along the count to a higher layer, somehow?

I think we are already asking for enough angels to dance on the TCP pin-header.

rick jones

---

From: Yuchung Cheng <[email-masked]>
Date: Wed, 8 Feb 2012 08:43:11 -0800

I second that. Even TCP end host can not get this 100%: spurious
retransmission can not be perfectly detected w/ ack path loss for
instance.

On Wed, Feb 8, 2012 at 8:32 AM, rick jones <[email-masked]> wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Wed, 08 Feb 2012 09:45:43 -0800

On 2/8/2012 4:15 AM, Ángel Bartomeu Bonillo wrote:
> Hello,
>
> I recently faced the problem of passively estimating the packet loss
> of TCP connection. After a bit of investigating the literature I
> found that there are tens of papers addressing this issue but I
> couldn't find any perfect solution. Since this is an important issue
> for network operators I have been thinking that there would be a very
> easy solution by just making the two TCP connection end points to
> account for its sent segments and report it to the other end point in
> the FIN segment. This approach could be used as well for other
> measurable parameters along the TCP session without the need for any
> other offline method and It would be very helpful for detecting
> failures along networks.
>
> Any comments?

Regardless of when you do this - either at the end of a connection, or 
during a connection - the ONLY information you can provide is "here is a 
list of segments I have not yet received".

However, that list is irrelevant. Those segments might be in the network 
and may still arrive - after you report, after the connection is over, etc.

There is no way to KNOW that a segment is lost vs. late.

Even when you retransmit a segment (e.g., because it is basically 
overdue, either because your side's timer expired or the other side sent 
either a SACK or ACK indicating a gap), you don't know that the first 
segment was lost - it could arrive after the timer expires.

Even though segments have TTLs, and TTLs are *supposed* to be 
decremented once every second or once every hop (whichever is greater), 
there are devices that queue packets for long periods (e.g., when a link 
is interrupted) and send them on later (even though they should have 
been dropped).

So there is no such information as "lost segments"; the best you know is 
retransmissions.

However, keep in mind that there are lots of TCP connections that are 
terminated without a FIN (e.g., using a RST - I don't think it's 
appropriate in many cases, but the method is in widespread use).

Joe

---

From: Ángel Bartomeu Bonillo <[email-masked]>
Date: Wed, 8 Feb 2012 18:52:52 +0100

Hi Rick, 

> If the count is reported in a FIN segment, isn't that rather like closing the barn door after the horses have left?  At least as far as doing anything for that connection is concerned.  So, already…

I'm talking about timescales larger than the connection lifetimes. This would be a mechanism so TCP can report how many packets it sent out. If both ends send at the end of the session the number of packets they sent out the other peer and anyone in the middle would be able to estimate de loss in both directions.

The idea is to enable TCP so it can report a little but valuable information about its performance once the connection finished. This is not a mechanism so TCP can adapt to losses in the middle of a communication but rather a long term mechanism for network operators and such. Nowadays many of the end user services use TCP and the end to end packet loss is many times impossible to calculate mainly because only the sending node knows the real number of packets sent out. For example in the uplink direction on a mobile network.
I think that adding just a couple of bytes (as a TCP option) to the FIN segment would give a priceless information for network operators.

> When a sending TCP sends the first FIN with a count at the end of a MB window would it retransmit the FIN, even if the first was received, to include retransmissions in that last window's-worth of…

The idea much simpler: the peer adds the num of packets sent during the connection as an option in the FIN. There is no need to change TCP behavior.

---

From: "Smith, Donald" <[email-masked]>
Date: Wed, 8 Feb 2012 11:05:55 -0700

Just agreeing with Joe, Many applications uses resets instead of a FIN handshake to terminate connections to speed things up especially browsers.

http://pages.cpsc.ucalgary.ca/~carey/papers/2005/TCP-Resets.pdf

When packets collide the controllers cease transmission AND wait a random time before retransmission (mostly)!
[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Joe Touch
> Sent: Wednesday, February 08, 2012 10:46 AM
> To: Ángel Bartomeu Bonillo
> Cc: [email-masked]
> Subject: Re: [tcpm] Aid passive estimate of tcp performance
>
>
>
> found
> > that there are tens of papers addressing this issue but I couldn't
> > find any perfect solution. Since this is an important issue for
> > network operators I have been thinking that there would be a very
> easy
> > solution by just making the two TCP connection end points to account
> > for its sent segments and report it to the other end point in the FIN
> > segment. This approach could be used as well for other measurable
> > parameters along the TCP session without the need for any other
> > offline method and It would be very helpful for detecting failures
> > along networks.
> >
> > Any comments?
>
> during a connection - the ONLY information you can provide is "here is
> a list of segments I have not yet received".
>
> However, that list is irrelevant. Those segments might be in the
> network and may still arrive - after you report, after the connection
> is over, etc.
>
> overdue, either because your side's timer expired or the other side
> sent either a SACK or ACK indicating a gap), you don't know that the
> first segment was lost - it could arrive after the timer expires.
>
> there are devices that queue packets for long periods (e.g., when a
> link is interrupted) and send them on later (even though they should
> have been dropped).
>
> So there is no such information as "lost segments"; the best you know
> is retransmissions.
>

This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 8 Feb 2012 18:15:58 +0000

> I'm talking about timescales larger than the connection lifetimes. This would be a mechanism so TCP can report how many packets it sent out. If both ends send at the end of the session the number o…

You might want to take a look at what the CONEX WG is trying to do: https://datatracker.ietf.org/wg/conex/charter/

Lars

---

From: Mark Allman <[email-masked]>
Date: Wed, 08 Feb 2012 13:08:01 -0500

I agree with Rick and the others.  This doesn't seem terribly useful.

> > When a sending TCP sends the first FIN with a count at the end of a
> > MB window would it retransmit the FIN, even if the first was
> > received, to include retransmissions in that last window's-worth of
> > data?  How long would the receiving TCP wait for this "final tally,
> > really" FIN to arrive after it sent the ACK to SEQfin to then
> > pass-along the count to a higher layer, somehow? 
> 
> The idea much simpler: the peer adds the num of packets sent during
> the connection as an option in the FIN. There is no need to change TCP
> behavior.  

I believe what Rick was saying was that you send a ton of packets and
the last one has the FIN bit lit up.  At that point these packets have
no been ACKed.  So, lets say the last window is 100 packets, the 100th
packet has the FIN, and this makes 1000 packets in total the sender has
transmitted.  So, in the FIN we send "1000".  Now, say 10 of the final
100 packets are lost and we have to retransmit those 10 packets.  Now,
the real total number of transmissions is 1010 and the number we stuffed
in the FIN is wrong.  If we want to get that number right then maybe we
hold off on sending the FIN until the final 100 packets are ACKed
(including needed retransmits).  But, that is a change to TCP behavior.
I think that is a relevant example.

Several additional thoughts popped into my head ...

  - This is useless for the TCP connection.  So, what is the incentive
    to bother stuffing it in there?  Some warm and fuzzy lets help the
    operators notion?  I doubt it.

  - This is useless for the TCP connection and so it doesn't make a lot
    of sense to me to add complexity to TCP for no tangible benefit.

  - You are right that passive loss estimators are not "perfect".  But,
    I believe they get you reasonably close.  How "perfect" do you need
    to be for operational purposes?  My strong hunch is that the answer
    is "not perfect at all, the right order would be good".  I.e.,
    operators are going to make different decision when faced with loss
    rates of .1%, 1% and 10%.  But, they are likely going to do the same
    thing with loss rates of .8%, 1%, 1.5% and 2%.  Loss estimators are
    good enough to get you into that sort of ballpark.

  - If the endpoint will give you some information its for sure less
    work than doing the passive monitoring necessary.  But, I am not
    sure reducing some operators' complexity by adding complexity (even
    modestly) to TCP is the right tradeoff.

allman

---

From: Marco Mellia <[email-masked]>
Date: Wed, 8 Feb 2012 20:01:56 +0100

I just want to add that what the top stack sees today can be much different from what the network carries... just think of offloading engines that fool the OS declaring a mss MTU of 16kB, then chop the segments into many smaller ones. Or some nasty nat box, or some load balancer in front of some server farm...
that is, passive tools will have a better picture in those cases...

Inviato da iPad

---

From: Joe Touch <[email-masked]>
Date: Wed, 08 Feb 2012 10:56:51 -0800

> http://pages.cpsc.ucalgary.ca/~carey/papers/2005/TCP-Resets.pdf

It doesn't just "speed" things; it's reckless and dangerous, esp. since 
the parties tossing around these RSTs typically don't maintain TIME-WAIT 
before reusing those connection IDs.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 08 Feb 2012 11:00:02 -0800

Hi, all,

> that is, passive tools will have a better picture in those cases...

It's impossible to account for forgers; if a proxy terminates a 
connection for an IP address it doesn't own, all bets are off for active 
*and* passive analysis.

Joe

>
> Inviato da iPad
>
> Il giorno 08/feb/2012, alle ore 19:08, Mark Allman<[email-masked]>  ha scritto:
>
>>

---

From: Jim Gettys <[email-masked]>
Date: Wed, 08 Feb 2012 14:03:07 -0500

On 02/08/2012 01:56 PM, Joe Touch wrote:
>> Just agreeing with Joe, Many applications uses resets instead of a
>> FIN handshake to terminate connections to speed things up especially
>> browsers.
>>
>>
> It doesn't just "speed" things; it's reckless and dangerous, esp.
> since the parties tossing around these RSTs typically don't maintain
> TIME-WAIT before reusing those connection IDs.

Joe, browsers have done this forever.

If you don't like it, then it's (long past time) to make the case that
they should change their behaviour.
                        - Jim

>> This communication is the property of CenturyLink and may contain
>> confidential or privileged information. Unauthorized use of this
>> communication is strictly

---

From: Joe Touch <[email-masked]>
Date: Wed, 08 Feb 2012 11:08:51 -0800

Jim,

Routers have been over-buffering forever too. Yet you continue to want 
to get them to change things and correctly implement the standards.

That's what I want for endpoints with TCP too.

Ignorance or deliberate defiance is not an excuse. These are errors that 
need to be corrected, since they have real implications throughout the 
network, both for users on those systems and those that share those 
addresses (e.g., behind shared NATs or proxies).

Joe

---

From: Jim Gettys <[email-masked]>
Date: Wed, 08 Feb 2012 14:20:39 -0500

On 02/08/2012 02:08 PM, Joe Touch wrote:
> Ignorance or deliberate defiance is not an excuse. These are errors
> that need to be corrected, since they have real implications
> throughout the network, both for users on those systems and those that
> share those addresses (e.g., behind shared NATs or proxies).

Over the years, I have noted a distinct lack of communications between
those who understand how the bits flow, and how they are used....  For
example, the transient bufferbloat phenomena is something that is pretty
obvious to those who understand TCP, and completely unobvious to most
who do web browsers...

I believe both groups need to talk to each other, strangely.  Sometimes
you may find that the guys who do the applications actually have needs
not being met by standards, that are well worth understanding; and
conversely, the guys who do the apps may find that life is better for
both them and others if they understand the standards.

Just go in with an open mind and say: "We observe the browsers/servers
doing the following thing that we believe is much less than optimal, why
are you doing this?" rather than "You are disobeying the rules, fix it",
and I think you'll get a warm welcome.
                - Jim

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 8 Feb 2012 11:39:15 -0800

Well,
   Some assumptions that existed long ago, are no longer serious or may be not hold good for the modern internet. Lets take the example of TIMEWAIT state which you mention below.  RFC recommends 2*MSL which translates to 4 mins. Many OS'es (Windows, Linux ) and Cisco IOS etc., have configurable knobs to tune this value to anywhere between 30 secs to 240 secs.
   Lets take up the initial window case, it was 1 segment 30 years ago, got increased to 3 segments and now it's on it way to hit the 10 segments mark.  So things keep changing and the "degree of conservatism" changes to adopt to the current internet.
   So, you just can't say these are erroneous or mis-interpretations, it is just the way things have moved on (IMO for good in most cases)
-Anantha 

> Sent: Wednesday, February 08, 2012 11:09 AM
> To: Jim Gettys
> Cc: [email-masked]'
> that

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 8 Feb 2012 12:01:20 -0800

+ 1

> and I think you'll get a warm welcome.

We have been through this before it is sad that some folks use the
argument of "there is a high bar for changing TCP" and try to bury ideas
which have not been standaridized and have not given a chance to get
standardized. Linux TCP has many things (good) which are not IETF
standards. Of course other OS'es as well.

I am afraid all these are a result of the latter attitude. I thought a
few times before writing this email, but alas I have a better feeling
now even though in some sense it is a repeat and a viewpoint which is
shared by a considerable number of folks.

-Anantha

---

From: Joe Touch <[email-masked]>
Date: Wed, 08 Feb 2012 12:54:07 -0800

On 2/8/2012 11:39 AM, Anantha Ramaiah (ananth) wrote:
> Well,
> Some assumptions that existed long ago, are no longer serious or may
> be not hold good for the modern internet.

Where that's true, it's worth re-examining.

 > Lets take the example of
> TIMEWAIT state which you mention below. RFC recommends 2*MSL which
> translates to 4 mins. Many OS'es (Windows, Linux ) and Cisco IOS etc.,
> have configurable knobs to tune this value to anywhere between 30 secs
> to 240 secs.

It's worth understanding why. It's not with a sense that this was safe 
per-se; it was a sense of improving performance. That's a bad reason to 
make a change, especially when it's ignorant of the rationale for the 
safety mechanism being avoided.

> Lets take up the initial window case, it was 1 segment 30 years ago,
> got increased to 3 segments and now it's on it way to hit the 10
> segments mark. So things keep changing and the "degree of conservatism"
> changes to adopt to the current internet.

Yes, and that was done by changing the specs.

> So, you just can't say these are erroneous or mis-interpretations,
> it is just the way things have moved on (IMO for good in most cases)

My specific experience is with the interaction between TCP and HTTP. 
HTTP was designed because of the ignorance of the rationale of the 
design of FTP - notably that it wasn't useful to open two connections to 
get a file when only one file per location would be useful (this is 
paraphrased from Berners-Lee's original papers). HTTP incurred long 
(200ms) delays when first deployed because of a similar ignorance about 
how application protocols interact with TCP - that interactive protocols 
with multi-byte exchanges must have Nagle off.

There is a similar issue with RSTs. They're useful to terminate 
connections when that is the desired intent - an abort. However, they're 
overused by browsers for other reasons - e.g., when switching pages.

There are reasons to change TCP, and to have it evolve; there are also 
reasons to find and declare variations "non-compliant" bugs and fix 
them. The distinction should be made with a full understanding of what 
TCP is *already* capable of, and the implications of these changes.

Joe

---

From: "Smith, Donald" <[email-masked]>
Date: Wed, 8 Feb 2012 14:50:31 -0700

> Sent: Wednesday, February 08, 2012 1:54 PM
> To: Anantha Ramaiah (ananth)
> Cc: [email-masked]
It depends on what you mean by safe. If your trying to survive a ddos attack making those timers very low helps quite a bit and doesn't seem to affect the clients.

In what transport today does a open take more than a second or two?
Same for a close with FIN those normally complete in a second or two.
I realize some of these recommendations were written when a 4800baud was a high speed link.

I can see where a satalite bounce might take a few seconds but even that isn't measured in minutes.

If we made new recommendations (not changing ratios just changing the values by a factor of 10 or so) maybe we could convince the browser vendors and web server vendors to not use RESETS the way so many of them do today.

> > So, you just can't say these are erroneous or mis-interpretations, it
> > is just the way things have moved on (IMO for good in most cases)
>
> design of FTP - notably that it wasn't useful to open two connections
> to get a file when only one file per location would be useful (this is
> how application protocols interact with TCP - that interactive
> protocols with multi-byte exchanges must have Nagle off.
>
> connections when that is the desired intent - an abort. However,
> they're overused by browsers for other reasons - e.g., when switching
> pages.
>
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> >> Of Joe Touch
> >> Routers have been over-buffering forever too. Yet you continue to
> >> want to get them to change things and correctly implement the
> standards.
> >>
> >> throughout the network, both for users on those systems and those
> >> that share those addresses (e.g., behind shared NATs or proxies).
> >>
> >> Joe
> >>
> >>>> since the parties tossing around these RSTs typically don't
> >>>> maintain TIME-WAIT before reusing those connection IDs.
> >>>
> >>>>>>> for its sent segments and report it to the other end point in
> >>>>>>> the
> >> FIN
> >>>>>>> segment. This approach could be used as well for other
> >>>>>>> measurable parameters along the TCP session without the need
> for
> >>>>>>> any other offline method and It would be very helpful for
> >>>>>>> detecting
> >> failures
> >>>>>>> along networks.
> >>>>>>>
> >>>>>>> Any comments?
> >>>>>>
> >>>>>> there are devices that queue packets for long periods (e.g.,
> when
> >> a
> >>>>>> However, keep in mind that there are lots of TCP connections
> that
> >> are
> >>>>> communication is strictly prohibited and may be unlawful.  If you
> >>>>> have received this
> >> communication
> >>>>> in error, please immediately notify the sender by reply e-mail
> and
> >>>>> destroy all copies of the communication and any attachments.

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 8 Feb 2012 13:54:22 -0800

> From: Joe Touch [mailto:[email-masked]]
> Sent: Wednesday, February 08, 2012 12:54 PM
> Cc: Jim Gettys; [email-masked]

Many changes proposed to TCP are in the areas of improving TCP
performance, this one is no different. The reason you want to change
initial window to a larger value is to have a better throughput. The
reason you want to decrease TIMEWAIT value is to have more connections
per second without port contention issues. The rationale is similar in
both cases. Regarding your safety argument: having a timewait value of X
was considered safe ages ago, now having a lesser value is considered
safe, it is parameter change and every parameter change that affects TCP
and/or has other side effects needs to evaluated carefully. I don't see
any difference.

> they're

Well, I thought RST's original intent was to detect and recover from
half open connections (crash etc.,). RFC 793 does list abort as the user
interface to TCP, but it doesn't tell you when you should not use
abort's. (I can see that that are supplement documents that discuss
RST's like RFC 3360, which mainly talks about middleboxes inappropriate
usage of RST's, but I don't remember anybody mandating its (abort API)
use in one way or the other). Abort API evolved to be used in other
scenarios. You can't blame the implementations for that.

> TCP is *already* capable of, and the implications of these changes.

Agree.

-Anantha
> Joe

<snip>

---

From: "t.petch" <[email-masked]>
Date: Fri, 17 Feb 2012 16:46:40 +0100

----- Original Message -----
From: "Ángel Bartomeu Bonillo" <[email-masked]>
To: "rick jones" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, February 08, 2012 6:52 PM
Hi Rick,
El 08/02/2012, a las 17:32, rick jones escribió:

>> I recently faced the problem of passively estimating the packet loss of TCP
connection. After a bit of investigating the literature I found that there are
tens of papers addressing this issue but I couldn't find any perfect solution.
>> Since this is an important issue for network operators I have been thinking
that there would be a very easy solution by just making the two TCP connection
end points to account for its sent segments and report it to the other end point
in the FIN segment.
>> This approach could be used as well for other measurable parameters along the
TCP session without the need for any other offline method and It would be very
helpful for detecting failures along networks.
>>
>> Any comments?
>
> If the count is reported in a FIN segment, isn't that rather like closing the
barn door after the horses have left?  At least as far as doing anything for
that connection is concerned.  So, already we are talking about operating on
timescales larger than connection lifetimes.  And what would the side receiving
the count-containing FIN do with this information? Sure, now it is known on both
ends, but the problem still lies somewhere in the middle (not always, but
often).  Is it expected that points along the middle will be sniffing this?
What would they do in response?  What could they (reasonably) do in response
with that information just from TCP vs any other transports?

I'm talking about timescales larger than the connection lifetimes. This would be
a mechanism so TCP can report how many packets it sent out. If both ends send at
the end of the session the number of packets they sent out the other peer and
anyone in the middle would be able to estimate de loss in both directions.

The idea is to enable TCP so it can report a little but valuable information
about its performance once the connection finished. This is not a mechanism so
TCP can adapt to losses in the middle of a communication but rather a long term
mechanism for network operators and such. Nowadays many of the end user services
use TCP and the end to end packet loss is many times impossible to calculate
mainly because only the sending node knows the real number of packets sent out.
For example in the uplink direction on a mobile network.
I think that adding just a couple of bytes (as a TCP option) to the FIN segment
would give a priceless information for network operators.

<tp>
Apologies for being late to the party but I think that it is a lovely idea.  As
has been pointed out, the figures that you would collect are not what you want,
but they would be a lot closer than anything available at the moment, and that
is engineering.  Ditto comments about RST; if there is a positive benefit to
shutting down properly and getting these figures, then that could discourage
RSTs.

Tom Petch
<tp>

> When a sending TCP sends the first FIN with a count at the end of a MB window
would it retransmit the FIN, even if the first was received, to include
retransmissions in that last window's-worth of data?  How long would the
receiving TCP wait for this "final tally, really" FIN to arrive after it sent
the ACK to SEQfin to then pass-along the count to a higher layer, somehow?

The idea much simpler: the peer adds the num of packets sent during the
connection as an option in the FIN. There is no need to change TCP behavior.

---

From: Ángel Bartomeu Bonillo <[email-masked]>
Date: Mon, 20 Feb 2012 17:30:51 +0100

Hi Tom.
What you say was my original point. However I have been overwhelmed by the amount of drawbacks pointed out by the other folks. 
My idea was to enable TCP to give a little report at the end of the session. This report should be concise and simple. Just accounting for any interesting parameters that are either difficult or impossible to be obtained without an explicit procedure. I was thinking about the estimate of the packet loss but I was hopping that other (more expert people) would find any other interesting usages. 
However, as I said, I think there have been too much negative feedback on this idea so far. 

What does everyone think?
Should we give up with this issue?

Thank you all.

---

From: "SCHARF, Michael" <[email-masked]>
Date: Mon, 20 Feb 2012 18:19:01 +0100

Hi Angel,

> What you say was my original point. However I have been 
> overwhelmed by the amount of drawbacks pointed out by the 
> other folks. 

Well, please note that TCP is not a trivial protocol. Even ideas that appear to be trivial at first sight may require a careful analysis. This is what the TCPM working group is about.

> My idea was to enable TCP to give a little report at the end 
> of the session. This report should be concise and simple. 
> Just accounting for any interesting parameters that are 
> either difficult or impossible to be obtained without an 
> explicit procedure. I was thinking about the estimate of the 
> packet loss but I was hopping that other (more expert people) 
> would find any other interesting usages. 

My own view is that a gap analysis of the existing solutions would be a good starting point.

For instance, Section 5.10.14 in RFC 5102 apparently mentions a way to export the total number of dropped packets by IPFIX, on a per-flow basis (I am not familiar with IPFIX, so sorry if I miss something fundamental). Potential related work in CONEX has already been mentioned as well. We probably should better understand if another TCP option offers a significant benefit compared to that, and in what cases.

> Should we give up with this issue?

Just to mention something obvious: The other alternative would be to put together an Internet Draft that addresses the issues already mentioned on the list.

Michael

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Mon, 20 Feb 2012 09:39:25 -0800

Angel:

This is just my opinion. I wrote something earlier then withdrew it based on a lot of email churn on this topic.

I agree that this is not a bad idea. However to make it work, you do need some TCP changes like :-
- having a TCP option to agree upon this reporting between the connection end points.
- at the end of the TCP connection ( be it RST or FIN) you need some clear cut ways to exchange the report.
This would need some changes to TCP. 
- Atleast in the RST case, (nothing prevents from the sender to put some information in the RST data portion) FWIW, RFC 793 says RST segments can contain data. RST becomes a best effort since RST segments can be lost. 
- FIN case, you need to account for data in the flight and send the report only when all the data has been acknowledged.

Also questions like :-
- do you want to send this report during the end OR anytime during the lifetime of a connection?
- do you want the active closer to send this report OR it could be sent by a both ends?
- There are many existing mechanisms that can be useful to obtain the similar information which you are looking for, like :-
 In cases where it is feasible, active performance methods like the one outlined in RFC 6349 can be used (several programs like TTCP, iPerf etc.,  are there and can be useful), SNMP is often used to monitor the connection characteristics, IPSLA (TWAMP is the equivalent IETF proposal) is often used by network operators to measure network characteristics. Poor man's version is to have a socket option which would make TCP dump the connection block before the TCB gets freed (which should include everything other than just packet counts), which is purely local but useful.

I just saw an email from Michael suggesting to write an ID, may be that is a good starting point if you are planning to take this effort seriously. Atleast the draft should have the use case clearly outlined and the reasons why the existing mechanisms aren't good enough. 

Thanks,
-Anantha

> Ángel Bartomeu Bonillo
> Sent: Monday, February 20, 2012 8:31 AM
> To: t.petch
> Cc: [email-masked]
> What you say was my original point. However I have been overwhelmed by
> the amount of drawbacks pointed out by the other folks.
> My idea was to enable TCP to give a little report at the end of the
> session. This report should be concise and simple. Just accounting for
> any interesting parameters that are either difficult or impossible to
> be obtained without an explicit procedure. I was thinking about the
> estimate of the packet loss but I was hopping that other (more expert
> people) would find any other interesting usages.
> MB window

---

From: rick jones <[email-masked]>
Date: Mon, 20 Feb 2012 09:53:28 -0800

On Feb 20, 2012, at 9:39 AM, Anantha Ramaiah (ananth) wrote:
> In cases where it is feasible, active performance methods like the one outlined in RFC 6349 can be used (several programs like TTCP, iPerf etc.,  are there and can be useful),

FWIW, netperf (2.5.0 and later) can, under Linux, report the retransmission statistics from a TCP_INFO getsockopt() and will do so for either end.  In this case I have Linux only at the far end, so I run a TCP_MAERTS test and report the "remote_transport_retrans"  using the output selectors (*)

$ ./netperf -l 20 -H <linuxbox> -t TCP_MAERTS -- -O throughput,remote_transport_retrans -s 1M
MIGRATED TCP MAERTS TEST from (null) (0.0.0.0) port 0 AF_INET to <linuxbox> () port 0 AF_INET : demo
Throughput Remote          
           Transport       
           Retransmissions 
                           
4.94       13              

happy benchmarking,

rick jones

(*) http://www.netperf.org/svn/netperf2/tags/netperf-2.5.0/doc/netperf.html#Omni-Output-Selection

MAERTS is STREAM spelled backwards and is a test where the netserver side sends to the netperf.

---

From: Alexander Zimmermann <[email-masked]>
Date: Mon, 20 Feb 2012 19:20:10 +0100

Am 20.02.2012 um 18:53 schrieb rick jones:

> FWIW, netperf (2.5.0 and later) can, under Linux, report the retransmission statistics from a TCP_INFO getsockopt() and will do so for either end.

For the sake of completeness flowgrind (https://launchpad.net/flowgrind) can do this too :-)
See http://www.umic-mesh.net/research/flowgrind/output.html

Alex

//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// mobile: (49-176) 32820027, fax: (49-241) 80-22222
// email: [email-masked]
// web: http://www.umic-mesh.net
//

---

From: Ángel Bartomeu Bonillo <[email-masked]>
Date: Mon, 20 Feb 2012 19:20:34 +0100

Hi Michael.

> Well, please note that TCP is not a trivial protocol. Even ideas that appear to be trivial at first sight may require a careful analysis. This is what the TCPM working group is about.

Sure thing :)

> My own view is that a gap analysis of the existing solutions would be a good starting point.

I agree here too but, first of all, I would evaluate the the possible benefits of making TCP have its own report mechanism. 
Let's imagine there was a group of measurable parameters that are configurable in the handshake using an option. If both peer support them and are able to report them (or are configured to do so)  they would add this information in the FIN/RST, or maybe in some other point (I'm not sure about this).  

Now here is in my opinion the key questions: 

- would TCP benefit from the use of this in the long term? 
- If this report mechanism becomes usual, could it help, for example, to ease the research on future enhancements or changes to TCP?

> Just to mention something obvious: The other alternative would be to put together an Internet Draft that addresses the issues already mentioned on the list.

Since I'm a newbie here I will rely on the community for this.

---

From: rick jones <[email-masked]>
Date: Mon, 20 Feb 2012 11:26:24 -0800

> See http://www.umic-mesh.net/research/flowgrind/output.html

Excellent.  Looks like it goes rather farther than netperf in that area - reporting the TCP_INFO on the intervals.  Netperf only does it at the end of the test, and then only for retransmissions.

rick jones
there is no rest for the wicked, yet the virtuous have no pillows

---

From: Ángel Bartomeu Bonillo <[email-masked]>
Date: Tue, 21 Feb 2012 11:05:17 +0100

Hi Anantha.

> - having a TCP option to agree upon this reporting between the connection end points.

Yes. Like with the SACK option.

> - FIN case, you need to account for data in the flight and send the report only when all the data has been acknowledged.

I think that a approach could be next: 
Every peer reports the number of data segments sent out in the FIN segment.
Every peer reports the number of data segments received in the ACK to the FIN segment.

As for the RST, AFAIK it does not indicate a normal connection end so I think we should not consider that case. Also, as  Tom pointed out, it could discourage its use for ending connections.

> In cases where it is feasible, active performance methods like the one outlined in RFC 6349 can be used (several programs like TTCP, iPerf etc.,  are there and can be useful), SNMP is often used to…

The problem in this tools you mentioned is that they do active tests and you need to control both ends. If TCP would have it own report mechanism these tests would be much easier to do in a passive and more wide way.

> I just saw an email from Michael suggesting to write an ID, may be that is a good starting point if you are planning to take this effort seriously. Atleast the draft should have the use case clearl…

After hearing the community comments I'm not sure that just this would be worth the effort.  Also I'm not sure if Operating System would implement it by default. If not then it would become another iperf that you have to configure in both ends.

Do you think such a little tool would be worth it? Not just the effort but the fact of adding complexity to TCP.

However as I mentioned in a previous mail I was also thinking in a more generic and extensible report system in case we agree that it could benefit aid the monitor of TCP in a more generic way.

---

From: Ángel Bartomeu Bonillo <[email-masked]>
Date: Tue, 21 Feb 2012 11:25:39 +0100

Interesting tool Alexander.

> // web: http://www.umic-mesh.net

Este mensaje contiene información reservada y confidencial destinada exclusivamente al destinatario. Si usted no es el destinatario no está autorizado a copiar, reproducir o distribuir este mensaje ni su contenido. Si ha recibido este mensaje por error, le rogamos que nos lo notifique inmediatamente.
The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee(s). It may contain privileged and confidential information. If you are not the intended recipient, please destroy this message and notify us immediately. Any disclosure, copying or distribution of this message is prohibited and may be unlawful.

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Tue, 21 Feb 2012 08:42:28 -0800

> 
> Do you think such a little tool would be worth it? Not just the effort
> but the fact of adding complexity to TCP.
> 
> However as I mentioned in a previous mail I was also thinking in a more
> generic and extensible report system in case we agree that it could
> benefit aid the monitor of TCP in a more generic way.

RFC 6349 was about TCP performance benchmarking, the same rationale can be applied to this effort since it is related.. but the key difference is that this calls for some minor additions to TCP. I agree that it would be a useful thing if TCPM wants to look into it.

OTOH, I would think such an effort could fall into the jurisdiction of IPPM WG, but if it has TCP changes then it would anyways need to come to TCPM. 

-Anantha
> Of
> >> However, as I said, I think there have been too much negative
> feedback
> >> on this idea so far.
> >>
> >>> connection. After a bit of investigating the literature I found
> that
> >> there are
> >>> tens of papers addressing this issue but I couldn't find any
> perfect
> >> solution.
> >>>>> Since this is an important issue for network operators I have
> been
> >> thinking
> >>>>> This approach could be used as well for other measurable
> parameters
> >> along the
> >>> timescales larger than connection lifetimes.  And what would the
> side
> >> receiving
> >>> ends, but the problem still lies somewhere in the middle (not
> always,
> >> but
> >>> often).  Is it expected that points along the middle will be
> sniffing
> >> this?
> >>> the end of the session the number of packets they sent out the
> other
> >> peer and
> >>> TCP can adapt to losses in the middle of a communication but rather
> a
> >> long term
> >>> mainly because only the sending node knows the real number of
> packets
> >> sent out.
> >>> Apologies for being late to the party but I think that it is a
> lovely
> >> idea.  As
> >>> has been pointed out, the figures that you would collect are not
> what
> >> you want,
> >>> but they would be a lot closer than anything available at the
> moment,
> >> and that
> >>> retransmissions in that last window's-worth of data?  How long
> would
> >> the
> >>> receiving TCP wait for this "final tally, really" FIN to arrive
> after
> >> it sent
> >>>> I think we are already asking for enough angels to dance on the
> TCP
> >>> pin-header.
> >>>>
> >>>> rick jones
> >>>