[xml2rfc] Question about tables
fred at cisco.com (Fred Baker) Fri, 28 July 2006 11:55 UTC
From: "fred at cisco.com"
Date: Fri, 28 Jul 2006 11:55:26 +0000
Subject: [xml2rfc] Question about tables
Message-ID: <CD9382A8-3CC3-4442-8A66-5EC6D7D2761A@cisco.com>
X-Date: Fri Jul 28 11:55:26 2006
I have implemented a table in the attached beginnings of a document.
Don't think too hard about what the document is about; it is
basically a request for a hop-by-hop option number for experimental
use in a protocol extension that I think has promise but needs a lot
of work.
There is a graphic that describes the hop-by-hop option, and then a
table that talks in more detail about the fields in it. The table
comes out the way I want it to look in the html version, but in the
text version I think it needs some lines to make it look better.
Suggestions on how to get the tool to produce them?
ftp://ftpeng.cisco.com/fred/xml2rfc/RCP-Hop-by-hop-edited.txt
ftp://ftpeng.cisco.com/fred/xml2rfc/RCP-Hop-by-hop.html
ftp://ftpeng.cisco.com/fred/xml2rfc/RCP-Hop-by-hop.txt
ftp://ftpeng.cisco.com/fred/xml2rfc/RCP-Hop-by-hop.xml
The "edited" file is approximately what I would like the text of the
table to come out looking like. It is manually edited. I suppose I
could do that and then put it into an "artwork" block, but it would
be nice if I didn't have to.
>From Nicolas.Williams at sun.com Fri Jul 28 15:15:37 2006
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri Jul 28 12:15:45 2006
Subject: [xml2rfc] Question about tables
In-Reply-To: <CD9382A8-3CC3-4442-8A66-5EC6D7D2761A@cisco.com>
References: <CD9382A8-3CC3-4442-8A66-5EC6D7D2761A@cisco.com>
Message-ID: <20060728191537.GQ11384@binky.Central.Sun.COM>
On Fri, Jul 28, 2006 at 11:55:19AM -0700, Fred Baker wrote:
> There is a graphic that describes the hop-by-hop option, and then a
> table that talks in more detail about the fields in it. The table
> comes out the way I want it to look in the html version, but in the
> text version I think it needs some lines to make it look better.
> Suggestions on how to get the tool to produce them?
I was just about to ask the same question: how to get dash lines between
rows of tables in xml2rfc txt output? Or is the lack of dash lines
between rows a bug?
I've got a draft which includes suggested forms for IANA registrations,
these being modelled as texttables; the lack of clear breaks between
rows makes it hard to read these forms...
Nico
--
>From fred at cisco.com Thu Jul 27 23:30:21 2006
From: fred at cisco.com (Fred Baker)
Date: Fri Jul 28 23:18:41 2006
Subject: [xml2rfc] Question about tables
Message-ID: <A4BBFE35-7D0C-4202-A083-DC05C2A2EC7E@cisco.com>
I have implemented a table in the attached beginnings of a document.
It comes out the way I want it to look in the html version, but in
the text version I think it needs some lines to make it look better.
Suggestions on how to get the tool to produce them?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060727/543bbdde/RCP-Hop-by-hop-0001.html
-------------- next part --------------
IPv6 N. Dukkipati
Internet-Draft Stanford University
Intended status: Informational F. Baker
Expires: January 28, 2007 Cisco Systems
July 27, 2006
Implementing RCP in the IPv6 Hop-by-Hop Options Header
draft-baker-document-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 28, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This note describes the implementation of RCP as an IPv6 Hop-by-Hop
option.
Dukkipati & Baker Expires January 28, 2007 [Page 1]
Internet-Draft RCP Hop-by-Hop July 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Hop-by-hop Option supporting RCP . . . . . . . . . . . . . 3
2.1. Defining the option . . . . . . . . . . . . . . . . . . . . 3
2.2. Router calculations to be performed . . . . . . . . . . . . 5
2.2.1. Router calculations to be performed periodically . . . 5
2.2.2. Router calculations to be performed per packet . . . . 5
3. Design caveats . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Behavior around tunnels . . . . . . . . . . . . . . . . . . 6
3.2. Initial conditions . . . . . . . . . . . . . . . . . . . . 6
3.3. Layer violations . . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
Appendix A. Additional stuff . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Dukkipati & Baker Expires January 28, 2007 [Page 2]
Internet-Draft RCP Hop-by-Hop July 2006
1. Introduction
2. The Hop-by-hop Option supporting RCP
2.1. Defining the option
0 1 2 3 4 5 6 7 8 15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exp | Mantissa | BW Request
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exp | Mantissa | BW Response
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exp | Mantissa | RTT Estimate
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RCP Hop-by-Hop Option
Dukkipati & Baker Expires January 28, 2007 [Page 3]
Internet-Draft RCP Hop-by-Hop July 2006
The fields in the header are as follows:
+-----------+-------+-------------+---------------------------------+
| Field | Bits | Range | Description |
+-----------+-------+-------------+---------------------------------+
| Type | 0..7 | RCPHopByHop | RCP Hop-by-Hop Option |
| Data Len | 8..15 | 6 | Payload is six bytes |
| Bandwidth | | | Bits per second the application |
| Request | | | would like to transmit at |
| B/W Req | 0..5 | 0..63 | |
| Exponent | | | |
| B/W Req | 6..15 | 0..1023 | |
| Mantissa | | | |
| Bandwidth | | | Bits per second the network can |
| Response | | | support the application |
| | | | transmitting at |
| B/W Rsp | 0..5 | 0..63 | |
| Exponent | | | |
| B/W Rsp | 6..15 | 0..1023 | |
| Mantissa | | | |
| RTT | | | Mean RTT in Milliseconds |
| Estimate | | | |
| B/W | 0..5 | 0..63 | |
| Exponent | | | |
| B/W | 6..15 | 0..1023 | |
| Mantissa | | | |
+-----------+-------+-------------+---------------------------------+
Table 1: Fields in RCP Hop-by-Hop Option
The premise is that any relevant number can be approximately
represented as a "mantissa" (an integer) shifted left "exponent" bits
(e.g., mantissa<<exponent, or mantissa*2^exponent). IEEE Standard
754 floating-point representation was considered as well, but it
consumes more bits, and network devices frequently do not directly
support it. This can be implemented in a few gates in hardware, or a
few instructions in microcode.
Two special numbers are defined: Infinity and Zero. Clearly any
number with a mantissa of zero has the value zero; implementations
are encouraged to represent with an exponent of zero as well (e.g.,
16 bits, all zero). The number with an exponent of 63 and a mantissa
of 1023 (e.g., sixteen bits, all ones) indicates an unknown or
unspecified value.
Specifically, when a TCP implementation sends a SYN packet, at that
time it has no measurement of the RTT to the peer and no knowledge of
network capacity. It may be able to say something about what it
Dukkipati & Baker Expires January 28, 2007 [Page 4]
Internet-Draft RCP Hop-by-Hop July 2006
would like to send, such as perhaps indicating the bit rate of the
relevant interface. On a SYN, therefore, the sender may indicate a
requested rate, but the rate response and RTT are unspecified.
Similarly, when sending a SYN-ACK, the system may know the response
rate if this option was present in the SYN packet, but it does not
know the RTT, and so must indicate that the RTT is unspecified.
Subsequent datagrams in the exchange have the required information,
and so may indicate it.
2.2. Router calculations to be performed
2.2.1. Router calculations to be performed periodically
The router is intended to periodically (approximately once per
average RTT of sessions passion through it, but more frequently if
appropriate) calculate how much bandwidth it can allocate to the
average data flow. The way it accomplishes this is defined in
[Nandita].
2.2.2. Router calculations to be performed per packet
2.2.2.1. Router calculations to be performed on each packet packet
If the rate being requested in any given packet is unspecified or
exceeds the bandwidth being granted to data flows in the specified
class, then it should be set to that value.
2.2.2.2. Router calculations to be performed per packet
The advertised RTT, specified, should be averaged into the current
RTT estimate.
3. Design caveats
RCP, in using the option described in Section 2, has several issues
that will need to be addressed as it is fleshed out. These relate to
o Behavior around tunnels
o initial conditions
o layer violations
Dukkipati & Baker Expires January 28, 2007 [Page 5]
Internet-Draft RCP Hop-by-Hop July 2006
3.1. Behavior around tunnels
The Internet uses a wide variety of tunneling architectures. These
include, but are not limited to:
o MPLS [RFC3031]
o Generalized MPLS [RFC3945], which is used for lambda switching
o L2TP [RFC2661]
o IP-in-IP [RFC1853]
o GRE Tunnels [RFC2784]
o IPSEC ESP in Tunnel Mode [RFC4301][RFC4301].
As discussed in [RFC2983], issues can arise with traffic passing
through opaque regions created by tunnels; information is not
accumulated in the inside headers, and if it is accumulated in the
outside headers it may or may not be copied to the inside headers on
decapsulation.
3.2. Initial conditions
As discussed in Section 2.1, the initial conditions for a data flow
are unknown. For example, until the RTT on a session has been
measured, it is invalid for the sender to advise the network of his
RTT. There may be other issues with initial conditions.
3.3. Layer violations
A special case of an initial condition problem occurs if the
transport layer specifies the rate requested in the option. Some
transports know that their applications will send at stated rates,
such as codecs; this rate can be specified to them by the
application. In many elastic traffic cases, the logical rate to
request is the bit rate of the interface that the data will flow
from. However, on any device that has multiple interfaces (routers
in general and many hosts as well), the interface is chosen in the
network layer after the transport has chosen an address. In such
cases, the transport has no a priori knowledge of the interface rate,
as the appropriate interface has not been chosen.
4. IANA Considerations
This memo requests the allocation of a hop-by-hop option, as defined
Dukkipati & Baker Expires January 28, 2007 [Page 6]
Internet-Draft RCP Hop-by-Hop July 2006
in [RFC2460]. The number should be in the range 0..63, as it is an
option which if not understood should be ignored and passed along.
The RFC Editor should replace this section with a statement reporting
the value that has been assigned to the literal RPCHopByHop.
5. Security Considerations
6. Acknowledgements
7. References
7.1. Normative References
[Nandita] Dukkipati, N. and N. McKeown, "RCP-AC: Congestion Control
to make flows complete quickly in any environment", 2006,
<http://yuba.stanford.edu/rcp/RCP_AC-dukkipati.pdf>.
[Nandita-1]
Dukkipati, N., Kobayashi, M., Zhang-Shen, R., and N.
McKeown, "Processor Sharing Flows in the Internet", 2004,
<http://yuba.stanford.edu/tr.html>.
[Nandita-2]
Dukkipati, N. and N. McKeown, "Why Flow-Completion Time is
the Right Metric for Congestion Control", 2006, <http://
yuba.stanford.edu/techreports/TR05-HPNG-112102.pdf>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
7.2. Informative References
[RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, August 1999.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.
[RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, October 2000.
Dukkipati & Baker Expires January 28, 2007 [Page 7]
Internet-Draft RCP Hop-by-Hop July 2006
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
Appendix A. Additional stuff
Authors' Addresses
Nandita Dukkipati
Stanford University
Palo Alto, California
USA
Phone:
Email: nanditad@stanford.edu
Fred Baker
Cisco Systems
Santa Barbara, California 93117
USA
Phone: +1-408-526-4257
Email: fred@cisco.com
Dukkipati & Baker Expires January 28, 2007 [Page 8]
Internet-Draft RCP Hop-by-Hop July 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Dukkipati & Baker Expires January 28, 2007 [Page 9]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RCP-Hop-by-hop.xml
Type: text/xml
Size: 17031 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060727/543bbdde/RCP-Hop-by-hop-0001.xml
>From julian.reschke at gmx.de Sun Jul 30 21:31:46 2006
From: julian.reschke at gmx.de (Julian Reschke)
Date: Sun Jul 30 11:32:12 2006
Subject: [xml2rfc] Minor 1.31 nits (DTD)
Message-ID: <44CCFB12.20806@gmx.de>
Hi,
are are two minor issues:
1) rfc2629.rnc isn't up-to-date with the current DTD; it doesn't declare
the submissionType attribute (this probably applies to the other files
derived from the DTD as well).
2) rfc2629-xhtml.ent declares character entities for the five entities
that are hardwired into XML. This causes the XML parser over here to
issue warnings every time a document referencing the DTD is parsed.
Please get rid of them.
Best regards, Julian
>From mrose at dbc.mtview.ca.us Mon Jul 31 11:09:12 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Jul 31 00:09:23 2006
Subject: [xml2rfc] Minor 1.31 nits (DTD)
In-Reply-To: <44CCFB12.20806@gmx.de>
References: <44CCFB12.20806@gmx.de>
Message-ID: <A0F7001F-FF0B-49F6-B386-B01B9FB50C5C@dbc.mtview.ca.us>
> 1) rfc2629.rnc isn't up-to-date with the current DTD; it doesn't
> declare the submissionType attribute (this probably applies to the
> other files derived from the DTD as well).
fixed.
> 2) rfc2629-xhtml.ent declares character entities for the five
> entities that are hardwired into XML. This causes the XML parser
> over here to issue warnings every time a document referencing the
> DTD is parsed. Please get rid of them.
send me a new file in a .zip or .tgz
thanks,
/mtr
- [xml2rfc] Question about tables Fred Baker
- [xml2rfc] Question about tables Fred Baker