headers
Long, Darren | 1 Aug 2003 12:01

The UDP-Lite Protocol - comment

Is it not possible that the UDP-Lite header may define an arbitrary region
in the packet payload for checksum protection, and not restrict this region
to starting at the first byte of the payload? I don't think that the current
proposed scheme offers enough flexibility, and think that this capability
would make a valuable addition.

Regards

Darren Long

THALES OPTRONICS
Vicon House, Western Way
Bury St. Edmunds
Suffolk IP33 3SP
United Kingdom
Tel.: +44 (0) 1284 750599
Fax: +44 (0) 1284 750598
Web: www.wvintenltd.com

This e-mail is intended solely for the above mentioned recipient and it may
contain confidential or privileged information. If you have received it
in error, please notify us immediately by telephone and delete the email.
You must not copy, distribute, disclose or take any action in reliance on
it.

Whilst every reasonable precaution has been taken, Thales Optronics can
not accept liability for any damage which you sustain as a result of
software
viruses that may be contained in, or attached to this email.
--------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
Randall R. Stewart (home | 4 Aug 2003 14:19
Picon
Picon

Re: F-RTO and SCTP (was: SCTP Timestamps)

Kacheong Poon wrote:

> Pasi Sarolahti wrote:
>
> > And after the examples shown by Sourabh, I believe detecting spurious
> > RTOs with multihoming brings interesting questions for both F-RTO and
> > Eifel that I need to study more thoroughly.
>
> I guess after all the discussions so far, SCTP implementors should
> think about not to follow what is recommended in RFC 2960, timeout
> retransmission to an alternate address.  Just a suggestion, it seems
> that at least for the first timeout, the retransmission is probably
> better sent to the original address.  And when this first retransmission
> is also lost leading to another timeout, SCTP should start considering
> using an alternate address.
>
Kacheong:

Slowly catching up on a HUGE backlog of email :-o

As to the above.. I don't agree yet.. Armando has proposed such  to me
and I have yet to be convinced....

It may be that it is better in some cases.. but when you start factoring in
real failures of a NIC you may find that your failure detection starts to
be effected in a adverse way. So far I think Armando has a good point
in that possibly FR's may be best NOT to send to an alternate .. but
T3's I think may still be best sent to an alternate...

Some of Armando's upcoming work will hopefully settle this :>
(Continue reading)

Permalink | Reply | 22 comments |
headers
Randall R. Stewart (home | 4 Aug 2003 14:35
Picon
Picon

Re: SCTP Timestamps

Brian:

A question or two below on your response here...

Brian F. G. Bidulock wrote:

>Sourabh,
>
>I agree that HEARTBEAT/ACK is not a good way to do this.  Although the
>opaque data in the chunk looks attractive, there are rather narrow rules
>for the handling of HB/ACK that have a rather different purpose.  SCTP
>relies on the HB mechanism for recovery of unavailable destinations in
>the multihomed environment and is also important for detection of lost
>ABORTs.  There are some items concerning HB that was discovered in interop
>testing that showed that rather special rules were required to accomodate
>implementations that could not (or did not) control source address vs. those
>that did.
>
>I think that by overloading HB/ACK for the purpose of doing more frequent
>RTT measurements would break the original purpose of HB/ACK: 
>
I am unclear on these three:

>testing the
>availability of desintations, 
>

>keeping RTO current on idle destinations, 
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Caitlin Bestler | 4 Aug 2003 16:13

RE: F-RTO and SCTP (was: SCTP Timestamps)


-----Original Message-----
From: tsvwg-admin <at> ietf.org [mailto:tsvwg-admin <at> ietf.org]On Behalf Of
Randall R. Stewart (home)
Sent: Monday, August 04, 2003 7:19 AM
To: Kacheong Poon
Cc: tsvwg <at> ietf.org
Subject: Re: [Tsvwg] F-RTO and SCTP (was: SCTP Timestamps)

Kacheong Poon wrote:

> Pasi Sarolahti wrote:
>
> > And after the examples shown by Sourabh, I believe detecting spurious
> > RTOs with multihoming brings interesting questions for both F-RTO and
> > Eifel that I need to study more thoroughly.
>
> I guess after all the discussions so far, SCTP implementors should
> think about not to follow what is recommended in RFC 2960, timeout
> retransmission to an alternate address.  Just a suggestion, it seems
> that at least for the first timeout, the retransmission is probably
> better sent to the original address.  And when this first retransmission
> is also lost leading to another timeout, SCTP should start considering
> using an alternate address.
>
Kacheong:

Slowly catching up on a HUGE backlog of email :-o

As to the above.. I don't agree yet.. Armando has proposed such  to me
(Continue reading)

Permalink | Reply | 0 comments |
headers
Randall R. Stewart (home | 4 Aug 2003 16:03
Picon
Picon

Re: SCTP Timestamps

Stephan/all:

Ok I have now read through this entire thread and I will
use Stephan's consolidated issues to comment on things...

One large META comment I have to this discussion.. One thing
we were VERY careful NOT to do is to require that a Sender Bundle
chunks together. It IS required that a receiver understand how to
"un-bundle" chunks.. but it is NEVER required that a sender bundle
chunks... This is one problem I have with the Time-stamp chunk that
has been talked about so-far.. it requires in some aspects that the
TS-Response be bundled with SACK's .... near as I can tell... this
I do NOT like...

Now it is true that most implementations that I have
tested with DO bundle things together.. but if I remember right there
as been one or two at past bake-offs that did NOT do any bundling... these
may have changed but I hate to see such a restriction show up... i.e. that
we add something that MUST be bundled...

Now on to comments below :>

Stephan Baucke wrote:

>
> I'll try to consolidate the issues:
>
> 1) Increasing the RTT sampling frequency: Benefits are still
> controversial ([1] [2] [3]), could be achieved using either timestamps
> or implementation techniques (at the cost of additional state at the
(Continue reading)

Permalink | Reply | 586 comments |
headers
Mark Allman | 4 Aug 2003 16:47
Picon
Favicon

Re: resolving the problem of unnecessary fast retransmits in go-back-N


(way late, as usual ... sorry)

> The long-term solution to this problem is SACK (to prevent
> unnecessary retransmissions) and DSACK (to resolve the DUPACK
> ambiguity if unnecessary retransmissions do happen).  However,
> most TCP connections today still do not use SACK.
> http://www.icir.org/floyd/sack-questions.html
> 
> Until SACK is universally deployed two methods to resolve the
> DUPACK ambiguity might be useful.

First, I am not sure I am willing to believe that SACK is not pretty
well deployed.  3 years ago I reported 40% of the web clients that
hit our web server here at NASA were using SACK (and the trend was
growing steadily) [All00].  I don't have good data from that server
right now, but I took a quick look at a server at BBN that I have
been monitoring for the last ~11 days.  In that time I have seen
6545 web connections (yeah, not terribly heavy traffic) and 6183 of
the remote hosts (94%) advertised SACK.  That seems like pretty good
deployment to me.

I am not sure what that says about additional "bugfix" tricks.  Do
we need them?  Do we not need them?  The above data is not
necessarily conclusive or representative.  The changes would add
complexity to a TCP implementation.  On the other hand, not that
much complexity and maybe would provide a decent enough win.  But,
when do we stop patching known suboptimal recovery?  Etc., Etc.,
Etc.    ??????
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sourabh Ladha | 4 Aug 2003 17:22
Picon

Re: SCTP Timestamps

Just a minor comment.

> > 3) Incorrect congestion window growth due to crediting of SACKs to the
> > wrong destination address or unawareness of failover [5]: Can be
> > resolved by timestamps and/or Rhein algorithm (? not sure if these
> > really cover the same problem space; Jana?)
>
> This can be solved with a sender side algorithm.. the KAME stack
> includes such a solution that we developed while working on [5]. I don't
> see that a TS would be needed for this.. they are an alternative
> method.. but I
> don't think are required..

Congestion window overgrowth caused by retransmission ambuiguity will not
be solved by CACC in [5]. I believe that changeover specific
cwnd overgrowth is solved by [5].

-Sourabh

> > [5] Janardhan R. Iyengar, Armando L. Caro Jr., Paul D. Amer, Gerard J.
> > Heinz, Randall R. Stewart, "SCTP Congestion Window Overgrowth During
> > Changeover", SCI 2002
> > http://www.cis.udel.edu/~acaro/papers/2002.sci.iyengar.pdf
> >
Permalink | Reply | 2 comments |
headers
Randall R. Stewart (home | 5 Aug 2003 15:44
Picon
Picon

Re: AW: SCTP Timestamps

Armando L. Caro Jr. wrote:

>On Mon, 21 Jul 2003, Schruefer Wolfgang wrote:
>
>  
>
>>>If you are not following this argument, _please_ read at
>>>least section 3
>>>of our paper. It's a short read. The full paper is only 5 pages.
>>>http://www.cis.udel.edu/~acaro/papers/2003.milcom.acaro.pdf
>>>      
>>>
>>I studied your paper with high interest, but my conclusion is that a
>>mirrored Retransmission Flag would be a perfect solution for the
>>scenario you describe in the paper.
>>
>>With the mirrored Retransmission Flag you _can_ recalculate RTO on the
>>second path. You just can not do it for the third or further paths.
>>And here I think that the third path (resp. the a RTO calculation for
>>the third transmission) may not be so important to improve.
>>    
>>
>
>Well, your one bit solution only works if the sender follows the
>recommended mechanism for retransmissions. There hasn't been a consensus
>that retransmitting on an alternate path is always the best policy. In
>fact, I would argue that it isn't. I believe that for better performance
>without affecting failover performance, fast retransmits should go to the
>same destination and timeout retransmits should go to an alternate
>destination [1].  With such a retransmission policy, one bit would
(Continue reading)

Permalink | Reply | 1 comment |
headers
Randall R. Stewart (home | 5 Aug 2003 15:49
Picon
Picon

Re: Meaning of path failure (was re SCTP Timestamps)

Caitlin Bestler wrote:

>
> On Monday, July 21, 2003, at 09:35 AM, Armando L. Caro Jr. wrote:
>
>>>
>>
>> Well, your one bit solution only works if the sender follows the
>> recommended mechanism for retransmissions. There hasn't been a consensus
>> that retransmitting on an alternate path is always the best policy. In
>> fact, I would argue that it isn't. I believe that for better performance
>> without affecting failover performance, fast retransmits should go to 
>> the
>> same destination and timeout retransmits should go to an alternate
>> destination [1].  With such a retransmission policy, one bit would
>> not be enough. Sure we could use 2 bits, but timestamps just seems
>> cleaner.
>>
>> [1] http://www.cis.udel.edu/~acaro/papers/2003.icon.acaro.pdf
>>
>> ~armando
>>
>
> In the paper cited, you fault the default SCTP behavior for assuming
> "that loss indicates either that the destination address used is 
> unreachable,
> or the destination's network path is congested."
>
> The implication is that the end-to-end algorithm is "giving up too 
> quickly"
(Continue reading)

Permalink | Reply | 6 comments |
headers
Randall R. Stewart (home | 5 Aug 2003 19:00
Picon
Picon

PR-SCTP updated draft

Hi all:

I think I have now gotten all of the minor changes in
to the WG last call on the PR-SCTP document. Please have a
look at the html diff at:

http://www.sctp.org

under the RFC/internet draft tab  you will find at the
bottom a rfc-chgbar/diff that highlights the few
changes..

Please let me know if I got everyones comments.. I would like
to get this in so that we can move the document forward..

Thanks

R
---

Randall Stewart
Permalink | Reply | 4 comments |

Gmane