Subject: [Iccrg] Call for Nominations: Applied Networking Research Prize 2013
From: [email-masked] (Eggert, Lars)
Date: Wed Sep 12 18:03:01 2012

CALL FOR NOMINATIONS:

           APPLIED NETWORKING RESEARCH PRIZE (ANRP) 2013

                      http://irtf.org/anrp

********************************************************************
***     Submit nominations for the 2013 award period of the      ***
***  Applied Networking Research Prize until November 30, 2012!  ***
***                                                              ***
***    (Please share this announcement with your colleagues.)    ***
********************************************************************

The Applied Networking Research Prize (ANRP) is awarded for recent
results in applied networking research that are relevant for
transitioning into shipping Internet products and related
standardization efforts. Researchers with relevant, recent results
are encouraged to apply for this prize, which will offer them the
opportunity to present and discuss their work with the engineers,
network operators, policy makers and scientists that participate in
the Internet Engineering Task Force (IETF) and its research arm, the
Internet Research Task Force (IRTF). Third-party nominations for this
prize are also encouraged. The goal of the Applied Networking
Research Prize is to recognize the best new ideas in networking, and
bring them to the IETF and IRTF especially in cases where they would
not otherwise see much exposure or discussion.

The Applied Networking Research Prize (ANRP) consists of:

 ? cash prize of $500 (USD)
 ? invited talk at the IRTF Open Meeting
 ? travel grant to attend a week-long IETF meeting (airfare, hotel,
   registration, stipend)
 ? recognition at the IETF plenary
 ? invitation to related social activities
 ? potential for additional travel grants to future IETF meetings,
   based on community feedback

The Applied Networking Research Prize will be awarded once per
calendar year. Each year, several winners will be chosen and invited
to present their work at one of the three IETF meetings during the
year.

HOW TO NOMINATE

Only a single person can be nominated for the award. The basis of the
nomination is a peer-reviewed, original journal, conference or
workshop paper they authored, which was recently published or
accepted for publication. The nominee must be one of the main authors
of the nominated paper. Both self nominations (nominating one?s own
paper) and third-party nominations (nominating someone else?s paper)
are encouraged.

The nominated paper should provide a scientific foundation for
possible future IETF engineering work or IRTF research and
experimentation, analyze the behavior of Internet protocols in
operational deployments or realistic testbeds, make an important
contribution to the understanding of Internet scalability,
performance, reliability, security or capability, or otherwise be of
relevance to ongoing or future IETF or IRTF activities.

Applicants must briefly describe how the nominated paper relates to
these goals, and are encouraged to describe how a presentation of
these research results would foster their transition into new IETF
engineering or IRTF experimentation, or otherwise seed new activities
that will have an impact on the real-world Internet.

The goal of the Applied Networking Research Prize (ANRP) is to foster
the transitioning of research results into real-world benefits for
the Internet. Therefore, applicants must indicate that they (or the
nominee, in case of third-party nominations) are available to attend
at least one of the year?s IETF meetings in person and in its
entirety.

Nominations must include:

 ? the name and email address of the nominee
 ? a bibliographic reference to the published (or accepted)
   nominated paper
 ? a PDF copy of the nominated paper
 ? a statement that describes how the nominated paper fulfills the
   goals of the award
 ? a statement about which of the year?s IETF meetings the nominee
   would be available to attend in person and in its entirety
 ? a brief biography or CV of the nominee
 ? optionally, any other supporting information (link to nominee?s
   web site, etc.)

Nominations are submitted via the submission site at
http://irtf.org/anrp/2013/. In exceptional cases, nominations may
also be submitted by email to [email-masked].

SELECTION PROCESS

A small selection committee comprised of individuals knowledgeable
about the IRTF, IETF and the broader networking research community
will evaluate the submissions against these selection criteria.

IMPORTANT DATES

Applications close: November 30, 2012 (hard)
Notifications:      December 20, 2012

SPONSORS

The Applied Networking Research Prize (ANRP) is supported by the
Internet Society (ISOC), as part of its Internet Research Award
Programme, in coordination with the Internet Research Task Force
(IRTF).

HELP PUBLICIZE THE ANRP

If you would like to help publicize the ANRP within your
organization, you are welcome to print and use the flyer at
http://irtf.org/anrp-2013-flyer.pdf

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4361 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20120912/759b3104/smime.bin

From: [email-masked] (Arjuna Sathiaseelan)
Date: Sat Sep  8 23:28:03 2012
Subject: [Iccrg] Re: Iccrg Digest, Vol 80, Issue 3
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hello Cheng,
 Check out the new-cwv draft that addresses the app-limited problem:
http://tools.ietf.org/html/draft-fairhurst-tcpm-newcwv-04

This draft has some major issues and we have got a new version which
is much more stable and will be submitted to ICCRG soon..

Regards
Arjuna

On 8 September 2012 12:01,  <[email-masked]> wrote:
> Send Iccrg mailing list submissions to
>         [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> or, via email, send a message with subject or body 'help' to
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Iccrg digest..."
>
>
> Today's Topics:
>
>    1. Re: [tcpm] RFC5681: why halving FlightSize not cwnd?
>       (Yuchung Cheng)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 7 Sep 2012 15:49:01 -0700
> From: Yuchung Cheng <[email-masked]>
> Subject: [Iccrg] Re: [tcpm] RFC5681: why halving FlightSize not cwnd?
> To: [email-masked]
> Cc: "[email-masked] Extensions" <[email-masked]>, "[email-masked]
>         list" <[email-masked]>
> Message-ID:
>         <CAK6E8=[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> I am glad we all identify the problem about FlightSize. We need a
> better mechanism to address application-limited cases, i.e., when cwnd
> is not fully used recently.
>
> within an RTT or so:
> a) loss: halve cwnd or flightsize or something else?
> b) no-loss: grow cwnd or not?
>
> longer than several RTTs (idle)
> c) decay the cwnd every couple minutes or every couple RTO, slow-start
> to prev cwnd, blah?
>
> There is always a concern about potential bursts leaving cwnd >>
> FlightSize. So RFCs and implementations drag cwnd to "moderate"
> potential bursts. For example, Linux pulls cwnd down to FlightSize +
> epsilon whenever an ACK does not look right, and refuses to grow cwnd
> unless it was fully used. And most congestion control design does not
> consider these events.
>
> I don't know what the right solution is yet. Pacing + track inflight
> of last RTT?
>
> but I know app-limited cases happen a whole lot today. Beside HTTP or
> RPCs (in data centers), even video deliveries are interactive, e.g.,
> NetFlix or Youtube. The apps pace at second(s) interval to conserve
> network bandwidth. And TCP-smart apps all use persistent connections
> today. TCP usage has moved away from bulk-ftp long time...
>
> Yuchung
>
>
>
> ------------------------------
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
>
> End of Iccrg Digest, Vol 80, Issue 3
> ************************************

From: [email-masked] (Yuchung Cheng)
Date: Fri Sep  7 23:49:35 2012
Subject: [Iccrg] Re: [tcpm] RFC5681: why halving FlightSize not cwnd?
In-Reply-To: <[email-masked]>
References: <CAK6E8=[email-masked]> <[email-masked]> <[email-masked]> <CAH56bmDP5YwGqpfDQ5=OGceohx+xrsoOSDkd7RZHg7O=V=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <CAK6E8=[email-masked]>

I am glad we all identify the problem about FlightSize. We need a
better mechanism to address application-limited cases, i.e., when cwnd
is not fully used recently.

within an RTT or so:
a) loss: halve cwnd or flightsize or something else?
b) no-loss: grow cwnd or not?

longer than several RTTs (idle)
c) decay the cwnd every couple minutes or every couple RTO, slow-start
to prev cwnd, blah?

There is always a concern about potential bursts leaving cwnd >>
FlightSize. So RFCs and implementations drag cwnd to "moderate"
potential bursts. For example, Linux pulls cwnd down to FlightSize +
epsilon whenever an ACK does not look right, and refuses to grow cwnd
unless it was fully used. And most congestion control design does not
consider these events.

I don't know what the right solution is yet. Pacing + track inflight
of last RTT?

but I know app-limited cases happen a whole lot today. Beside HTTP or
RPCs (in data centers), even video deliveries are interactive, e.g.,
NetFlix or Youtube. The apps pace at second(s) interval to conserve
network bandwidth. And TCP-smart apps all use persistent connections
today. TCP usage has moved away from bulk-ftp long time...

Yuchung

From: [email-masked] (Michael Welzl)
Date: Fri Sep  7 08:34:55 2012
Subject: [Iccrg] Re: [tcpm] RFC5681: why halving FlightSize not cwnd?
In-Reply-To: <[email-masked]>
References: <CAK6E8=[email-masked]> <[email-masked]> <[email-masked]> <CAH56bmDP5YwGqpfDQ5=OGceohx+xrsoOSDkd7RZHg7O=V=[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi all,

Not too long ago, Yuchung pointed out a very similar problem to the one here with our own work, draft-hurtig-tcpm-rtorestart-02.txt, which intends to make the RTO timer more aggressive if the really used window is very small. We used FlightSize in our algorithm to represent this "really used window". As with RFC 5681, our rationale is that FlightSize captures the amount of data that is actually transmitted onto the network, which may be significantly smaller than cwnd if the sender is application-limited.

Yuchung has now shown us that this choice is bad, twice. FlightSize captures what we want, but additionally, a small FlightSize is also always reached towards the end of an arbitrarily large window (yes, this is also an application-limited case - it's about the difference between an application with a low constant sending rate and the end of a transfer (or, similarly, an application with a stop-and-go behavior)). Neither our draft nor RFC 5681 really captures this situation. Indeed, it seems to me the same problem appears in draft-fairhurst-tcpm-newcwv-03.txt, which also relies on FlightSize in a similar way:

Section 4.2:
***
      Non-validated phase: FlightSize <(2/3)*cwnd.  This is the phase
      where the cwnd has a value based on a previous measurement of the
      available capacity, and the usage of this capacity has not been
      validated in the previous RTT.
***

If FlightSize reaches this value at the end of a larger window, I think this statement is wrong. Indeed, in accordance with Yuchung's examples, this would make the mechanisms in this draft kick in every time at the end of e.g. a 20-packet-long web flow (or indeed at the end of any transfer, with arbitrary length). I don't think that's the intention?

I suspect that we can find more examples of RFCs or drafts with this issue. The problem is indeed more fundamental - as Matt said, we're using the wrong state variables. I can well imagine that the problem automatically disappears with TCP Laminar, but as a smaller update to existing / ongoing work, what we really need is probably a means to differentiate Yuchung's case from the case of concern in at least RFC 5681, draft-hurtig-tcpm-rtorestart and draft-fairhurst-tcpm-newcwv-03.txt.

Here's a simple suggestion: can we identify Yuchung's case by saying that FlightSize has been continuously decreasing?

Cheers,
Michael

On 7. sep. 2012, at 08:53, [email-masked] wrote:

> If FlightSize is not ~cwnd, then at the time, the flow is not fully
> utilising cwnd, but there are a wide range of (app) behaviours that result
> in this condition. My thoughts are that we should update the behaviour in
> both in standards-track TCP and also in Laminar.
> 
> This has been the topic of the new-cwv draft that we have been proposing
> as an update to TCP. It's been discussed on the ICCRG list, and we're
> re-structuring our draft and expect to publish this revision in a week or
> so.
> 
> Gorry
> 
> 
>> On Thu, Sep 6, 2012 at 2:25 PM, Ethan Blanton <[email-masked]>
>> wrote:
>>> Mark Allman spake unto us the following wisdom:
>>>> A few things ...
>>>> 
>>>>  - I don't buy Ethan's argument that the burden on the network is 4
>>>>    packets if you lose the 17th.  It seems to me the burden is
>>>> measured
>>>>    from the front of the window not the back.  So, in this case it was
>>>>    a burden of 17 packets that caused the loss.
>>> 
>>> Note that this was not intended to be my argument; my argument is that
>>> a TCP that doesn't "remember" such things (and 5681 does not) only
>>> knows about the 4 packets at the time of the loss, so it *thinks* the
>>> burden is 4.  This is clearly not optimal, and I would not argue that
>>> it is.  Perhaps I stated this poorly.
>> 
>> I would say that you are using the wrong state variables:  at this
>> point cwnd is simultaneously being used to suppress bursts and
>> remember the congestion state from before the application pause.   If
>> you parameterize it differently (e.g. Laminar) this becomes a
>> non-problem.
>> 
>>>>  - So, without additional schemes we're left with being too aggressive
>>>>    (using cwnd) or too conservative (using FlightSize).  But, if we're
>>>>    going to error that is probably the right direction.
>>> 
>>> Agreed.
>> 
>> Yes exactly.   One solution would be to pace from FS up to ccwind....
>> This case is described in the Laminar draft.
>> 
>>>>  - I probably would not have all that much heartburn making the
>>>>    ssthresh 10 in the case you describe as long as there was some
>>>>    knowledge that a cwnd of 20 was used recently.  I.e., it isn't the
>>>>    result of some large storage of permission to send that was built
>>>> up
>>>>    over time, but was in fact the result of the application's sending
>>>>    pattern.  I think one could design some rules around that notion
>>>>    that would be OK.
>>> 
>>> Also agreed.  I think it's reasonable to assume that the FlightSize in
>>> effect at the time a lost packet was *sent* is safe, for sure.
>> 
>> I point out this logic assumes that it was the instantaneous queue
>> length that triggered the losses (as it is for drop tail).  With RED
>> or CoDel, the losses are normally triggered by a persistent queue,
>> which may or may not depend on the instantaneous window at the time
>> the packet was either sent or received.   With CoDel, drops are
>> triggered when the minimum window size is still large enough to
>> sustain a queue....  The peak window has no effect on the drops
>> (unless the queue overflows).
>> 
>> Thanks,
>> --MM--
>> The best way to predict the future is to create it.  - Alan Kay
>> _______________________________________________
>> tcpm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tcpm
>> 
> 
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

From: [email-masked] (Mark Allman)
Date: Thu Sep  6 20:46:41 2012
Subject: [Iccrg] Re: [tcpm] RFC5681: why halving FlightSize not cwnd?
In-Reply-To: <CAK6E8=[email-masked]>
Message-ID: <[email-masked]>

A few things ...

  - I don't buy Ethan's argument that the burden on the network is 4
    packets if you lose the 17th.  It seems to me the burden is measured
    from the front of the window not the back.  So, in this case it was
    a burden of 17 packets that caused the loss.

  - The historical reason why we use FlightSize instead of cwnd is that
    cwnd was not always reflective of the burden placed on the network.
    For instance, some implementations just let the cwnd grow without
    bound regardless of whether it was used or not.  So, the cwnd might
    be (say) 100 even though you have never sent more than 20 segments
    per RTT when you go to set ssthresh.

  - (The note about the rwnd is not elegant!  All we mean is that the
    cwnd is growing without being used and, hey, it could even grow
    higher than the rwnd.  But, really who cares about the rwnd ... the
    point is that it grows unused and so is not reflective of anything.)
    
  - I may well buy that the current scheme leaves us too conservative
    due to cases like you sketch.  Exactly how important this case is
    I'll leave to you and Ethan to fight out! :-)

  - So, without additional schemes we're left with being too aggressive
    (using cwnd) or too conservative (using FlightSize).  But, if we're
    going to error that is probably the right direction.

  - I probably would not have all that much heartburn making the
    ssthresh 10 in the case you describe as long as there was some
    knowledge that a cwnd of 20 was used recently.  I.e., it isn't the
    result of some large storage of permission to send that was built up
    over time, but was in fact the result of the application's sending
    pattern.  I think one could design some rules around that notion
    that would be OK.

allman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20120906/e860829e/attachment.bin
>From [email-masked]  Thu Sep  6 23:05:32 2012
From: [email-masked] (Mark Allman)
Date: Thu Sep  6 22:58:09 2012
Subject: [Iccrg] Re: [tcpm] RFC5681: why halving FlightSize not cwnd?
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> Note that this was not intended to be my argument; my argument is that
> a TCP that doesn't "remember" such things (and 5681 does not) only
> knows about the 4 packets at the time of the loss, so it *thinks* the
> burden is 4.  This is clearly not optimal, and I would not argue that
> it is.  Perhaps I stated this poorly.

I agree with that.

allman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20120906/ed22f0ba/attachment.bin
>From [email-masked]  Thu Sep  6 23:50:34 2012
From: [email-masked] (Matt Mathis)
Date: Thu Sep  6 23:42:53 2012
Subject: [Iccrg] Re: [tcpm] RFC5681: why halving FlightSize not cwnd?
In-Reply-To: <[email-masked]>
References: <CAK6E8=[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <CAH56bmDP5YwGqpfDQ5=OGceohx+xrsoOSDkd7RZHg7O=V=[email-masked]>

On Thu, Sep 6, 2012 at 2:25 PM, Ethan Blanton <[email-masked]> wrote:
> Mark Allman spake unto us the following wisdom:
>> A few things ...
>>
>>   - I don't buy Ethan's argument that the burden on the network is 4
>>     packets if you lose the 17th.  It seems to me the burden is measured
>>     from the front of the window not the back.  So, in this case it was
>>     a burden of 17 packets that caused the loss.
>
> Note that this was not intended to be my argument; my argument is that
> a TCP that doesn't "remember" such things (and 5681 does not) only
> knows about the 4 packets at the time of the loss, so it *thinks* the
> burden is 4.  This is clearly not optimal, and I would not argue that
> it is.  Perhaps I stated this poorly.

I would say that you are using the wrong state variables:  at this
point cwnd is simultaneously being used to suppress bursts and
remember the congestion state from before the application pause.   If
you parameterize it differently (e.g. Laminar) this becomes a
non-problem.

>>   - So, without additional schemes we're left with being too aggressive
>>     (using cwnd) or too conservative (using FlightSize).  But, if we're
>>     going to error that is probably the right direction.
>
> Agreed.

Yes exactly.   One solution would be to pace from FS up to ccwind....
This case is described in the Laminar draft.

>>   - I probably would not have all that much heartburn making the
>>     ssthresh 10 in the case you describe as long as there was some
>>     knowledge that a cwnd of 20 was used recently.  I.e., it isn't the
>>     result of some large storage of permission to send that was built up
>>     over time, but was in fact the result of the application's sending
>>     pattern.  I think one could design some rules around that notion
>>     that would be OK.
>
> Also agreed.  I think it's reasonable to assume that the FlightSize in
> effect at the time a lost packet was *sent* is safe, for sure.

I point out this logic assumes that it was the instantaneous queue
length that triggered the losses (as it is for drop tail).  With RED
or CoDel, the losses are normally triggered by a persistent queue,
which may or may not depend on the instantaneous window at the time
the packet was either sent or received.   With CoDel, drops are
triggered when the minimum window size is still large enough to
sustain a queue....  The peak window has no effect on the drops
(unless the queue overflows).

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

From: [email-masked] (Yuchung Cheng)
Date: Thu Sep  6 20:25:52 2012
Subject: [Iccrg] Re: [tcpm] RFC5681: why halving FlightSize not cwnd?
In-Reply-To: <[email-masked]>
References: <CAK6E8=[email-masked]> <[email-masked]>
Message-ID: <CAK6E8=[email-masked]>

On Thu, Sep 6, 2012 at 12:08 PM, Ethan Blanton <[email-masked]> wrote:
> Yuchung Cheng spake unto us the following wisdom:
>> RFC 5681 specifically calls to use FlightSize instead of cwnd for cwnd
>> reduction.
>>
>> """When a TCP sender detects segment loss using the retransmission timer
>>    and the given segment has not yet been resent by way of the
>>    retransmission timer, the value of ssthresh MUST be set to no more
>>    than the value given in equation (4):
>>
>>       ssthresh = max (FlightSize / 2, 2*SMSS)            (4)
>>
>>    where, as discussed above, FlightSize is the amount of outstanding
>>    data in the network.
>>
>>    [...]
>>
>>    Implementation Note: An easy mistake to make is to simply use cwnd,
>>    rather than FlightSize, which in some implementations may
>>    incidentally increase well beyond rwnd.
>> """
>> When a sender sends cwnd==20 packets
>> a) fast-recovery: only 17th packet got dropped. FlightSize == 4
>> (pipe==1), ssthresh=2
>> b) timeout: 17-20th packets are dropped. FlightSize == 4(pipe==4), ssthresh=2
>
> Note that this is _only_ true if there were only 20 segments available
> to send.  Otherwise, by the time the dup ACKs for 17 come in, up to 32
> (remember ssthresh!) new segments would have been clocked out.  So
> your sender is either data-limited or protocol-limited or some such.
This is unfortunately the case of trillions of HTTP flows or any RPC
 interactive type traffic today. It's not a corner case.

>
> What that means is, in your scenario, where FlightSize == 4, at the
> time that packet 17 was dropped, your TCP's contribution to the
> network traffic was only 4 packets.  Therefore, as far as it can tell,
> a burden of 4 packets is "too much".

so if I send 100 packet (then stop) and only the last 1 got dropped. I
 should start from ssthresh == 2? isn't it more reasonable to assume
100 is too much, not 1 is too much?

then I am kinda unfortunate if the next some data is ready to send 1 RTT
after the one packet loss is recovered.

and I still don't get the rationale of rwnd argument in RFC 5681.

>
> Yes, this is over simple and probably not the case -- but we're also
> talking about a corner case, here.  Since you don't have any new data
> to send, anyway, you'll retransmit 17, get an ACK for 20, and close
> the connection or wait for new data or whatever.
>
> Ethan
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQEVAwUBUEj0tP8fixZ3H8crAQjFCgf/XRxoG+d3G1Hk7baB3tMht2Vgwx6VrTu/
> daL2bOLuabBjAySKUp1ouBtmaAJUs40Il1w9cdyQrcJ99NUxqpBywB2goLTxsdPQ
> xkdjzHXI52upeg2bgDBtamc7T+qsSiDkyCzNpWUG8FdPPAqC7lGoL0Xe8OlOFET5
> FfgeCH/K1Z+wsI05ykNe8Vv9Shx1/CJnWXjJ86DUNZl56qXqpENmLAvDdgQLe4AK
> H8BZgG6Ij66Vii8Al8Tu8ndK2HMMO8JnYIIEbj9gASHCusB2ZqdopA7xg8GCaMKM
> E641K5C5mRpyQE6yR/ORlE6xIL243ARsiM9Sfv0S30hoMmNn5ll71Q==
> =HJZ1
> -----END PGP SIGNATURE-----
>

From: [email-masked] (Yuchung Cheng)
Date: Thu Sep  6 19:35:18 2012
Subject: [Iccrg] RFC5681: why halving FlightSize not cwnd?
Message-ID: <CAK6E8=[email-masked]>

RFC 5681 specifically calls to use FlightSize instead of cwnd for cwnd
reduction.

"""When a TCP sender detects segment loss using the retransmission timer
   and the given segment has not yet been resent by way of the
   retransmission timer, the value of ssthresh MUST be set to no more
   than the value given in equation (4):

      ssthresh = max (FlightSize / 2, 2*SMSS)            (4)

   where, as discussed above, FlightSize is the amount of outstanding
   data in the network.

   [...]

   Implementation Note: An easy mistake to make is to simply use cwnd,
   rather than FlightSize, which in some implementations may
   incidentally increase well beyond rwnd.
"""
When a sender sends cwnd==20 packets
a) fast-recovery: only 17th packet got dropped. FlightSize == 4
(pipe==1), ssthresh=2
b) timeout: 17-20th packets are dropped. FlightSize == 4(pipe==4), ssthresh=2

As a result, the next transaction, e.g., an HTTP response, will almost
exit slow-start immediately and slowly increase cwnd per RTT. But
AFAIK, ssthresh is based on slow-start overshoot by half of cwnd (of
previous round trip), not current FlightSize.

This has been implicitly addressed in Laminar, but I want to call this
out b/c I don't understand the rwnd argument in RFC5681. As long as
the sender respects rwnd, what's the problem?

From: [email-masked] (Thomas Dreibholz)
Date: Tue Sep  4 22:58:51 2012
Subject: [Iccrg] Call for Papers of the PAMS 2013
Message-ID: <3989217.WYiQJ1v8uR@lupo>

We apologize if you receive multiple copies of this CFP.

CALL FOR PAPERS

The 3rd International Workshop on Protocols and Applications with Multi-Homing 
Support (PAMS 2013)
In conjunction with the 27th IEEE International Conference on Advanced 
Information Networkingand Applications (AINA 2013)
Barcelona, Spain, March 25-28, 2013
http://simula.no/pams2013

The intent of our workshop is to bring together people from research and
industry, in order to provide a discussion forum for state-of-the-art topics
related to multi-homing on Network, Transport, Session and Application Layers.
The PAMS workshop will include full-paper sessions as well as a poster session
(with short presentations) to introduce preliminary ideas as well as work in
progress.

Workshops proceedings will be published by the IEEE CS Conference Publishing
Service and will be included in the Digital Library.

The main topics to be addressed include (but are not limited to):

    * Network Resilience by Multi-Homing
    * Network Architectures for Multi-Homed Systems
    * Performance Evaluation of Multi-Homed Systems
    * Deployment of Multi-Homed Protocols in Existing Networks
      with Middleboxes
    * Design and Implementation of Multi-Homed Systems
    * Testbeds for Multi-Homed Systems
    * Load Sharing and Load Balancing for Multi-Homed Systems
    * Mobility for Multi-Homed Systems
    * Protocols with Multi-Homing Support
    * Congestion and Flow Control of Multi-Homed Systems
    * Quality of Service for Multi-Homed Systems
    * Multi-Homing for Interconnection Networks
    * Security of Multi-Homed Systems
    * Application Deployment and Support for Legacy Applications
    * Cross-Layer Optimisation for Multi-Homed Systems
    * Multi-Homing in the Context of the Future Internet

GENERAL CHAIRS:

    * Thomas Dreibholz, Simula Research Laboratory, Norway
    * Hakim Adhari, University of Duisburg-Essen, Germany

PROGRAM CHAIRS:

    * Martin Becke, University of Duisburg-Essen, Germany
    * Thomas Dreibholz, Simula Research Laboratory, Norway

PUBLICITY CHAIRS:

    * Glenford Mapp, Middlesex University, United Kingdom
    * Xing Zhou, Hainan University, China

PROGRAM COMMITTEE

    * Hakim Adhari, University of Duisburg-Essen, Germany
    * Nicola Altan, ista International, Germany
    * Paul Amer, University of Delaware, U.S.A.
    * Holger Bleul, DB Systel, Germany
    * Anna Brunstr?m, Karlstad University, Sweden
    * Ahmed Elmokashfi, Simula Research Laboratory, Norway
    * Kristian Evensen, Simula Research Laboratory, Norway
    * Ernst Gunnar Gran, Simula Research Laboratory, Norway
    * Seok Joo Koh, Kyungpook National University, South Korea
    * Amund Kvalbein, Simula Research Laboratory, Norway
    * Glenford Mapp, Middlesex University, United Kingdom
    * Preethi Natarajan, Cisco, U.S.A.
    * Brad Penoff, Google, U.S.A.
    * Esbold Unurkhaan, Mongolian University of Science and Technology, 
Mongolia
    * Andreas Timm-Giel, TU Hamburg-Harburg, Germany
    * Alan Wagner, University of British Columbia, Canada
    * Michael Welzl, University of Oslo, Norway
    * Xing Zhou, Hainan University, China

IMPORTANT DATES

    * Paper Submission Deadline:       October 01, 2012
    * Author Notification:             November 25, 2012
    * Camera-Ready Paper Submission:   December 28, 2012
    * Author Registration:             January 11, 2013

CONTACT

For further information, please contact:

    * Thomas Dreibholz ([email-masked])
    * Hakim Adhari ([email-masked])

WEBSITE

http://simula.no/pams2013