Subject: [tcpm] roadmap and ipr, take 3

From: Mark Allman <[email-masked]>
Date: Tue, 09 Aug 2005 15:36:19 -0400

Folks-

At the IETF meeting in Paris last week we seemed to reach tentative
consensus on the path forward for the placement of RFC 4015 in the TCP
roadmap document (there was also a bit of a thread on the list from
before the meeting that you can re-visit in the archives).

The sense of the room that we got in Paris was that RFC 4015 should be
moved to the experimental section of the TCP roadmap - mostly due to IPR
considerations.  However, decisions are not made in meetings and so we
are bringing the question to the list.  

So, two requests ...

(1) If you object to moving RFC 4015 from the 'standard enhancements'
    section (section 3) of the TCP roadmap to the 'experimental
    extensions' section (section 4) of the TCP roadmap then please yell
    loudly.

(2) If you have other reasons that you think RFC 4015 should be in the
    'experimental extensions' section of the document, please voice
    those, as well (even if voiced in the meeting or previously).

The game plan is that we'll wait to see what rolls in from this request,
we'll ask the authors to make the changes (which will be fairly
straightforward, I hope) and then we'll do a quick WGLC on the new text
to make sure its right before passing it back to Jon.

I am attaching the relevant section of the draft meeting notes below.

Thanks!

Mark & Ted

> IPR issues, Eifel response, RFC 4015
> 
>   Jon P: IPR situation is uncertain.  There are initial indications
>    on ancestors of the current document, but not on it itself.
>    However, have been anecdotal reports of IPR action taking place.
> 
>   Scott Bradner (via jabber): the point is that the IPR holder has
>    asked for a NDA discussion to get a license to implement 4015 so
>    its not so theoretical as Jon suggests
> 
>   Christian Huitema: encumbered to the point where many in the room
>    cannot implement
> 
>   Ted: Scott says cannot directly address IPR in a document, but can
>    say RFC is moved in status based on discussion of IPR
> 
>   Christian: try to implement, then can change status
> 
>   Scott B: cannot bless IPR claim by specifically referring to it.
> 
>   (many 'aah's)
> 
>   Ted: hear 'move to experimental with a note'
> 
>   Gorry: [The roadmap authors and WG] discarded another item [ XXX: I belive
>    you're referring to jumbograms -- Gorry? ] on basis that it was
>    not widely implemented
> 
>   Ted: that would be another reason
> 
>   Markku: there is another complication, proposed standard status
>    was accidental. 
> 
>   Scott B: Christian is correct about 2026 in theory but we actually
>    have no running code on that part of 2026
>   Scott B: I think it has been implemented which is how the question
>    of the license came up 
> 
>   Ted: Hums showed strong support for moving RFC 4015 to the
>    experimental section of the roadmap - mostly due to IPR concerns,
>    but please post other arguments.  Hums on other two options,
>    "move to separate section" and "no change," received basically no
>    support.
> 
>   Jon: this leaves the roadmap without any standards-track
>    recommendations for this issue, do we really want that?
> 
>   Joe T: Is there another solution we want in the roadmap?
>   Ted: F-RTO is a possibility
>   Mark Allman: Not F-RTO.  F-RTO is a detection algorithm and RFC
>    4015 is a response algorithm.
>   Bob B: don't hold up the roadmap for that
>   Ted: should we hold for that?
> 
>   Hum was to not delay the roadmap for a new spurious RTO response
>    algorithm and the response was strong to proceed with that issue
>    unaddressed in the roadmap - i.e., no response algorithm in the 
>    "Recommended" section.

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Yogesh Prem Swami <[email-masked]>
Date: Tue, 09 Aug 2005 15:12:31 -0500

>     those, as well (even if voiced in the meeting or previously).

Because the response is not sufficient in all the different cases (i.e.,
when STOs occur due to mobility). I guess I already said in my last e-mail.

Thanks
Yogesh

---

From: Joe Touch <[email-masked]>
Date: Tue, 09 Aug 2005 13:43:36 -0700

>     those, as well (even if voiced in the meeting or previously).

Dependence on experimental extensions, as noted at the meeting (though
didn't appear in the minutes).

> ------------------------------------------------------------------------
>

---

From: Mark Allman <[email-masked]>
Date: Wed, 10 Aug 2005 10:43:08 -0400

Yogesh-

> Because the response is not sufficient in all the different cases
> (i.e., when STOs occur due to mobility). I guess I already said in my
> last e-mail.

I am trying to figure out if we should be noting this in the roadmap.
Your previous email to the list said:

>> Coming back to technical issues, I believe that spurious timeouts are
>> extremely rare in the absence of mobility, where eifel response is
>> applicable. In the presence of mobility, there is a need for a
>> broader solution than just spurious timeouts. In fact, eifel response
>> could *potentially* be dangerous for spurious timeouts after subnet
>> change because it simply restores the congestion window without much
>> regard to properties of the new path.

So, the claim is that spurious RTOs are nearly always caused by mobility
and if that is the case then Eifel can actually be the wrong approach
because it restores the previous sending rate.  Do I understand that
correctly?

As pushback I will note that in some of the papers and discussion on
Eifel and other schemes folks have talked about short disconnections
(with no data loss) that are specifically allowed for in the design of
packet radios as being the motivation for detecting and somehow reacting
to spurious timeouts.

Can someone who knows about this sort of thing comment on whether
spurious timeout detection is useful outside the mobility context?
Pasi?  Gorry?

(As the author of an RFC (3708) that detects spurious retransmissions,
I'll note that my motivation in the space was to counter spurious
retransmits caused by reordering and not spurious timeouts.)

Thanks!

allman

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 10 Aug 2005 10:53:47 -0400

> Your previous email to the list said:

We might simply note that it's primarily useful when STOs are due to
reordering, and either either note or leave out, that there is some
question about its application to mobility-induced timeouts.

-Wes

-- 
Wesley M. Eddy
Verizon FNS / NASA GRC
http://roland.grc.nasa.gov/~weddy
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Mark Allman <[email-masked]>
Date: Wed, 10 Aug 2005 11:01:17 -0400

> question about its application to mobility-induced timeouts.

I didn't mean to claim that it is helpful for reordering.  I am not sure
that it really is.  Reordering usually busts fast retransmit.  So, I
don't agree with adding the above note about RFC4015 is "primarily"
about reordering.

I'd still like to hear from the folks who are savvy in these wireless
links.

allman

---

From: Pasi Sarolahti <[email-masked]>
Date: Wed, 10 Aug 2005 20:08:11 +0300

> spurious timeout detection is useful outside the mobility context?

There could be persistently reliable links along the path that might
cause timeout. For example, some people are known to use PPP-over-SSH
(yuck).

It is true that the spurious timeout work has been motivated by the
mobility world so far, but I don't think TCP can generally say anything
sure about the reason of a spurious timeout, if detected. If we had an
imaginary oracle RTO estimator that would have avoided a spurious
timeout that occurred with standard RTO estimator, the cwnd would have
remained at its earlier level. That's the reasoning I have explained
myself about RFC 4015. I believe reliably declaring a mobility event
would require an explicit mobility trigger of some kind.

But I don't know how important this aspect is in the move-to-
experimental-section discussion. Personally, I think it is a bit
inconsistent that all the detection algorithms are experimental, but the
response is in standards track. So I support moving RFC 4015 to
experimental section of the roadmap.

(And if my memory doesn't fail me, I recall that it wasn't quite clear
to everyone during the WGLC what the status was going to be. Below is a
flashback from tsvwg archives)

-----
Message-Id: <[email-masked]>
Date: Wed, 05 Mar 2003 12:51:52 +0100
To: [email-masked]
From: Reiner Ludwig <[email-masked]>

we have updated the draft that specifies the Eifel response algorithm:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-eifel-response-03.txt

[...]

We would greatly welcome more feedback.

Otherwise, we believe that this draft is ready for WG-last-call to become 
an experimental RFC.
-----

- Pasi

---

From: Yogesh Prem Swami <[email-masked]>
Date: Wed, 10 Aug 2005 12:23:15 -0500

Hi Mark,

Please see in line:

> Your previous email to the list said:

I'm okay either way. A short note might be good, but if it's going to
delay the road map draft then it's probably not worth it. The road map
draft is mature enough to move forward in my opinion.

> because it restores the previous sending rate.  Do I understand that

This is my current understanding. Also Floyd and Gurtov have a similar
observation in their wireless link modeling paper
(http://www.cs.helsinki.fi/u/gurtov/papers/mtp.pdf).

Thanks
Yogesh

---

From: Ted Faber <[email-masked]>
Date: Wed, 10 Aug 2005 10:24:52 -0700

> didn't appear in the minutes).

I don't want to lose that in the minutes.  Can you please send me a
short bot of text to insert in them?  Thanks.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Janardhan Iyengar <[email-masked]>
Date: Thu, 11 Aug 2005 15:55:13 -0400 (EDT)

> Dependence on experimental extensions, [...]

I, too, would like to see this reason mentioned.

- jana

---------------------------------------------------------------
Janardhan R. Iyengar           http://www.cis.udel.edu/~iyengar
Protocol Engineering Lab  --   CIS   --  University Of Delaware
---------------------------------------------------------------

---

From: gorry fairhurst <[email-masked]>
Date: Thu, 18 Aug 2005 21:10:10 +0100

<snip>
> spurious timeout detection is useful outside the mobility context?

I believe there are "wireless" i.e. radio environments in which delay from the 
under-lying infrastructure can vary, (L2 re-routing, bandwidth-on-demand, 
contention-access to L2, ARQ mechanisms, etc).

> retransmits caused by reordering and not spurious timeouts.)

I would like to see Eifel in the roadmap, but I questioned the position on the 
basis of lack of deployment experience in current mainstream TCP stacks - 
without this experience, it seems "experimental" in an IETF sense. I noted the 
similarity of this to the case for Jumbogram support.

Gorry